Best Practice Modellierung von Ja / Nein / Weiß nicht / Nicht erhoben

• Home
• Modellierung von Ja / Nein / Weiß nicht / Nicht erhoben

Modellierung von Ja / Nein / Weiß nicht / Nicht erhoben

Sollen Informationen mit den Antworten Ja / Nein / Weiß nicht / Nicht erhoben in FHIR repräsentiert werden, z. B. die Information, ob bestimmte Erkrankungen oder Symptome vorliegen, sollte unterschieden werden, woher die Informationen stammen:

1. Werden sie von einem Menschen direkt eingegeben, oder
2. Fehlt die Eingabe bei der Eingabe oder wird auf dem Server nach einer Information gesucht und ein Fehlen kommuniziert werden?

Im ersten Fall, beispielsweise durch die Erhebung in Questionnaires mit anschließendem Mapping in Observations, werden die Informationen als CodeableConcept dargestellt, auch wenn es nur die Auswahlmöglichkeiten Ja und Nein gibt. Dies ermöglicht einen Vergleich von Informationen aus verschiedenen Systemen und Profilen sowie eine Erweiterung der möglichen Werte ohne Änderung des Datentyps.

Für die folgenden Konzepte befinden sich in diesen Empfehlungen Codierungen:

Für diese Konzepte werden folgende Codierungen empfohlen, wobei SNOMED bevorzugt wird vor LOINC, und dies vor HL7 CodeSystemen.

Bevorzugte Codierung

Alternative Codierung

CanonicalURLs

Beispiele

Beispiel I – entgegen dieser Empfehlung

In Profil A wird der Status, ob eine bestimmte Erkrankung vorliegt, mit Ja / Nein erhoben und in einer Observation als valueBoolean hinterlegt.

In Profil B wird der Status, ob eine bestimmte Erkrankung vorliegt, mit Ja / Nein / Unbekannt erhoben und in einer Observation als valueCodeableConcept hinterlegt.

Diese beiden Spezifikationen sind inkompatibel zueinander aufgrund der unterschiedlichen Datentypen. Für Implementierer, die Ressourcen zu beiden Profilen weiterverarbeiten möchten, entsteht ein Mehraufwand, da sie beide Datentypen verarbeiten können müssen.

Beispiel für Profil A:

{
    "resourceType": "Observation",
    "id": "1",
    "status": "final",
    "code": {
        "coding": [
            {
                "code": "72288-4",
                "system": "http://loinc.org",
                "display": "Odor of Exudate from wound"
            }
        ]
    },
    "valueBoolean": "true",
    "effectiveDateTime": "2023-06-21",
    "focus": [
        {
            "reference": "b68841d5-c928-45c1-b083-d1629bfccf71"
        }
    ],
    "subject": {
        "reference": "c33dfe0c-3bc3-46eb-971b-4d1a2f218cf3"
    }
}

Beispiel für Profil B:

{
    "resourceType": "Observation",
    "id": "1",
    "status": "final",
    "code": {
        "coding": [
            {
                "code": "72288-4",
                "system": "http://loinc.org",
                "display": "Odor of Exudate from wound"
            }
        ]
    },
    "valueCodeableConcept": {
        "coding": [
            {
                "code": "373066001",
                "system": "http://snomed.org/sct",
                "display": "Yes"
            }
        ]
    },
    "effectiveDateTime": "2023-06-21",
    "focus": [
        {
            "reference": "b68841d5-c928-45c1-b083-d1629bfccf71"
        }
    ],
    "subject": {
        "reference": "c33dfe0c-3bc3-46eb-971b-4d1a2f218cf3"
    }
}

Beispiel II – Berücksichtigung der Empfehlung

Ändert Profil A den Datentyp zu valueCodeableConcept und nutzt einen Teil der in Profil B zulässigen Werte (nämlich die Codierungen für Ja und Nein), können Ressourcen zu beiden Profilen von Implementieren identisch behandelt werden. Zusätzlicher Implementierungsaufwand kann verhindert werden.

Beispiele für beide Profile Ressourcen:

{
    "resourceType": "Observation",
    "id": "1",
    "status": "final",
    "code": {
        "coding": [
            {
                "code": "72288-4",
                "system": "http://loinc.org",
                "display": "Odor of Exudate from wound"
            }
        ]
    },
    "valueCodeableConcept": {
        "coding": [
            {
                "code": "373066001",
                "system": "http://snomed.org/sct",
                "display": "Yes"
            }
        ]
    },
    "effectiveDateTime": "2023-06-21",
    "focus": [
        {
          "reference": "b68841d5-c928-45c1-b083-d1629bfccf71"
        }
    ],
    "subject": {
        "reference": "c33dfe0c-3bc3-46eb-971b-4d1a2f218cf3"
    }
}

Verwendung der dataAbsentReason-Extension

Im Fall, dass Informationen auf dem Server (oder einem System mit vergleichbarer Funktion) herausgesucht werden sollen, aber nicht gefunden werden, kann dieser Sachverhalt als dataAbsentReason (ggf. auch als Extension) hinterlegt werden.

• Beispiel A: In System A wurde die Information, dass der Status, ob eine Erkrankung vorliegt, nicht erhoben wurde, per Questionnaire / Formular erhoben. Diese Information wird in einer Observation als valueCodeableConcept hinterlegt.

• Beispiel B: In System B wurde dieselbe Information zum Vorliegen der Erkrankung nicht hinterlegt, allerdings soll eine Information dazu extrahiert werden. Da die Information nicht vorliegt, wird in der Observation nicht valueCodeableConcept, sondern dataAbsentReason mit einem entsprechenden Wert gefüllt.

Rückmeldungen

Rückmeldungen zu diesen Inhalten bitte an das TC Terminologien übermitteln.