Connecting Observation values with UCUM unit codes

I feel like there must be a simple solution that i’m not seeing here.

When Creating an Observation resource, I want to be able to get the UCUM unit code that is associated to that observation. eg. If I am creating an Observation resource for a temperature SNOMED code… but i also need to input the UCUM code manually.

Is there some list i can query for associated UCUM codes to SNOMED Observation codes ?

The short answer is no.

The current UK answer is you will find the units within a profile. E.g. for SPO2 you would view
find the codes are SNOMED 103228002 and LOINC 59408-5 and the unit is %

I feel this is a bit difficult for a developer. I would prefer to work as you suggested and be able to query for this information. (This is not an official response)
So if you wanted to see who to know how to record a COVID test result you would query against a FHIR ObservationDefinition resource and get an answer which looks something like this.

    "resourceType": "ObservationDefinition",
    "id": "ObservationDefinition-COVID19DetectionResult",
    "code": {
        "coding":  [
                "system": "",
                "code": "871562009",
                "display": "Detection of Severe acute respiratory syndrome coronavirus 2 (observable entity)"
    "validCodedValueSet": {
        "reference": ""

This tells you the code and the value is a CodeableConcept which has a defined ValueSet

It’s also possible for this ObservationDefinition to hold information on units in quantitativeDetails.unit

Hi John,

This was (and still is) hotly debated within the INTEoPEN Care-connect curation group.

There are very, very few international Observation profiles or ObservationDefinitiions (and diasagreement on which to use!).

THere is some useful guidance on use of SNOMEd CT in Observations

but beyond the NEWS2/Vital signs work we dod for Care-Connect, and a whole bunch of Child health Observation profiles (developed independently and never curated), most is being done ad-hoc.

Some people think we should not bother to spend time and effort (and it is a lot of effort) to discuss, decide on standardising use of units, sensible ranges etc. The argument is that this kind of ‘validation’ is best left to the importing system.

This kind of validation is exactly what we are aiming for in openEHR - so if you look at

You will see the UCUM units defined (there are a whole bunch more) .

We have to do this since when we persist data an openEHR-based system, these archetypes do act exactly as if they were the database validation layer i.e send wrong UCUM unit and you get a server validation error.

We have also being doing some work around generating various FHIR artefacts from openEHR archetypes - no reason why we couldn’t generate the ObservationDefinition that way @Kevin_Mayfield -what do you think?

Would be fine by me. Realised I’d knocked up this demo which represented information I was extracting from profiles or a archetype.
As central spreadsheet may also work (if we ignore valuesets for now)

Thanks you both for your responses ! That’s hugely helpful!

I might be going about things in quite a daft way. In essence want a healthcare professional to be able to search for Observations and then input the value for that observation, and have the UCUM codes suggested for that observation… the solution I’m resorting to is they have to search for the metrics separately !

To facilitate the search I found this open api:

^ That SNOMED uses on their term browser… is there a better way to achieve this kind of search ? I suppose if I’m able to search and return the ObservationDefinition instead of just the Observation SNOMED code, that would be more convenient!

With the work around FHIR artefacts… I don’t think I’ve come across them yet, How would I go about searching for those ObservationDefinition s ? Is it searchable by observation SNOMED ID ?

Thanks again for your insights,

I think you will find that is it almost impossible for clinicians to do that kind of lookup in real-time. Choosing the ‘correct’ term bindings as there is often quite a wide choice, is very tricky and somewhat arbitrary. Generally needs terminologist guidance.

Essentially we are slowly trying to ‘pre-cook’ these bindings and other parts of clinical knowledge like correct units, acceptable amount ranges etc ,etc.

Thanks @ian, I see what you mean…

As the project I’m working on is more community focused, compared to secondary care systems it is much more simple! I think I may have to roll up my sleeves and manually start associating observations with metrics + reference values for our platform.

I’m surprised there isn’t a straightforward way to do this but i can understand the different opinions clinicians have in reference values and default UCUM metrics !

@mayfield.g.kev I think looks quite neat! I think I may have a look into my own solution for now!


If you give me a list of the obs you have in mind,

I can almost certainly point to the archetypes that have that information, certainly the UCUM units and with luck some SNOMED bindings. Reference values are more tricky as they do not much exist beyond labs. We apply 'technical validation ranges ’ which are sometimes way beyond probably physiological limits but the upper range i.e how high could someone’s systolic actually go, in real life!! can be very difficult to pin down (and might be different for different age groups).

I’ll try get a list together !

I might actually be able to do it myself by searching on do you think ?

You might want to consider attending this hack INTEROPen presents: Terminology Server Hackathon Tickets, Wed 24 Feb 2021 at 09:00 | Eventbrite

The (NHS) terminology server is like the api you found earlier but with more capabilities. Not sure if it supports UCUM unit recommendations though (but that sounds like a useful idea).

I’ve been looking at a Medication browser which uses this server, I search for drugs and then get some details back on it’s characteristics.
Code is here GitHub - KevinMayfield/dmdbrowser: This is experimental work using the beta version of NHS Digital Terminology Services.
The app doesn’t work at the moment because it needs this new server.

Documentation for the new server is here
They have a online demo


Oh fair, I might have to check that out ! Sounds pretty interesting, although I feel like a lot of the FHIR community work in Java, I’ll be like a foreign exchange kid with my limited Java vocab ! (praise be to Docker).

I’ve just been figuring things out with the python FHIR client and a google FHIR server so far, so i feel like there’s quite a lot more to get a handle of! Do We know if EMIS and other EMRs will support FHIR accessible 3rd party development any time soon ?

Other end of the elephant I know but UI demo allowing a swap between Snowstorm and Ontoserver is here

I’m not sure. NHS tends to focus on clinical record view on API’s so we get exchanges of compositions. Developers are more resource focused and want tools like

  • RESTful query API’s
  • Event (streams or notifications)

Until we get those views aligned and recognise they are different requirements we will plod along slowly.

Missing from the diagram is authorisation and authentication. Probably fair to say it’s looking like authorisation is going down a federated OAuth2 route using openId authentication providers (also OAuth2 with services like NHS Logon and NHS Identity)

The composition view of interop (see below) is present in NHS FHIR STU3 standards and the move towards in NHS FHIR R4 (see above) is in progress.


A word of caution, the Termbrowser API is not supported by NHS Digital and mustn’t be used for clinical implementation. The new CSIRO ontoserver mentioned elsewhere in the thread will be supported for clinical implementation once it goes live. I understand it is currently in private beta.