Currently (02-12-2013), in the practitioner resource 0..1 names can be associated to a practitioner. In contrast, 0..* names can be associated to a patient. This allows specifying a person's maiden name for example. Why is there this difference?
In the project I'm working on, we're exporting existing data about practitioners from our database using FHIR messages. In the database, all persons are stored in the same way. Since it is possible to store a person's maiden name (which is also done for practitioners in our data), we have to build the name part in a practitioner message differently from the name part in a patient's message. Also, when parsing a practitioner message, we'll need different code to extract the name of a patient and of a practitioner.
Therefore, I believe that there are two disadvantages of having different generic attributes of persons of different kinds:
It prevents us from sending the complete name information of a practitioner without resorting to extensions.
It complicates the code for building and parsing FHIR messages, which also makes the code less maintainable.
I understand that in most cases it's not very important to be able to send the maiden name of a practitioner, but it does add extra complexity for the implementation. Furthermore, I don't see what problems setting the cardinality to 0..* could cause. If someone only wants to send a single name, then that's still possible.
Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also discussed here) also seems like an unnecessary restriction.
Managing cardinality is a tricky issue. If the resource can have multiple names, then everyone dealing with this has to deal with the possibility of multiple names. The relevant committee believes that having multiple names is an unusual practice for practitioner records (that's certainly my experience) but a common one for patient.
Perhaps you'd like to explain your full use case so it can be considered by the committee? On the other hand, you can use an extension:
<Practitioner>
<extension url="http://myurl.com/fhir/profiles/extensions#maiden">
<valueHumanName>
<!-- details for human name -->
</valueHumanName>
</extension>
</Practitioner>
Therefore, I believe that there are two disadvantages of having
different generic attributes of persons of different kinds:
When designing Patient, Pracitioner and RelatedPerson, we have tried several different solutions:
having Person resource, separate from Patient/Pracitioner. This proved to be burdensome since many systems (unlike yours!) don't capture patient and person separately, and when looking at REST useage patterns it turned out they were always needed togehter, resulting in unneccessary burden on client and server
Having a special Demographics datatype which contained all shared attributes. This met resistance since it meant having attributes on Practitioner that did not make sense, e.g. marital status and deceasedDate. This run against our intent to keep the Resources focused to their scope and the number of attributes per resource manageable.
This is how we ended up where we are now: more or less "duplicating" the attributes (when applicable) across those three resources.
Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also >discussed here) also seems like an unnecessary restriction.
The Practitioner resource represents a person employed by an organization to provide care. We assumed that for one such engagement, there is one "official" (post) address for that person. The practitioner may however perform services at multiple locations (each of which can have an address).
Related
I have a FHIR Bundle with requisition report that needs to go to multiple Practitioners. How would i represent this, would it be via references in a MessageHeader or...?
In the MessageHeader itself, we're a bit unclear on the meaning of multiple destinations. It might be for fan-out routing where the message is pushed to an initial recipient, which then sends to multiple places. Alternatively, it might tell the destination who else received the message (though at the 'routing' level, this is generally not useful information, so I'd presume only the first is intended).
The more useful level (the level surfaced at a business level and retained after delivery) for a cc is on the DiagnosticReport itself. Surprisingly, there's no standard element or extension for defining that. You could certainly define your own, but it might be worth submitting a change request and soliciting a standard extension for that purpose - to indicate who all intended recipients of the report are.
I am wondering how you make sure you are not adding the same person twice in your EventStore?
lets say that on you application you add person data but you want to make sure that the same person name and birthday is not added twice in different streams.
Do you ask you ReadModels or do you do it within your Evenstore?
I am wondering how you make sure you are not adding the same person twice in your EventStore?
The generalized form of the problem that you are trying to solve is set validation.
Step #1 is to push back really hard on the requirement to ensure that the data is always unique - if it doesn't have to be unique always, then you can use a detect and correct approach. See Memories, Guesses, and Apologies by Pat Helland. Roughly translated, you do the best you can with the information you have, and back up if it turns out you have to revert an error.
If a uniqueness violation would expose you to unacceptable risk (for instance, getting sued to bankruptcy because the duplication violated government mandated privacy requirements), then you have to work.
To validate set uniqueness you need to lock the entire set; this lock could be pessimistic or optimistic in implementation. That's relatively straight forward when the entire set is stored in one place (which is to say, under a single lock), but something of a nightmare when the set is distributed (aka multiple databases).
If your set is an aggregate (meaning that the members of the set are being treated as a single whole for purposes of update), then the mechanics of DDD are straightforward. Load the set into memory from the "repository", make changes to the set, persist the changes.
This design is fine with event sourcing where each aggregate has a single stream -- you guard against races by locking "the" stream.
Most people don't want this design, because the members of the set are big, and for most data you need only a tiny slice of that data, so loading/storing the entire set in working memory is wasteful.
So what they do instead is move the responsibility for maintaining the uniqueness property from the domain model to the storage. RDBMS solutions are really good at sets. You define the constraint that maintains the property, and the database ensures that no writes which violate the constraint are permitted.
If your event store is a relational database, you can do the same thing -- the event stream and the table maintaining your set invariant are updated together within the same transaction.
If your event store isn't a relational database? Well, again, you have to look at money -- if the risk is high enough, then you have to discard plumbing that doesn't let you solve the problem with plumbing that does.
In some cases, there is another approach: encoding the information that needs to be unique into the stream identifier. The stream comes to represent "All users named Bob", and then your domain model can make sure that the Bob stream contains at most one active user at a time.
Then you start needing to think about whether the name Bob is stable, and which trade-offs you are willing to make when an unstable name changes.
Names of people is a particularly miserable problem, because none of the things we believe about names are true. So you get all of the usual problems with uniqueness, dialed up to eleven.
If you are going to validate this kind of thing then it should be done in the aggregate itself IMO, and you'd have to use use read models for that like you say. But you end up infrastructure code/dependencies being sent into your aggregates/passed into your methods.
In this case I'd suggest creating a read model of Person.Id, Person.Name, Person.Birthday and then instead of creating a Person directly, create some service which uses the read model table to look up whether or not a row exists and either give you that aggregate back or create a new one and give that back. Then you won't need to validate at all, so long as all Person-creation is done via this service.
Background:
I have been digging into the FHIR DSTU2 specification to try and determine what is the most appropriate resource(s) to represent a particular patient's historical list of GPs/PCPs. I am struggling to find an ideal resource to house this information.
The primary criteria I have been using is to identify the proper resource is that it must provide values to associate a patient to a practitioner for a period of time.
Question:
What is the proper resource to represent historical pcp/gp information that can be tied back to a patient resource?
What I have explored:
Here is a list of my possible picks thus far. I paired the resource types with my thought process on why I'm not confident about using it:
Episode of Care - This seems to have the most potential. It has the associations between a patient and a set of doctors for a given time period. However, when I read its description and use-case scenarios, it seems like I would be bastardizing its usage to fit my needs, since it embodies a period of time where a group of related health care activities were performed.
Group - Very generic structure that could fit based on its definition. However, I want to rule out other options before taking this approach.
Care Plan - Similar to Episode of Care rational. It seems like a bastardization to just use this to house PCP/GP history information. The scope of this is much bigger and patient/condition-centric.
I understand that there may not be a clear answer and thus, the question might run the risk of becoming subjective and I apologize in advance if this is the case. Just wondering if anyone can provide concrete evidence of where this information should be stored.
Thanks!
That's not a use-case we've really encountered before. The best possibility is to use the new CareTeam resource (we're splitting out CareTeam from EpisodeOfCare and CarePlan) - take a look at the continuous integration build for a draft.
If you need to use DSTU 2, you could just look at Patient.careProvider and rely on "history" to see changes over time. Or use Basic to look like the new CareTeam resource.
We are currently in the process of evaluating FHIR for use as part of our medical record infrastructure. For the EHR data (Allergies, Visits, Rx, etc..) the HL7 FHIR seems to have an appropriate mapping.
However, lots of data that we deal with is related to personal Fitness - think Fitbit or Apple HealthKit:
Active exercise (aerobic or workout): quantity, energy, heart-rate
Routine activities such as daily steps or water consumption
Sleep patterns/quality (odd case of inter-lapping states within the same timespan)
Other user-provided: emotional rating, eating activity, women's health, UV
While there is the Observation resource, this still seems best fit (!) for the EHR domain. In particular, the user fitness data is not collected during a visit and is not human-verified.
The goal is to find a "standardized FIHR way" to model this sort of data.
Use an Observation (?) with Extensions? Profiles? Domain-specific rules?
FHIR allows extraordinary flexibility, but each extension/profile may increase the cost of being able to exchange the resource directly later.
An explanation on the appropriate use of an FHIR resource - including when to Extend, use Profiles/tags, or encode differentiation via Coded values - would be useful.
Define a new/custom Resource type?
FHIR DSTU2 does not define a way to define a new Resource type. Wanting to do so may indicate that the role of resources - logical concept vs. an implementation interface? - is not understood.
Don't use FHIR at all? Don't use FHIR except on summary interchanges?
It could also be the case that FHIR is not suitable for our messaging format. But would it be any "worse" to go FIHRa <-> FIHRb than x <-> FIHRc when dealing with external interoperability?
The FHIR Registry did not seem to contain any User-Fitness specific Observation Profiles and none of the Proposed Resources seem to add appropriate resource-refinements.
At the end of the day, it would be nice to be able to claim to be able to - with minimal or no translation, ie. in a "standard manner" - be able to exchange User Fitness data as an FHIR stream.
Certainly the intent is to use Observation, and there's lots of projects already doing this.
There's no need for extensions, it's just a straight forward use. Note that this: " In particular the user fitness data is not collected during a visit and is not human-verified" doesn't matter. There's lots of EHR data of dubious provenance...
You just need to use the right codes, and bingo, it all works. I've provided a bit more detail to the answer here:
http://www.healthintersections.com.au/?p=2487
We have a layered application, or at least is in the process of transitioning to one, broken down as follows:
Interface (user-interface or application-interface, ie. webservice, etc.)
Business logic
Data access
To make the rest of this question more concrete, I'll describe a specific instance.
We have a user interface, which has a controller object behind it (the business logic layer). This controller talks to the database through another object (the data access layer).
In a given context, the user interface allows the user to pick an employee to tie the operation being done to. Since there are rules regarding which employees the user (well, any world outside of the controller really) can pick, the controller provides two things for this:
a readable property containing a list of available employees to choose from
a read/writable property containing the currently chosen employee
The user interface might read the list and use it to populate a combobox.
In version 1 of this application, the combobox contains the identifying number of the employee + the name of the employee.
All is well...
... until version 1.1, a bugfix. A user complains that he can't choose between Jimmy Olson and Jimmy Olson because the application doesn't make it easy enough for him to know which is which. He knows there is one Jimmy in the sales department, and another in the development department, so the fix for this 1.1 version is to simply tack on a slash + the department name in the combobox. In version 2 we would opt for replacing the combobox with a combobox that has column support, removing the slash, but in 1.1, this is what is chosen in order to minimize the risk of further bugs.
In other words, the combobox would contain:
1 - Jimmy Olson/Sales
2 - Jimmy Olson/Development
other people
However, the user interface code has no SQL code, or any way to get hold of that department, and thus we have to go to the controller and look at the code there. The controller doesn't need the department, and to be honest, it doesn't even need the name of the employee, the identifying number is enough, so there is nothing in the controller that asks for or does anything to the department. So we have to go down to the data access layer and change the SQL there.
This solution quite frankly smells.
If there are multiple interfaces to this controller, with different requirements, we have three possible solutions:
Change the data access layer to cater for the (increasing/diverse) needs of multiple interfaces (2 layers away), which means that all the interfaces will possibly get all the data they need, but they would also get all the data required for any of the other interfaces
Add something that lets the user interface tell the data access layer (still 2 layers away) what it needs
Somehow make the user interface layer get hold of the required data without changing either the controller or access layer involved, this sounds like we need more data access code, somewhere.
None of the above solutions feel good.
What I'm wondering is, are we completely off course? How would you do this? Are there a fourth and fifth solution below the 3 above?
Per this question: Separation of Concerns, the accepted answer contains this quote:
The separation of concerns is keeping the code for each of these concerns separate. Changing the interface should not require changing the business logic code, and vice versa.
Does this simply mean that all the controller/data access layer should provide us with is whatever it needs to do its job (ie. the identifying numbers of employees), and then the user interface should go talk to the database and ask for more information about these specific employees?
The way I see it, you have two possibilities:
Have the lower layers send up all
the information they have about a
person, possibly as an XML document,
even though many of the consumers of
that information don't need it all.
Provide APIs for the higher level
layers to drill down and get the
information they need. So in the
case you give, have a method that
the interface can ask the business
layer to ask the database layer for
the department given the user id.
Both have trade-offs. The first one exposes a lot more information, possibly to consumers who don't have any right to that information. The second one passes a lot less information per transaction, but requires more transactions. The first one doesn't require a change to the API every time you have more information, but changes the XML. The second keeps the interface of existing APIs the same, but provides new APIs as needs change. And so on.