We are currently working on recording observations on our host EPR which uses SNOMED.
How do you know if a code should be a value programatically?
i.e.
if I want to record Body Weight -
I can lookup the code in a terminology server and get the answer 27113001
How do I know that should be recorded as a value with kg units. The result would look something like this Clinical Observations
For blood pressure, I can find the code is 75367002 but how would a developer know this is component observation and we need systolic and diastolic values in mm[Hg] units? e.g. Clinical Observations
We can use this website to see how to record the common examples Clinical Observations
but the number of observations you can record are huge?
Very interesting question. I suspect the most that could be done in SNOMED would be to find some way to link the Property ‘118538004 |Mass, a measure of quantity of matter (property) (qualifier value)|’ to the potential Units of measure that are ‘mass’ units of measure. In this example everything in the hierarchy under 258680008 |Unit of mass (qualifier value)|.
Though this would allow the recording of a mass in kilodaltons.
In any event more detailed info would be needed for specific implementations.
There are 148 properties, but not all of them look like they are could be countable so would need a unit of measure, Biological sex (property) and Address (property) for example.
Don’t think it is something that can really be represented in a Terminology server and IMO we definitely should not be using SNMED CT t o define units - UCUM is the established international standard for that and is used widely.
So the challenge is how to associate specific observations with related units, terms and other metadata.
So, of course we use archetypes for that and have done a lot of work on units.
but ObervationDefinition is also a lighter weight artefact that could be useful
Other than that we are into lots and lots of FHIR profiles!!
I think this is a sweetspot where openEHR can do the heavy-lifting of capturing the requirements , then auto-generate various FHIR artefacts out the back.
I’m not sure what the current thinking is, but is used to be UCUM for units of measurement and SNOMED for units of counting. I think dm+d is all SNOMED but I might be wrong on that.
In SNOMED the only hierarchy of concepts which should have values is the “Observable Entities” hierarchy. An Observable entitiy is if you like a question to which there is an answer. The value may be numeric or textual. Elsewhere you will find “Findings” which contain the question and the answer. So 60621009 |Body mass index (observable entity)| and 162864005 |Body mass index 30+ - obesity (finding)| the latter includes the “Answer” 30+
Blood pressure needs to be treated as a battery as there should be a Systolic and Diastolic Value for each observation. So many systems will have a “Header” for Blood pressure" and two othe concepts related for systolic and Diastolic observations. Much of it beyond this will depend on the information model of the system rather than the terminological model.
Yes teh number of observations which could have values is huge.
