Hi!
At Cambio, here in Sweden, we are going to initiate a work regarding what we call care contacts, which is basically encounters, within primary care.
My question is if anyone has created templates for this that you would like to share with us? Think that would be very helpful for us to see how others have done it and get inspired. We haven’t really gotten started yet but we could of course share the outcome of our work further on.
2 Likes
These are some things that we are specifically interested in:
- What archetypes have been used?
- How have you managed updates to the Composition/Entries based on events in the patient journey, e.g. the patient arrives, encounter starts, encounter ends and so on
What do you mean by ‘Encounter’, in this context?
To me this means a single interaction f2f/online between a patient and a professional bounded by the start and end time of a typical primary care consultation i.e patient enters room at 09:00 and patient leaves at 09:15.
Composition.Encounter
context.start_time
context.end_time
However, I am aware Encounter can means something different e.g a hospital visit where they can be multiple interactions
1 Like
This is a list of the archetypes we used in the past for a GP system encounter. We deliberately put complex interactions like prescrbing, referral, test ordering in different compositions.
Encounter
Reason for encounter
SOAP PSKY
Story/History
Body temperature
Pulse
Blood Pressure
Laboratory Test
Laboratory Test Panel
Organisation
Body weight
Height/Length
Indirect Oximetry
Respiration
ECG recording
Glasgow Coma Scale
Pulmonary Function Testing
Body mass index
Alcohol Use Disorders Identification Test (AUDIT)
MADRS
I-PSS Prostate Score
Urinalysis
PUQE Scale
Menstrual cycle
Clinical Synopsis
Problem/diagnosis
Problem status
Healthcare service request
Care journey
Goal
Health Education
Clinical Synopsis
4 Likes
I know Emma is away on vacation, so I’ll continue to follow up on this.
We agree that more complex data should be put into other Compositions.
What we are after is really not to summarize the clinical outcome and content of the Encounter. It is to capture data about the encounter itself. As a thing that has its own life cycle.
The encounter is an event that has happened and should be part of the patient record (is our thinking).
I can see there being multiple Encounter compositions on the same real world single Encounter, each documenting different clinal interventions, assessments etc.
We need to capture information like:
- Type of encounter (f2f, video, phone…)
- State (planned, ongoing, performed…)
Some data sits in the RM, but that will not be enough. Feels like we would need to model some additional archetype to capture more data.
1 Like
Maybe I’m missing something, but I get the impression that we’re talking about at least partially administrative data about appointments, and not the clinical content of the appointments?
4 Likes
I agree , I’m still a little unclear about the user story here.
- Type of encounter (f2f, video, phone…)
That could be handled by context.participations.mode or
- State (planned, ongoing, performed…)
This implies some sort of booked or planned activity. Normally we would not handle that inside openEHR , unless it was perhaps part of a managed patient journey or care plan.
And there definitely needs to be some sort of linkage between ‘related compositions’ whether part of a complex Encounter or more formal Episode of Care.
@martin.grundberg - a short user story might help clarify a typical use case.
2 Likes
Since the infrastructure such as the reference model of openEHR is extremely versatile, why not try to build a CKM-like knowledge repository for common administrative requirements?
1 Like
Well, yes and no 
We are not talking about the clinical content of appointments (or encounters), that is straight forward. We use the Encounter composition with whatever archetypes are relevant for that use case.
An encounter is the outcome of an appointment (appointment being a planned event or “activity”). So we are not really talking about appointments, but the event that followed.
I guess it would often be seen as “administrative” data, but the distinction “administrative” and “clinical” are not always clear. Our starting position is to ask ourselves “is this information part of the patient’s record”, and our hypothesis is to answer that with “Yes, encounters are part of the patient record”. That means our starting position is to manage it using openEHR.
One optionis of course to say that “this is not the domain of openEHR”. We know we are pushing openEHR here a bit, but encounters are absolutely central to EHR systems, and not only for administrative purposes, eg it is central to querying for health data, e.g. “show me all the diagnoses that were recorded during an encounter”. It can also serve as an indicator for healthcare professionals how many times a patient has been in contact with healthcare (the number of encounters in general or to a certain clinic could indicate some underlying problem).
Im not experienced with the Admin archetypes. But a quick look in the ckm seems to indicate that others have been looking at this type of requriement before https://ckm.openehr.org/ckm/archetypes/1013.1.4447. Is anyone using them?
Ah - o k so this is closer to what I would call an Episode of Care. THis has been under discussion in SEC, as it was thought that we might need to handle it with aRef Model change but I think an archetype, pretty closely aligned with the FHIR Episode of Care resource, would work pretty well, though I suspect there are some elements that we would handle in different archetypes, as this is very much oriented to a US reporting requirement IMO.
This is my current look at FHIR - green = we would use, yellow = we might handle that in a different archetype>
Part of our challenge are the very different uses we need
- Hospital admissions and outpatient clinics
- Primary care encounters (maybe one visit plus multiple encounters with different professionals)
- Managing care journeys e.g Mental health.
and it would be good to ensure that we are aligned with Contsys where possible
1 Like
In this case, I feel comfortable saying its the FHIR Encounter concept we are looking for (aka Contact or Care Contact). FHIR Episode of Care may include/have many FHIR Encounters, during which many openEHR Encounter Compositions are documented.
I am used to this concept in a Swedish regional context, covering primary care, outpatients, admissions, A&E and more. The same concept corresponding to “Encounter” (we call it Contact, same same) has managed all those areas, with slight variations in the information models, especially for inpatient cases.
The same concept and system implementation worked almost out the box within the NHS England covering A&E, outpatients and inpatients, including managing all the CDS (Commissioning Data Set) reporting requirements which is highly encounter based.
We had to add a separate concept to cover the hospital provider spell, covering multiple consultant episodes (=contact in our EHR=FHIR Encounter) for an inpatient.
Regarding the use cases, Id say:
1. Hospital admissions and outpatient clinics
- FHIR Encounter works for both
2. Primary care encounters (maybe one visit plus multiple encounters with different professionals)
- Single primary encounter - FHIR Encounter
- One visit to multipe professionals - What I am most used to to support this is multiple Appointments to one FHIR Encounter (this is also the FHIR model). The patient is really only arriving to the clinic once, one visit.
3. Managing care journeys e.g Mental health
- This sounds like an Episode of Care, something spanning across multiple Encounters. Patient can then leave the hospital and have periods of time where they are not in the hospital, but you still want to track that you are managing that patient. We have a concept in our EHR called “Commitment” which tracks this, and this corresponds to FHIR Epsiode of Care.
The openEHR Encounter Composition is a confusing to us that come from the EHR system space as that is not normally how we see encounters. Or, the Encounter in openEHR does not map to the FHIR Encounter. During a single visit to the hospital, any number of documents/notes can be done (each represented as an openEHR Encounter Composition). Ie, FHIR Encounter 1…* openEHR Encounter.
Current hypothesis is to model an Admin entry for the Encounter, a sibling to the https://ckm.openehr.org/ckm/archetypes/1013.1.4447 archetype. Perhaps include it in an Encounter Composition.
What is described in the existing ADmin archetype “Episode of care - institution” I think could be seen as both a FHIR Encounter or a FHIR Episode of Care. Often (in Swe and NHS UK at least) for inpatients there are two levels of concepts. A higher level tracking whent he patient gets admitted to they get discharged, and a lower level which tracks “episodes” within specific departments or consultants, as they require to be tracked separately for various reasons.
The basics of what we want to capture about the encounter (right now) is this:
- status (planned, ongoing, performed…)
- type (f-2-f, video, phone etc.)
- where the encounter takes place
- what healthcare organisation is responsible for the encounter
- when the encounter took place (start and end time, could be a start time in the future if it is only planned)
So we are talking about the more administrative parts and not what actually happened clinically.
I saw this in the Use section of the Encounter archetype:
“- allow for harmonisation or alignment with other model formalisms such as FHIR or CIMI, such as explicit representation of participants that are usually managed by the openEHR Reference Model in an openEHR archetype.”
When I look at this it sounds like we might have a problem when aligning with for example a FHIR-profile (that we will also create for this) if we only have these attributes recorded using the reference model attributes.
Is that correct? What problems would that be in that case?
Do you think we should create an admin_entry archetype instead for our usecase?
In addition I think there will be more to enter within the encounter, regarding what actually happened clinically, but right now that is not the scope for us.