During the openEHR.ch Data Modeling Exchange Group (DMEG) work, we agreed to use CLUSTER.case_identification.v0 as the standard for representing the administrative case ID in Switzerland. The decision is documented here: Log in with Atlassian account
However, the archetype is currently still in draft state, which creates some uncertainty for implementation. Since we would like to establish a Swiss standard for this use case, it would be helpful to rely on an archetype that has gone through review and is available in a stable published version.
Would it be possible to put CLUSTER.case_identification.v0 into review and, if appropriate, publish it as version 1?
We understand that this may need to be prioritized together with other IEB work. Could you let us know whether a review of this archetype is already planned or could be considered? If helpful, members of the Swiss DMEG would be happy to support the review with feedback from the Swiss implementation perspective.
Iām curious about your use case. I also note that this archetype was developed in 2010 and references an IHE Laboratory Technical Framework related to notifiable diseases. Is that the context you are modelling as well?
If so, there may be other archetypes that emerged from infectious disease notification, surveillance and outbreak management that may be more useful. Some of these arose from development of the Ocean ID tool modelling from 2015/16ish and the more recent MOH Jamaica standardisation effort.
At this point, IMO this archetype is of limited utility as it is not specific enough in intent and yet oddly specific in the associated data elements, which limits broad reuse.
I think I was responsible for that archetype which as you say was part of showing alignment with IHE Public health lab test definitions many years ago.
So āCaseā in this instance definitely refers specifically to a Public Health Case , not to a general āAdministrative caseā
@Olha_Nikolaieva - I donāt have access to the Confluence page but have requested it. My impression is that you may be intending to use this archetype to apply to a much wider idea of āclinical caseā /Encounter/Episode of care - is this correct? If this is the case, there are discussions about adding an EncounterID to compositions to handle this but until then, most people are using local cluster archetypes in composition/context. Part of the challenge in this area is that the idea of ācase/encounterā etc can be a bit different around the world. Thnkfully the FHIR Encounter/ EpisodeofCare resources seem to be getting some traction and helping pull people into a level of standardisation.
No, it is not the case we were about to represent. It is really about the kind of Case/Encounter ID.
Exactly, this was the goal. And as you pointed out, some Swiss implementations are already using local clusters, which support the linkage between the openEHR composition and the FHIR Encounter resource.
Thatās interesting to hear. Could you maybe elaborate a bit on what kind of confusion āEncounterā is causing in Australia? Iād be curious to understand yout context better.
Interesting, I hadnāt noticed this archetype before. I can see it is from 2022, but it seems we have not seen it in CKM until now. At first glance, it could actually work for our use case. We would need to review the details, but it looks like a possible candidate for representing an Encounter ID in our case. Thank you for pointing it out!
I have just written a āone pagerā to try to clarify my understanding about the use of Encounter. It ended up being 22 pages.
The problem space in AU:
Context
What āencounterā means
Example
Administrative and funding systems
A billable unit of service, used colloquially. Formal frameworks use different terms: āprofessional attendanceā (MBS), āseparationā (activity-based funding), āservice eventā (community care reporting).
Varies by framework - āEncounterā is implied. It does not appear as a formal term in any of these frameworks
FHIR / AU Core
Either a single visit or a whole admission, distinguished only by partOf nesting
Under investigation in the FHIR AU community in preparation for development of an Encounter IG
Hospital
The entire admission from presentation to discharge
Three-week inpatient stay
openEHR
A single interaction - explicitly not an episode of care
One nursing observation
Primary care
A single GP consultation
One visit for a sore throat
SNOMED CT - Procedure hierarchy
Patient encounter procedure (308335008) - sits in the Procedure hierarchy (an act that occurs, not a record of an act). Scoped to one interaction.
Modality subtypes include face-to-face encounter (1258986006), telephone encounter (185317003), and videoconference encounter (453131000124105).
SNOMED CT - Record artifact hierarchy
Four concepts within the Record artifact hierarchy, at different levels and in different branches.
Encounter note (866144008), Encounter report (371531000) with children of Clinical consultation report (371530004) and Progress report (371532007), Emergency department encounter report (773093006)
Encounter is both an abstract concept, a type of record artifact and an administrative item. We use the word interchangeably for all things and conversations get very confused, especially when an encounter in primary care usually reflects a single āinteractionā, āvisitā or ācontactā and in acute/hospital care it represents the whole admission. Therefore, in the hospital setting then what is each āinteractionā by each health professional called. And what are the relevant record artefacts called in each setting? In that context, how does a hospital (whole of) encounter record differ from a primary care single (or complex) interaction encounter record? What is the derived artefact for sharing called (ie a snapshot or summary, not the whole record) - either during an open encounter/admission or a closed/completed one? How is that different to a handover of care document? So many questions.
