We’re working on requirements for labs results, and have bumped into a potential problem. Some results are textual/non-quantitative in nature, for example “positive/negative”, “+/++/+++”, “negative/borderline/positive”. These results also need a kind of “normal range” for the receiving system to be able to mark or emphasise it in the UI. The text data type however doesn’t have any normal range/reference ranges attributes in the reference model like the quantity, count and ordinal data types do. We can’t have several different places where the normality information is kept for different data types, as this would be very complex to handle. How should this be handled?
Kind regards, Silje Ljosland Bakke
Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Often, the lab will provide a field denoting in-rangeness of
such results. Other than that, a human on the receiving side
may have to manually set the property when reviewing /
paraphing the result.
Some programmatic smarts can be added to applications to
auto-set the property to "not-any-known-normal" where
"known-normal" consists of a suitably restricted regular
expression defined per test type.
If a result is expressed as normal/ abnormal or high/normal/low,
surely the 'normalcy range' is self-defining.
If there is a need for the lab to assert some kind of textual normalcy
rangeThe 'reference range guidance' element in the Lab panel
archetype is intended for this purpose and essentially equates to
referenceRange/text in the FHIR Observation.
I don't think screen presentations should be something to consider in archetype-structures. A few weeks ago this was said to me on this list, and I think that is right. Screen presentation-definitions should be something to use in templates for screen presentation. There can also be templates for other purposes, messages, reports, etc.
Archetypes, except for its original purpose: data-structure-representation, need to be purpose independent. Archetypes are the base to build templates on, and depending of the purpose of the template, the data will be represented in a different way.
So archetypes need to be as much as possible machine-processable, and if you use all kind of convenient terms to, for example, indicate pain, then you will never be able to datamine (research in the history of a patient, or in a population) in a more generic way, and you will also need that specific archetype.
Imagine a hospital with 7000 archetypes, it will become nearly impossible to find persons which have pain, what kind of pain and how severe it is.
Better is to code pain, and I know SCT has good codes for pain (there may be other code-systems too). This makes machine processable searching for pain, kind of pain, severity of pain possible and will improve healthcare for a specific patient or a population.
Each entry in the classification needs:
- a screen representation (‘+++')
- a description (‘moderate')
in theory these two come from DV_ORDINAL.symbol, which is a DV_CODED_TEXT. That assumes a text value of '+++' and either a description or synonym (or both) of 'moderate'.
- an expression defining the inclusion criteria ('Lower Limit' < ‘Value' < 'Higher limit'
- an expression defining the exclusion criteria ('no diagnosis of xyz')
these are semantic things and I think have to be outside of the DV_ORDINAL data type definition, which after all just represents a value. Once you add these, it becomes a disease- or test-specific definition. I'm not sure where we would put these things - I think probably in a knowledge base of semantic definitions of different test results. One might argue that SNOMED should provide that, but I'm inclined to think it belongs in a knowledge base of lab-related ranges, labels and other computational elements, like the 'presentation ranking number' and 'value for calculation support' you have below.
And perhaps each entry needs:
- Ranking number (‘1')
DV_ORDINAL.value.
- Presentation ranking number (‘4')
- Associated value for calculation support (‘100')
To my ideas the Semantic Ordinal, as described, actually is an Archetype Pattern or a Data Type.
did you mean 'of a Data Type'?
I think the above ideas are all likely to be useful, but they won't all fit inside DV_ORDINAL...
The ERS system needs to be able to represent faithfully that what was shown on a screen.
This is what the HcProvider signs off/attests.
See the requirements imposed on ERS systems in ISO 18308.
Therefor I’m of the opinion that the archetype used to store data in, and retrieve data from, the database must be able to carry that screen info.
For Clinical Decision Support Systems this screen info is irrelevant.
For legal purposes it is essential.
HcProviders always will use their own local classifications. They never uniformly will use one and the same, all the time.
These local classifications need to be mapped on a standardised internal pattern/archetype for classifications. It is this pattern that is stored and retrieved annex to the mapping to the local classification.
I do not agree, archetypes are not to be used for screen presentations, for that purpose are templates. This was discussed just a few weeks ago on this list.
I agree that they do not fit in a Data Type.
It had better be handled using archetypes.
It is too complex for a DV_Ordinal Data Type
The reason why I wrote what I wrote is that Archetype must do more than the bare essentials.
Leaving more to the implicit knowledge of humans or value sets stored in one or the other service, or coding system.
I think that one of the functions of archetypes is to define precisely what is stored and retreived and transported with the least amount of implicit knowledge left for humans.