I think of this all the time, its existential dread.
1 Like
Call it code, id, key, itâs a reference to a definition of something, and that definition is a mix of human readable things, links to other definitions, context, etc, etc. Those definitions need to have some kind of representation, it doesnât matter if itâs a graph, object oriented, or free text, you just need enough bits to describe the thing, how you sort those bits and how those bits and encoded/decoded is meaningless. The semantics is in the bits themselves. Itâs like DNA being described by long strings of 4 symbols, you just need enough of those to represent something with enough semantics that it allows to understand the concept exactly, but be practical enough so that can be used in software (itâs impractical to describe each thing by a representation of all its atoms).
For instance, it would be possible to have an RM that represents the base ontology we need to base all the clinical concepts on, and use ADL to represent higher level concepts by constraining/extending/specializing the base RM. Though if we use the same formalism, letâs say ADL, to also represent the base RM (I commented about that in other thread recently), you can construct all your semantic layers with one formalism. Then how you reference or identify each component of a thing represented by the formalism, be an id, a code, a path, it doesnât matter much, what you care about is that the reference is exact, unique, processable, etc.
I think we have different mental models about this. The comment by @damoca was about not using paths at all, which is the structural part, so if you donât use that part, you need the semantics of the structure also in the terminology or in the ontology that defines the base semantics. My point is that the semantics should be somewhere and I see the structure as part of those semantics. So you can change the paths for other things, but at the end everything is connected, you just changed the reference to the entry point to get to the thing.
On the other hand, what you say is to create yet another element in the specs, with bindings to other artifacts. I canât imagine the kind of effort required for such feat.
Anyway, I would like to see a practical example of all this before discussing further since I think there is something I donât get here 
That is the correct attitude 
More people should have itâŠ
To be useful and usable, this needs to be a controlled ontology, and representation of that is quite important.
Some of the informational semantics are not needed (and have no place) in the ontology. For example heart rate and exertion level are just two observables in an ontology; thereâs no data / state distinction. We overlay that in the information layer to separate out what is the focus of our enquiry (the heart rate) and factors the modify the interpretation (body exertion level etc). In the Intermountain Healthcare CEM models (archetype equivalents) they donât have data/state separation. It makes their models harder to understand and even a bit harder to compute with, since you canât easily loop through the meaning-modifying observable elements, but it doesnât make their models wrong.
The ontology is just about reality, not about analytic views of reality. That means it is pretty lean.
I understand the ontology is not the place for the structure. What Iâm saying is to have the full semantics about something, specially if we are talking about recording, exchanging, querying, analyzing and visualizing information, you need ontologies, taxonomies, dictionaries, data structures, terminologies, constraints, mappings, etc. and all of those linked together, thatâs the only way you can use all the models from a fully semantic point of view. If we work just with some of those, we will always have partial semantics.
Though Iâm open to other ideas, but I need to see something actually working that way to be convinced. If you have such thing, please share it.
1 Like
I donât think I said that anywhere 
I fact, I believe we totally agree.
What I said is that both the information structures and their semantics are important. I agree with the comments saying that it will be probably impossible to put a code to everything, that would be unmanageable. But it is also wrong to think that everything is about the structure (which is, by the way, the initial question, what happens when that structure changes in an archetype).
Dual modelling is greatly based on semantics. The fact that we use a reference model already provides some basic semantics or a reference ontology. When an archetype is created, we are constraining those semantics. When an archetype is named, we are also defining semantics. If we call an archetype OBSERVATION.pulse we are somehow assigning a code, a meaning, to it. When we filter by an archetype_id in an AQL it is not something structural, it is semantic!
So, the point is that structure is essential, because it helps to organize data. But its combination with a semantic definition is what should help us to find the right data. This combination is especially true when we work with data values. A code can help us to find an ELEMENT that represents the systolic blood pressure. Its location in the archetype can provide a context for the meaning of that information. And then we will see that it is a DV_QUANTITY and we will be able to find its units by navigating to the specific attribute of the data type We wonât need further codes here.
Iâd like to conclude by saying that everything we are discussing is about the vision for openEHR/dual model systems. Maybe the technology is not yet there. Maybe developers of openEHR systems and modelers still have to learn about the best way to proceed and how to create efficient solutions. If we have been working on this for +20 years is because nobody said it was easy.
2 Likes
Right. Iâm just saying that there are important semantics not currently in many archetypes, primarily markers to indicate what each data item reports on (aka âis-aboutâ - see this foundational paper). These markers, to be of any use computationally must necessarily be entities in an ontology. That ontology could either be assumed to be SNOMED CT, things like OGMS, FMA, etc, or something created de novo. Our âexperimentâ in the US actually used LOINC, for convenience rather than any technical suitability. You were worried that such an ontology would replicate the contents of archetypes. I am saying it wonât; it establishes the target of the is-about relation for each archetype data point.
For example in the Pulse / heart beat archetype, the data point /data[Rate] reports (= is-about) heart rate, but computationally thereâs no way to know what âheart rateâ is - i.e. the right side of the relation is absent. So CDS or other components canât easily:
- know that the rate is comparable to the same thing called differently in e.g. FHIR, inside Cerner or other EMR etc
- know that it is a âvital signâ and that it needs to be in a certain range to be alive and not in an emergency situation;
The first thing is obtained by the use of the same is-about code in different health data models from which data are created; the second is achieved by locating the code within its ontology and following various relations (is-a and others).
So the addition of this ontology wonât replicate the informational semantics (consisting of the structures of elements on the left side of the is-about relation); au contraire, it provides the ontological meaning.
Some might think (as many have over the decades) that the ontologies or terminologies such as SNOMED CT are all that is needed. But they arenât; it should be clear from the above that they can only provide an ontological underpinning to the structures of information that people actually want to record.
The information structures have their own semantics: why is a certain collection of data points used to characterise a certain phenomenon? There are many reasons, nearly all contingent, e.g. medical history / culture, cost-related, and so on. Physicians do initial exams using cheap, non-invasive methods; they only do MRIs and similar when they are really needed. So physical exam archetypes will contain certain data points, and not others. Docs donât record what the patient ate when recording heart rate, unless they suspect something ingested is actually causal; and so on.
Ontologies of reality thus capture invariant truths (as best we know them), while ontologies of information capture contingent rules / structures and so on. The latter are what HCPs record to do medicine; the former tells us what the data mean. More on this here.
I believe we are at a point where we (the HIT domain) needs to do this properly and we are best placed to realise it in openEHR.
1 Like
This is something that we need to work on to improve.
2 Likes
There are work going on to bring SNOMED CT and LOINC closer together.
LOINC / SNOMED CT â Regenstrief Institute, Inc. and SNOMED International
1 Like
It depends on what you mean by âexternal terminologiesâ. In the same way as it is possible for everyone with the right knowledge to extend openEHR with a new archetype, it is possible for everyone with the right knowledge (and a SNOMED CT license) to extend SNOMED CT with new concepts within the SNOMED CT relationship structure. In the future, openEHR and SNOMED CT modelling might be more integrated than today, if we believe that is a good idea.
(The drawback of extending SNOMED CT with your own content is about the same as extending openEHR with archetypes outside the international CKM.)
5 Likes