Leitfaden Basis DE (R4)

Leitfaden Basis DE (R4)
Home
Über diesen Leitfaden
Grundlagen
Anwendungshinweise
Ressourcen-Paket
Ableitung eigener Profile von den Basisprofilen
Nicht profilierte Ressourcen, zukünftige Erweiterung
Beispiele
Ressourcen
Patient
Identifikator
organisationsinterner Patienten-Identifier (PID)
gesetzliche Krankenversichertennummer (10-stellige KVID)
private Krankenversichertennummer
Name
Geschlecht
Adresse
Personenstand
Geburtsdatum
Personen in Gesundheitsberufen
Lebenslange Arztnummer (LANR)
Zahnarztnummer (ZANR)
Allergien und Intoleranzen
Beobachtungen, Messungen
VitalParameter
Atemfrequenz
Blutdruck
BMI
Herzfrequenz
Körpergewicht
Körpergröße
Körpertemperatur
Kopfumfang
Sauerstoffsättigung
Anamnese
Raucherstatus
Alkoholkonsum
Schwangerschaft
Schwangerschaftsstatus
Erwarteter Geburtstermin
Schwangerschafts-Historie
Labor
Pflegegrad
Diagnosen
Diagnose-Typen und Rangfolgen
ICD-10-GM (Profil)
Condition.code
Postkoordinierte ICD-Codes
Diagnosesicherheit
Beispiel: Diagnosesicherheit: "Zustand nach"
Beispiel: einfacher ICD-Code
Beispiel: ICD-Code mit Ausrufezeichen-Notation
Beispiel: ICD-Code mit Kreuz-Stern-Notation
Prozeduren
OPS
Procedure.code
Dokumente
Medikation
Normgröße
Fragebögen und Formulare
Terminologie
Nomenklatur der Ressourcen
Codesystem-Versionen
Platzhalter-Codesysteme
Valuesets
Geschlechtskennzeichen
Pflegegrad
ValueSets von IHE Deutschland
Codesysteme
KBV-Schlüsseltabellen
Namensräume
lokale Namensräume
nationale Namensräume
Codesystem-Übersetzungen
administrative-gender
marital-status
LOINC

lokale Namensräume

Namensräume dienen dem Zweck, die Überschneidung von Identifikatoren über Systemgrenzen hinweg zu verhindern. Sie werden häufig einrichtungsintern, bzw. systembezogen definiert, und dann nach extern kommuniziert zum Beispiel der lokale Patient-Identifier oder die von einem System vergebene Auftragsnummer.

Solche Namensräume sollten gemäß der FHIR-Spezifikation als URLs definiert werden. Dabei gilt zu beachten:

  • Die Basis-URL sollte stets die Domäne der definierenden Organisation sein, z.B.:
http://meine-Organisation.de
  • Die weiteren Bestandteile der URL sollten sicherstellen, dass sich verschiedene von dieser Organisation vergebene Identifier nicht überschneiden, z.B.:
http://meine-Organisation.de/NamingSystem/patienten-identifier
http://meine-Organisation.de/NamingSystem/mitarbeiter-identifier
http://meine-Organisation.de/NamingSystem/laborauftrag-identifier

bzw. wenn in der Organisation mehrere patientenführende Systeme zum Einsatz kommen:

http://meine-Organisation.de/NamingSystem/system-a/patienten-identifier
http://meine-Organisation.de/NamingSystem/system-b/patienten-identifier
  • Software-Hersteller sollten beachten, dass hier stets die Domäne des jeweiligen Kunden verwedet werden sollte, da die Domäne des Herstellers keine Eindeutigkeit über mehrere Installationen hinweg gewährleisten kann.
  • Wenn für das Projekt, in dessen Rahmen der Namensraum definiert wurde, ein Implementierungsleitfaden veröffentlich wird (z.B.: auf http://simplifier.de), ist es sinnvoll, die Namensräume als NamingSystem-Ressource zu definieren und die URL mit Hilfe eines Redirects auf die Spezifikation dieser Resource aufzulösen. Dafür kann es hilfreich sein, einen weiteren Pfad in die URL einzufügen, der als Basis für den Redirect auf alle Resourcen des Leitfadens verwendet werden kann:
http://meine-Organisation.de/fhir/NamingSystem/patienten-identifier
http://meine-Organisation.de/fhir/NamingSystem/mitarbeiter-identifier
http://meine-Organisation.de/fhir/NamingSystem/laborauftrag-identifier
  • obwohl URLS aufgrund der besseren Lesbarkeit und dem Vorteil, unmittelbar auf die Definition verweisen zu können, grundsätzlich vorzuziehen sind, ist alternativ auch die Verwendung von OIDs möglich:
urn:oid:1.2.3.4.5.6.7