SNOMED on FHIR

Page tree

We're going to use FHIR medication resources for our national list of prescriptions (by decision from the eHealth Agency). We are also going to use SNOMED CT to code reasons for prescription, but since this SNOMED value set is never going to be complete we need to represent something like nullflavor=OTH. The specification generally does not include nullflavors, although there are extensions like DataAbsentReason. According to this Zulip thread there has been a design decision to not use a nullflavor like in v3. https://chat.fhir.org/#narrow/stream/4-implementers/subject/DataAbsentReason.20extension.20or.20ValueSet.20with.20UNK.2FOTH.3F

How do others solve this problem?

  • No labels

4 Comments

  1. Daniel Karlsson

    The solution chosen in our project was to add "OTH" from the v3 NullFlavor CodeSystem https://www.hl7.org/fhir/v3/NullFlavor/cs.html to our otherwise SNOMED CT ValueSets. This is analogous to e.g. the Marital Status ValueSet https://www.hl7.org/fhir/valueset-marital-status.html.

  2. Alejandro Lopez Osornio

    Discussed in FHIR call, Australia uses DataAbsentReason

  3. Peter Jordan

    In the NZ e-Prescription Service, coded indications for prescribing is not a mandatory element (0..*) and we don't expect to see reasons why that data might be absent. In practical terms, it's enough of a struggle for the prescribing systems to encourage over-burdened users to provide coded reasons. and it might be self-defeating if concepts such as 'other' or 'unknown' were added to dropdown selection lists as it would be too easy for users to select these by default. If a patient doesn't want this information to be used for downstream purposes, they can request that the clinician marks the relevant prescription item as 'confidential'.

  4. Michael Lawley

    For clarity, we us DAR when we need to represent this kind of info (rather than nullFlavor).
    I don't know what we do for this specific use case though.