In some use cases, we need to model elements that can be simple or more complex, within the same model. An example is the body site of a diagnosis, which can be as simple as a free text string or precoordinated terminology term, but could also involve aspects, lines, distances from a landmark in a specified direction, or a circular direction around a landmark. Till now we’ve handled this by putting in a DV_TEXT plus a SLOT for a CLUSTER archetype, like this:
This works relatively well, but can in some cases be problematic for querying the data. This led us to think about the possibility of adding a combined data element and SLOT to an archetype. Similar to the way we currently can add several different data types to a data element. Is this something that could work?
The simplest approach is to do what you are doing and always ensure the simple DV_TEXT element contains an appropriate value even if the more complex data are filled in, i.e. so that querying can always succeed in the simple mode, even if the data tree is also there.
Sure, that’s how the models are intended to be used now, although we can’t enforce it. But the question was if we can make a single AT-code (or id-code in ADL2) a choice between (for example) DV_TEXT and a CLUSTER slot? And if we can’t do it now, what would need to be changed for this to become possible?
In general:
the EHR is documenting things in the patient system. This can be a body location. Anything documented has localisation in time and space. Space can be the world (GPS), address, organisation and anatomical location, etc. Localisation in space, in general, can be absolute (e.g. GPS) and relative to anything else including an Anatomical Body Part. When it is a relative location one needs to specify in more detail the vector from a point of reference. This vector defines the point of origin, the distance between the point of origin and the item that is documented, plus direction. In addition and alternatively the vector can be replaced by a term from a classification defining things as: (partial) overlapping, above, below, to the left, to the right.
All these subtleties pose problems too easy querying but are needed to fully model data in the EHR.
For the moment any quick fix is just that.
I did have some ideas about his a few years ago, as I completely recognise the issue but it was pretty difficult to come up with a solution. It was discussed in CIMI but my head exploded trying to work out a solution!!
I assume both Element and slot Element are hanging from CLUSTER, so generic paths without specifying the node_id can indeed be used.
Again, playing with cardinality could ensure you have either the original Element or the slot one
Not quite. The suggestion as I understand it is to have a run-time choice between a coded_text and a SLOT containing a CLUSTER that would provide detailed structure for the same semantics. Body site is a classic example - prefer to use a value set of body sites where possible but allow CLUSTER.anatomical_location as a fall back if you need more specific detail or to cover something not included in the value set.
I’ll try again!! Told you it made my head hurt last time!!
What we want for the majority of simpler uses, or where pre-coordinated terminology works is just
ELEMENT: Body site
but sometimes we need to handle more complex constructs
ELEMENT: Body site
ELEMENT: Laterality
Currently we do that by adding a SLOT for the more complex example but that means we end up with Body site both two places.
I think what I am trying to get at is something like
EXPANDABLE ELEMENT :
name: Body Site
value: Lung
other details: CLUSTER SLOT
So this is as full blown Element not a slotted in construct. It already has a ‘slot’ at the same level as the name and value. THe other_details is other details relating to the Element itself not sitting alongside it in the root.
In this world the current anatomical location CLUSTER would be much the same but would not have its own ‘body site’ element.
That should give us a clear query target for body site. THe only way we can do that is use the CLUSTER every time which is a pain.
One other approach would be to change the visuals via some kind of directive to give the option of ‘hoisting’ the CLUSTER body site ELEMENT to the root level. That would mean adding the CLUSTER to every template.
The only other option I can see is to consider creating some ‘domain’ datatypes e.g. an ‘Anatomical location’ datatype.
Are there other examples of similar patterns /problems - I guess the Medication Order / Cluster is one although that is more subtle
This is probably not the solution you are searching for, but I think the problem you are presenting is just in the middle of that grey zone between information models and terminologies. An in my opinion, the representation of this case should fall in the terminological area.
At the end, you want an element with a code, that can be simple or be somehow postcoordinated. If you are using SNOMED CT, this would be “easy”, just use a post coordinated expression.
If using post coordination is still something futuristic, or if you want to define constraints over the specific atrributes of the code, or if you are not using SNOMED CT at all and you want to use a terminology that does not support post coordination, then probably you need something new in the RM.
In the old 14796 data types standard (the one used in the first version of ISO 13606), the Concept Descriptor (CD) data type supported this feature. It represents a coded value where you can attach semantic qualifiers (attributes) with a role and a code value. This allows creating a basic post coordination using the information structure. The advantage would be that we still could build AQL queries over the data type information structure.
a) I’m not sure anyone is using post-coordination in operational systems in anger
b) SNOMED licensing remains an issue.
If it were not for that, I think there is a good case for at least testing whether the current SNOMED anatomical location model is a good fit. Certainly an area where the kind of dual terminology/Information model representation that CIMI was striving for might be worth the effort, although I suspect that even that you might find that the biomedical view of anatomy - essentially the relationship between body parts, gets out of kilter with the IM requirements e.g relative locations, detailed xy,z coordinates.
Beyond laterality, I wonder how much overlap really exists?
Discussions with local SNOMED experts today about how to manage laterality in diagnoses and body site… Apparently there is a SNOMED ref set that captures all of the duplicated body structures, so there should be a pretty comprehensive value set for body structures that means the Anatomical location archetype will only need to be used in outlier situations. The updated body sites with laterality are limited to left or right , so we need two occurrences if we need to represent both left and right of a duplicated body structure. The hierarchy containing ‘both’ or ‘left and right’ body sites is apparently outdated and I was advised it should not be used, at least for now.
It means that we can safely keep most diagnoses and their body sites modelled within the single archetype, without needing to extend with the Anatomical location CLUSTER.
There is an increasing number of precoordinated diagnoses with Left/Right/Bilateral as well.
Reassuring if you have a SNOMED license, but this is still diverting from the original question of how a CHOICE may be implemented at run-time and found in queries.
A big help here would be if we could persuade SNOMED Int. to release those pre-coordinated body site + laterality codes as a ‘free set’.
That would largely solve the body site issue as I think it mostly relates to laterality. Who wants to start a conversation (maybe along with FHIR folks) ?!!
However I still suspect there are other similar patterns but can’ think of specific examples so far!! Are there any from the physical examinations? There probably are some examples from the old histopathology work
We do the same Body site/SLOT Structured Body site combo with BP and the Exam CLUSTERs. Procedure has Body site and suggestion to put Anatomical Location in the Procedure detail SLOT, rather than a dedicated one. Imaging instruction will need it. There will be others.
