Modelling Encounters in FHIR: Part 2
January 31, 2014 10 Comments
I was having a chat with some colleagues in New Zealand (who shall remain nameless, but you know who you are PJ & KA) about Encounters – specifically how to model an encounter (using openEHR archetypes as it happens), and it became evident that we were talking about slightly different things by the word ‘encounter’. I was referring to the FHIR encounter – a resource that has mainly administrative information about a contact with a patient (date, time, participants and so on), but my colleagues were referring to the more holistic concept of encounter – including all the clinical information collected during that encounter, actions performed, and so on.
So that we were talking about the same thing, I volunteered to write down how you could express these concepts in FHIR – so here it is. A simple Primary Care (Ambulatory Care in the US) consultation, which has a clinical note (subjective and objective) plus a prescription.
Note that I’ve used a Composition resource to establish the context of the Consultation note. This is a versatile resource (as most of them are in truth), which is also used in a FHIR document, although it doesn’t have to be – as this example shows.
The composition references the encounter, and also – through the sections of the composition – the clinical findings and actions that occurred during the consultation. There is some duplication of data – eg dates are in both encounter and composition – but nothing to get too concerned about.
This is how you could store the record in a data store, and of course it’s really easy to serialize into a FHIR document if you want to send a copy of the record to someone else – it would be an atom feed with 7 entries/resources in it with the appropriate references (see an example of a similar FHIR document here). Of course, you would also need to include copies of the referenced resources like Patient and Practitioner (that I left off the picture for simplicity) that would increase the resource count slightly.
Interestingly, this layout is very similar to how a CDA document would be represented – with the Composition (plus Patient and Practitioner) as the CDA header, and the Encounter, Clinical Findings and Medications Prescribed as sections. Co-incidence? I think not…
So: in our modelling work we really need to model the Encounter as a separate Entity with references to the clinical parts of the consultation, rather than a single model that seeks to encompass the whole thing (IMHO).
About David Hay
You don’t need Composition to provide context. Almost all resources link to Encounter directly. (And if you need a linkage to a resource that doesn’t, you can use an extension.) Composition is only needed if you want to provide a particular structure to the assembled information – e.g. as a document.
Thanks for that Lloyd. I did look into that, but couldn’t see an obvious place to link – say – the observations directly to the encounter. How would that work?
And btw if we assume that the use case is to record all the details of a primary care contact with a patient, then isn’t that enhanced by the composition structures – like section?
cheers…
Observation not having a link to Encounter seems like a glaring omission to me. I’ve raised it as an issue on the tracker and I expect it’ll be there for release 2. Certainly it’s something that I think falls within the 80%. For now, you could use an extension.
The only thing sections should add is context for how to present and render the information to a human. If that’s your primary driver, then yes you’ll probably want to structure it as a document. However, if all you need to do is capture the information about what happened at a particular encounter, there’s no need to bring Composition into it. Even if composition is present, the meaning of the data should be the same if Composition is removed.
So you’re saying that anything that ‘happened’ during that encounter( eg a prescription, a new diagnosis, a lab order, a radiology request, an updated careplan, etc) has a link back to that encounter, and the Composition should only be a display mechanism of those resources to a human? This does mean that to figure out what happened during that encounter (which is a really common use case) you need a whole lot of ‘reverse queries’. The composition does seem to make things a lot more tidy…
That’s my biggest fear with the FHIR, so far. The same need for a reverse query is to query the patient related person. The system, somehow, should be aware of what’s available to avoid querying every resource that may reference the target resource. Is there a method/solution/recommended approach?
Cheers.
That’s not so much an issue with FHIR as it is with RESTful implementations. In REST. Any resource on any server can reference any resource on any other server. There’s nothing FHIR-specific about that. And there’s no magic “give me all data from all servers that point to X” solution. The reality of RESTful services is that they will function in some sort of interoperability space. The set of servers involved will be finite, and quite often, all of them will synchronize using atom publish/subscribe mechanisms so that they all end up with the same data in a fairly reasonable period of time.
Other architectures include indexing solutions where the data servers may not all be well known, but a single (or set of synchronized) indexing servers are. In this scenario, data repositories create index records when they receive data and queries first hit the index to determine what server(s) may have relevant content to query. (We had talked about generalizing DocumentReference to cover any resource, but weren’t sure about this use-case yet.)
If you just want all data for a given patient from a given server, you can use the patient partition. (We don’t yet have encounter partitions, and I’m not sure the value they’d add would outweigh the complexity.)
Thank you, Lloyd! I think I see the light at the end of the tunnel now 🙂 It takes time to switch thinking from all eggs in one basket vs. distributed data. With an index of available servers and resources that they support, it can be a pretty neat solution! Congrats on DSTU!
Well, FHIR generally only allows associations to point in one direction and from a RESTful perspective, it makes sense for the observations, interventions, etc. to point to the encounter as it will pre-exist them. If you want to find out everything that happened during an encounter, a reverse query will be the only way to achieve that. Any composition that is created is likely to be a summary (e.g. a discharge summary) that includes a filtered subset of the information deemed to be likely to be “relevant”. So which approach you use really depends on what you’re interested in.
The association linking data to the encounter is there (or should be), so you can retrieve all of it (or any particular subset of it) if you wish. On the other hand, if what you want is a human-mediated summary organized for human consumption, a Composition is a better structure.
Simply creating a Composition for expediency of linking isn’t a good practice. If you want to enable really efficient queries from encounter to everything that happened as part of it, then define an extension on Encounter and have your server auto-update the encounter as you post other records. (Though there’s still the potential issue of data that might be linked to the encounter that isn’t posted to your server.)
Hmm – I can see where you guys are going. Agree David that Encounter resource is left with a limited set of items specific to the concept and not include any clinical or other admin stuff. I think it’ll be a while to try and find how best to represent certain information – certainly best from real world implementations.
I tend to think in order to avoid cumbersome reverse querying FHIR might benefit from an embedded lightweight health record organisation (e.g. a uniform EHR structure as in openEHR). This might have the advantage of both assisting the user to collate different types of resources from a patient into a meaningful document (e.g. health summary, GP2GP transfer etc.) and also be of great help for consistent rendering.
This might add some complexity but a specific resource which records all actions belonging to a particular patient would definitely solve the problem of brute force search to find everything pertaining to a particular patient. I think this is what David had in mind when using a Composition to encapsulate all transactions). Look I don’t know enough about FHIR yet so forgive if this does not make sense at all!
I believe you don’t always need everything in one form (unless it is a summary report). When information is displayed to a clinician (even if it is on one screen), it is still separated: meds, immunizations, encounters, etc. Query them separately to display to a clinician and this may cover 75% of informational needs. It is less often when a clinician reviews each encounter in details to find out a big picture of health problems (again, other than for reporting purposes). Concerns?