FHIR Patient-Ressource erklärt: Identifikatoren, Namen, demografische Daten und Verknüpfungen, mit einem gültigen Beispiel

Kurze Antwort: Patient ist die FHIR-Ressource, die eine Person beschreibt, die medizinische Versorgung erhält: wer sie administrativ ist, nicht was ihr fehlt. Sie enthält Identifier (medizinische Aktennummern, nationale IDs), Namen, Telecom-Kontakte, administratives Geschlecht, Geburtsdatum, Adresse, Familienstand, Kommunikation (Sprachen), einen Hausarzt, eine betreuende Organisation und Links zu anderen Patient-Datensätzen für dieselbe Person. Klinische Fakten leben nie im Patient; sie leben in den Ressourcen, die darauf verweisen.

Ein gültiges FHIR R4 Beispiel

Eine gültige FHIR R4 Patient-Ressource benötigt nur resourceType, enthält aber in der Praxis mindestens eine Kennung (identifier) mit einem System (system) und einem Wert (value), einen Namen (name) mit Familien- (family) und Vornamenanteilen (given), ein Geschlecht (gender) und ein Geburtsdatum (birthDate). Das untenstehende Beispiel beansprucht auch das IPS Patient-Profil in meta.profile und fügt Kontaktinformationen (telecom), Adressen (address), bevorzugte Sprache (preferred language), Hausarzt (general practitioner) und verwaltende Organisation (managing organisation) hinzu.

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {"profile": ["http://hl7.org/fhir/uv/ips/StructureDefinition/Patient-uv-ips"]},
  "identifier": [{
    "use": "usual",
    "type": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MR"}]},
    "system": "https://hospital.example.org/mrn",
    "value": "MRN-00012345"
  }],
  "active": true,
  "name": [{"use": "official", "family": "Doe", "given": ["Jane", "Marie"], "prefix": ["Ms"]}],
  "telecom": [{"system": "email", "value": "[email protected]", "use": "home"}],
  "gender": "female",
  "birthDate": "1980-05-23",
  "address": [{"use": "home", "line": ["12 High Street"], "city": "Leeds", "postalCode": "LS1 4AB", "country": "GB"}],
  "communication": [{"language": {"coding": [{"system": "urn:ietf:bcp:47", "code": "en-GB"}]}, "preferred": true}],
  "generalPractitioner": [{"reference": "Practitioner/gp-42"}],
  "managingOrganization": {"reference": "Organization/hospital"}
}

Die wichtigen Elemente

Die für die Interoperabilität wichtigsten Patient-Elemente sind Kennung (identifier) (mit System, Wert und Typ), Name (name) (mit Verwendung, Familien- und Vornamenanteilen), Geschlecht (administrative gender), Geburtsdatum (birthDate), verstorben (deceased), aktiv (active), Kontakt (contact) und Verknüpfung (link). Kennungen und Namen steuern den Abgleich zwischen Systemen, Geschlecht und Geburtsdatum sind administrative Fakten, und link erfasst, wie ein Master Patient Index doppelte Datensätze einer Person verbunden hat.

• identifier ist eine Liste, jede mit einem system (wer sie ausgestellt hat) und einem value. Der type gibt an, um was es sich handelt: MR medizinische Aktennummer, NI nationale Identifikationsnummer, PPN Reisepass, SS Sozialversicherungsnummer, aus der HL7-Tabelle 0203. Ein Patient hat normalerweise mehrere; die MRN eines Krankenhauses und eine nationale ID sind beide gültig, und Systeme gleichen sie ab.
• name ist ebenfalls eine Liste mit einem use: official, usual, nickname, maiden, old. family ist ein einzelner String; given ist eine Liste. Skripte, Transliterationen und Namensreihenfolge sind dem Implementierungsleitfaden des Landes überlassen.
• gender ist das administrative Geschlecht mit vier Werten: male, female, other, unknown. Es ist das, was im Datensatz steht, und wird für Abgleiche und Formulare verwendet. Klinisches Geschlecht, Geschlechtsidentität und Pronomen gehören in Erweiterungen oder Observationen, die FHIR R5 und das Gender Harmony Projekt formalisiert haben.
• birthDate ist ein Datum, optional nur das Jahr oder Jahr und Monat, wenn das genaue Datum unbekannt ist. Eine patient-birthTime-Erweiterung fügt die Uhrzeit für Neugeborene hinzu.
• deceased[x] ist ein Boolean oder ein Datum/Uhrzeit. active false markiert einen Datensatz, der nicht mehr verwendet werden soll (Duplikat, verschoben), ohne ihn zu löschen.
• contact listet Personen auf, die kontaktiert werden sollen (nächste Angehörige, Vormund), mit einem Beziehungscode; sie sind selbst keine Patient-Ressourcen. Ein Elternteil, der ebenfalls Patient ist, ist eine RelatedPerson, die auf beide verweist.
• link verbindet Patient-Datensätze, die dieselbe Person betreffen: replaced-by und replaces nach einer Zusammenführung, refer zum maßgeblichen Datensatz, seealso für einen Datensatz in einem anderen System. So drückt ein Master Patient Index seine Entscheidungen in FHIR aus; siehe Patientenabgleich.

Was nationale Profile hinzufügen

Nationale und internationale FHIR-Profile machen die lose definierte Basis-Patient-Ressource nutzbar, indem sie Elemente als obligatorisch festlegen und länderspezifische Erweiterungen hinzufügen. US Core verlangt Kennung, Name und Geschlecht und fügt Erweiterungen für Rasse, Ethnizität und Geburtsgeschlecht hinzu; das IPS Patient-Profil verlangt Name, Geschlecht und Geburtsdatum; nationale Profile definieren Kennungssysteme und Adressformate.

Die Basisressource macht fast alles optional. Profile machen sie nutzbar:

Ein Datensatz, der eine Grenze überschreiten soll, muss das Profil auf jeder Seite erfüllen, was in der Praxis bedeutet, sowohl die nationale Identifikationsnummer als auch eine MRN, einen vollständigen offiziellen Namen und ein vollständiges Geburtsdatum mitzuführen. Siehe FHIR Implementierungsleitfäden.

Operationen, die Sie verwenden werden

Die am häufigsten verwendeten FHIR-Operationen für Patienten sind die Suche nach Kennung oder Demografie (GET /Patient mit Parametern für Kennung, Nachname oder Geburtsdatum), die Operation $everything, die den Patienten und alle Ressourcen zurückgibt, die auf ihn verweisen, und $match, die den Abgleichalgorithmus des Servers nach wahrscheinlichen Duplikaten abfragt. Eine $merge-Operation wird in FHIR R5 standardisiert.

• GET /Patient?identifier=https://hospital.example.org/mrn|MRN-00012345 findet einen Patienten anhand der Kennung; ?family=doe&birthdate=1980-05-23 anhand demografischer Daten.
• GET /Patient/{id}/$everything gibt den Patienten und alle Ressourcen zurück, die auf ihn verweisen, paginiert, was die Art und Weise ist, wie ein vollständiger Datensatz exportiert wird.
• $match (wo unterstützt) fragt den Abgleichalgorithmus des Servers nach wahrscheinlichen Duplikaten; $merge wird in R5 standardisiert.

Fehler, die Patientenakten beschädigen

Die Fehler, die FHIR Patient-Datensätze am häufigsten beschädigen, sind die Speicherung einer nationalen ID in der Ressourcen-ID (resource id) anstelle der Kennung (identifier), das Weglassen von identifier.system, sodass Werte aus verschiedenen Krankenhäusern kollidieren, die Eingabe des gesamten Namens in text ohne Familien- und Vornamenanteile, die Verwendung des administrativen Geschlechts für das klinische Geschlecht und die Bearbeitung eines zusammengeführten Datensatzes an Ort und Stelle anstatt der Verknüpfung und Deaktivierung.

• Die nationale ID in id zu setzen. Die Ressourcen-id gehört dem Server und kann beim Import geändert werden; Identifier gehören in identifier.
• Ein name mit allem in text und ohne family/given, sodass Suchen nach Nachnamen fehlschlagen.
• gender für das klinische Geschlecht zu verwenden oder auf unknown zu setzen, weil das Formular kein Feld hatte.
• Fehlendes identifier.system, sodass Werte von MRN-1 zweier Krankenhäuser kollidieren.
• Einen Patient vor Ort zu bearbeiten, wenn eine Zusammenführung stattgefunden hat, anstatt zu verknüpfen und zu deaktivieren.

In Anpheros

Anpheros stellt jede Person, den Kontoinhaber und jedes Familienprofil als FHIR Patient-Ressource auf der Anpheros Platform dar, und jeder Datensatz, den eine Klinik über die API hinzufügt, verweist auf diesen Patienten. Klinik-Kennungen werden als zusätzliche Kennungen mit dem eigenen System der Klinik beibehalten, und die Demografie, die eine Person eingibt, bleibt eine administrative Datengrundlage, aus der keine klinischen Rückschlüsse gezogen werden.

Wenn eine Klinik ihre eigene Kennung sendet, wird diese als zusätzliche identifier mit dem System der Klinik gespeichert, sodass dieselbe Person von beiden Seiten gefunden werden kann. Die Demografie, die die Person in der App eingegeben hat, sind der usual Name und administrative Daten; der Datensatz zieht daraus niemals klinische Rückschlüsse.

Verwandte Seiten

• Patientenabgleich und der Master Patient Index
• FHIR Implementierungsleitfäden
• FHIR Encounter erklärt
• FHIR Condition erklärt
• FHIR Suche erklärt
• Patientenbeispiel auf der Entwicklerseite

Quellen

• HL7 FHIR R4: Patient
• HL7 FHIR R4: Patient $everything
• HL7 Terminologie: Identifier-Typ-Codes (v2-0203)
• HL7 US Core: Patientenprofil
• HL7 IPS: Patientenprofil

Häufige Fragen

Ist Patient dasselbe wie Person in FHIR?

Nein. Person ist eine administrative Ressource, die dieselbe menschliche Person über verschiedene Rollen hinweg verknüpft (hier ein Patient, dort ein Praktiker, woanders eine RelatedPerson). Klinische Ressourcen verweisen auf Patient, niemals auf Person.

Wo werden Allergien und Zustände gespeichert?

In AllergyIntolerance- und Condition-Ressourcen, die auf den Patient verweisen. Patient selbst enthält nur administrative Daten.

Wie erfasse ich ein Neugeborenes ohne Namen?

Mit einem Namen, dessen Verwendung temporary oder leer ist, einem birthDate mit der patient-birthTime-Erweiterung und einem link zum Datensatz der Mutter über RelatedPerson oder die patient-mothersMaidenName-Erweiterung, wie nationale Profile es vorsehen.

Kann eine Patient-Ressource von zwei Krankenhäusern gemeinsam genutzt werden?

Jedes System behält seine eigene Patient-Ressource mit seiner eigenen ID; sie teilen Identifier (eine nationale ID) und können die Datensätze verknüpfen. Der Abgleich über Systeme hinweg ist die Aufgabe eines Master Patient Index, nicht der Ressource.

Anpheros Platform

Kostenlos in der Sandbox testen

Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.

Kostenlose Sandbox anlegenEntwickler-Guides lesen →

Kostenlos · 30 synthetische Patienten · keine Karte

Erstellt von

Das Anpheros-Team

Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.

Über Anpheros →