In the context of mapping openEHR into OMOP we want to be as exhaustive as possible and provide as many alternatives to generate visits from openEHR data as possible. If your organization is supporting this kind of grouping of the data, what is a visit/episode* for your organization?
I think using FOLDERs is the way to go to model episodes. But I could see a COMPOSITION with DV_EHR_URI work as well. @chunlan.ma and @sebastian.iancu have different implementations.
There’s been some previous discussions on this topic. Probably on discourse, but also on Jira/confluence. Would be good to include that.
Be careful that the term ‘episode’ is very overloaded.
So a generic mapping of all episodes to OMOP episode seems dangerous. How well defined is the concept in OMOP? Does it vary per study?
OMOP distinguishes visits (when patient got admitted/discharged) and episode (e.g. a diseases, chemo treatments). We are mainly interested on the first ones right now, as second ones usually imply data curation and/or folders as you say. In principle, every condition, observation, etc. in OMOP can be related to the visit.
Omop visits have a high level abstraction (inpatient, outpatient, ER, etc.) so realistically should be dependent of the context of the data. Our idea is to add a new “visit” type of OMOCL mapping that could extract the relevant start and end dates from existing data, being that admin_entry, context, etc. I can see that info available in the folder structure (there are no folder archetypes in any CKM, but they could potentially exist now in local installations)
As @joostholslag says ‘episodes’ is a very overloaded term and can mean very different things to different people, and I suspect almost impossible to standardise in any short term.
Howver, at the core, of all these perspectives and requirements, there is possibly a very simple administrative idea of ‘episode’ that is reasonably well captured by the FHIR EpisodeOfCare - FHIR v5.0.0 resource.
I think we could usefully create an equivalent archetype that could be in common against all the different possible use-cases, even if they use episode identifiers rather than folders, or have very different local definitions of ‘episode’
These are the data points that might best be captured in an EpisodeofCare archetype - maybe best as a Cluster to allow this to sit inside more contextual Admin-entries.
“identifier” : Business Identifier(s) relevant for this EpisodeOfCare
Yeah, seems to be quite aligned. For legacy DBs, this info is extracted from health summaries or discharge reports, which can give you an approximate idea of when the care started/ended.
For external consultations a same day visit start/end is assumed
episode of care: health related period during which healthcare activities are performed to address one health issue as identified by one healthcare professional.
clinical process episode clinical process episode : health related period that includes all healthcare activity periods in one clinical process.
FHIR’s definition of episode of care looks consistent with ISO ContSys’ definition above.
The primary difference between the EpisodeOfCare and the Encounter is that the Encounter records the details of an activity directly relating to the patient, while the EpisodeOfCare is the container that can link a series of Encounters together for problems/issues. [Source]
These resources are typically known in existing systems as:
* “identifier” : Business Identifier(s) relevant for this EpisodeOfCare
* “status” : R! planned | waitlist | active | onhold | finished | cancelled | entered-in-error
* “managingOrganization” : { Reference(Organization) }, // Organization that assumes responsibility for care coordination
* “period” : { Period }, // Interval during responsibility is assumed
* “careManager” : { Reference(Practitioner|PractitionerRole) }, // Care manager/care coordinator for the patient
* “type” : - e.g. specialist referral, disease management
* Home and Community Care
You might squeeze eventPeriod into start and end_time, but identifier, status, even managing organisation are not good fits.
The other issue is that these datapoints are firmly constructed from a reporting perspective, not from a clinical perspective, although clearly there may be a lot of overlap with e.g a care journey episode record for more clinical purposes.
I think there is merit on settling on a common ‘Episode of care’ archetype close to the FHIR resource, which in some cases may be the definitive record, but in other cases, needs to be populated indirectly from a more clinically-oriented record, or from different uses of folders/ episode indeintifiers etc.
Trying to get something that can account for all of the different clinical and reporting requirements will I suspect prove elusive.
The main purpose of this thread is to gather all the alternatives everyone is using, not to create a single source of truth but to provide as many alternatives as needed for omop visit generation
Personally I know of two ways, considering the episode implies more than one clinical contact, and might include things that are not clinical contacts (encounters).
Folders, was already mentioned.
Special linked composition: one episode compo linked to all the individual event compos.
Option 2. Is kind of a folder, though it can include the full internal structure of the composition (context + content).
Those are the two “openEHR ways” I can think of. Then a vendor could implement their own episodes in top of the openEHR models.
Thanks for this Diego - it is very timely. I am just finalising the draft for the next edition of ContSys. For those not familiar, ContSys is a concept model of the health and care business. It isn’t an information model (logical or physical). The site I provide at https://contsys.org is a model conforming to the standard. For the revision, there is a draft model conforming to the last Draft International Standard.
Starting with the big picture:
ContSys is looking at continuity of care across multiple professions and organisations. Implicity, this extends to multiple record management systems
The Clinical Process (which will become continuity of care process in the next edition to embrace all social care activities addressing environmental/social considerations) covers all professionally governed activity from initial raising of the concern though to resolution or death. For transient issues, this is a clearly defined between two dates; for long term conditions only a start date will exist until death.
The clinical process is identified by the use of a health thread. This is effectively a cross-organisational identifier of the care. A use of the health thread in the English NHS is the patient pathway used to measure waiting times for interventions to resolve conditions and to enable fair waiting list management.
At the other end of the spectrum is the ContSys notion of a Contact, where a member of the health and care team interacts with the patient. Not all activity is within a contact - a lab analyser processing a specimin is an example, as is a multidisciplinary team review meeting without the patient being present. In ContSys the time period in which the contact occurs is a contact period with synonym encounter.
In the middle, things get messy. Different jurisdictions concentrate on grouping all the activity together in different ways, often for managerial or financial reasons. FHIR provides the nested encounters as a way of suporting multiple approaches, and episode of care as a way of grouping activity within one provider. The ContSys encounter is just one kind of FHIR encounter.
ContSys uses the various mandates to handle the accountability dimension, which the physical models tend to avoid. In the current draft, the mandates are much more clearly drawn out, separating functional roles (performances/participations) from structural roles (mandates / contracts to perform/participate).
Call to action - I’d appreciate feedback on the use of the words period, episode, encounter and contact to get an improved set of concepts in the next edition of ContSys
How do associate the various compositions that record data about an ‘Episode’ or ‘Encounter’?
Folders
Tags
Common identifier embedded in compositions
some other from of EHR_URI links
How/ where do you record the base metadata associated with each episode start/ end dates , 'owning organisation etc?
FOLDER archetype
ENTRY / CLUSTER archetype in an ‘Episode master’ composition
Use FHIR to handle this
Are you asking one or both questions?
I don’t think we will ever get a consensus around the first question as the variations are justifiable.
Similarly, there are a number of different approaches to the second question—hospital admission is very different from community nursing to GP to care pathway management.
However, it might be possible to agree on a core EpisodeofCare service that emits a set of datapoints, sufficient to meet common reporting/ analytics requirements, regardless of the exact internal configuration.
In a discussion with fellow ContSys project team members around the modelling of time we came to the following conclusions:
A contact should remain the interaction between a subject of care (patient) and a person providing care for an issue
An encounter should remain within one care provider but retains the HL7 recursive nature. An encounter will usually include contacts but not in all cases, such as a lab processing a sample. An encounter groups activities performed by a care provider
Episodes fall into two kinds
condition related episodes, tracking the evolution of a condition. This is not tied to one care provider.
activity related episodes, tracking the care activities addressing a condition. Again this is not tied to one provider.
In both cases, episodes are linked through ContSys health threads which in 13606-1 is represented using a link.
In the current 2015 edition of ContSys, an appointment is for one contact; should this be for one encounter?
I would appreciate the wider openEHR community’s views on this approach. I’ll also share concept definitions as they are refined.