Barnet_David_HEALTH
(Barnet David (HEALTH AND SOCIAL CARE INFORMATION CENTRE))
1
All
I have a modelling issue where I’m trying to bind a single data point or an archetype to a choice of terminology & code systems.
The actual use case is that I’m modelling a new-born hips examination, and the result may be given as either a SNOMED CT concept, a Read 2 code or a CTV3 code (for those unfamiliar with Read 2 & CTV3, they are code systems used (mostly) in primary care in the UK). In the actual instance, each code/concept will have a code system identifier to distinguish the actual code system used
For example, a result of “no abnormalities and no risk factors” can be represented as either
The answer isn’t completely simple. Some background here. If there are bindings defined for snomed_ct, read2 and ctv3 to the ac-code that appears in the archetype definition section, and no further constraint is given, the implication is that any code from any terminology with a binding may be used at runtime. Since this is normally on a value-set by value-set basis, each value set (each distinct ac-code) will have a binding entry only in those terminology groups in the binding section that make sense.
in which case Dmitry’s advice is correct and the Archetype Editor allows you to add bindings to
any/all of the terms via the terminology, then term-binding tab. Not the nicest UI but you get there!!
If the target needs to be selected from a list of possible options then Thomas’s advice is appropriate. One issue is that we do not have good industry standard ways of defining these external refset bindings, though it looks as if FHIR might get some traction.
It should also be noted that normally constraints on which terminologies can be used in a particular implementation is done in a template. This can be done on the existing DV_TEXT definition or on a DV_CODED_TEXT constraint. This can be expressed in the template designer, again not the best UI but you get there… Not sure that archetype constraint bindings help in this step.
the solution to this situation is not yet 100% clear in ADL2 (it is in ADL1.4, as others have described). We are trying to define a cleaner way to represent it in ADL2, but I’m still not clear on the requirements. It appears that the scenario you have is that since SNOMED CT, READ and CTV3 are extant in the UK, coding should be allowed using any of those, but not by other means.
Does this apply across the whole HSCIC model library? Or do you want some more fine-grained control, e.g.:
do you want to designate certain terminologies for specific templates ? E.g. template A can only use SCT, but template B can use any of the three?
do you need to say on a node-by-node basis in a single template, e.g. this node must be coded by SCT, but this other node by say SCT-or-READ, and this third node, any of the 3 are allowed?
If others can clarify requirements in this area as well, it would be very helpful.
Barnet_David_HEALTH
(Barnet David (HEALTH AND SOCIAL CARE INFORMATION CENTRE))
7
Thomas
For use (NHS in England) it’s probably at the template level (but it would be good to occasionally specify at the node level).
In England there’s a concerted effort to move towards a single terminology (SNOMED CT), but I imagine that’s a long road.
In the meantime, we have a mixed economy of coding systems.
For some interoperability (such as a GP to GP communication), there is one coding system in use (in this case Read, but soon to be SNOMED CT). In other scenarios we map to a single coding system (for example in some of our HL7 messaging specifications, for our Commissioning Data Sets). In other scenarios such as Public Health England’s Child Health data sets (which is where the hips example came from), we recognise that different systems use different coding systems and say to send the data in the coding system used to capture the data.
So it’s a very mixed picture, and the move towards SNOMED CT will increase the mixture in the picture. However, the nirvana of SNOMED CT across the board will make thing a lot easier, but is a long way in the future (should it be reached at all).
just to be clear on this point, because this is the one I want to know about. Consider the following archetype extract: ~~~~~~~~~~~~~~~~~~~~~~~~~ definition OBSERVATION[id1] matches { – data matches { HISTORY[id2] matches { events matches { EVENT[id3] matches { – Any event data matches { ITEM_TREE[id4] matches { items matches { ELEMENT[id6] occurrences matches {0..1} matches { – value matches { DV_CODED_TEXT matches {[ac1]} } } ELEMENT[id7] occurrences matches {0..1} matches { – value matches { DV_CODED_TEXT matches {[ac2]} } } CLUSTER[id8] occurrences matches {0..1} matches { – items matches { ELEMENT[id6] occurrences matches {0..1} matches { – value matches { DV_QUANTITY matches {…} } } … – etc } } } } } } } } } [“ac2”] = – assume SNOMED has a value set of test statuses ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the above, we don’t need to do anything special to make sure that the node id1 and value set at ac1 are coded from SNOMED CT, and that id3 and ac2 are coded from LOINC - because the bindings don’t provide for anything else. But if there was a binding for [“id1”] in both the snomed_ct and the loinc binding group then we might need a capability to say: on this particular OPT, I only want to allow LOINC at node id1, while being able to allow other nodes to still use SNOMED CT and / or LOINC in different permutations. The latter is obviously more complicated to specify in a generated template, because now you really do have to able to mark different nodes as differentially subsetting their allowed bindings, for some particular purpose. I’m hoping we don’t need to do this, but would like to know if it is needed. thanks - thomas