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).