Profil Person
Ziel
Eindeutiger Identifikator für den einzelnen Patienten. Es ist die Grundlage für Verknüpfung sämtlicher sonstigen Ressourcen. Er beinhaltet Basisinformationen zum Patienten, wie z.B. Name, Geburtsdatum, aktuelle Adresse.
Veröffentlichung | |
---|---|
Datum | 30.07.2025 |
Version | 1.0.0 |
Status | Active |
Nutzungsraum | DE |
Verwendetes FHIR-Profil
Für die Profilierung wird die ISiK Spezifikation "Basis Stufe 4" verwendet.
ISiK-Profile sind in beide Richtungen kompatibel zu ZIV-Profilen. Ein ZIV-Profil ist kompatibel zu MII-Profilen, MII-Profile sind nicht notwendigerweise kompatibel zu ZIV-Profilen.
ZIV-Profil Person
Name | Flags | Card. | Type | Description & Constraints | Klinik | Patient |
---|---|---|---|---|---|---|
1. identifier | S | 1..* | Identifier | Business identifier for this medication | nicht relevant | nicht relevant |
2. active | S | 0..1 | boolean | nicht relevant | nicht relevant | |
3. name | S | 1..* | HumanName | einsehbar | einsehbar | |
4. telecom | 0..* | ContactPoint | einsehbar | einsehbar | ||
5. gender | S | 1..1 | code | einsehbar | einsehbar | |
6. birthdate | S | 1..1 | date | einsehbar | einsehbar | |
7. deceased | S | 0..* | einsehbar | nicht relevant | ||
7.1. deceasedBoolean | 0..1 | boolean | einsehbar | nicht relevant | ||
7.2. deceasedDateTime | 0..1 | dateTime | einsehbar | nicht relevant | ||
8. address | S | 0..* | Address | einsehbar | einsehbar | |
9. martialStatus | 0..1 | CodeableConcept | einsehbar | nicht relevant | ||
10. multipleBirth[x] | 0..1 | nicht relevant | nicht relevant | |||
10.1. multipleBirthBoolean | 0..1 | boolean | nicht relevant | nicht relevant | ||
10.2. multipleBirthInteger | 0..1 | integer | nicht relevant | nicht relevant | ||
11. photo | 0..* | Attachment | nicht relevant | nicht relevant | ||
12. contact | 0..* | BackboneElement | einsehbar | einsehbar | ||
13. communication | 0..* | BackboneElement | einsehbar | nicht relevant | ||
14. generalPractioner | 0..* | Reference | einsehbar | nicht relevant | ||
15. managingOrganization | 0..1 | Reference | einsehbar | nicht relevant | ||
16. link | S | 0..* | BackboneElement | einsehbar | nicht relevant |
Beispiel-FHIR-Ressource
{ "resourceType": "Patient", "id": "1", "identifier": [ { "use": "usual", "type": { "coding": [ { "code": "MR", "system": "http://terminology.hl7.org/CodeSystem/v2-0203" } ] }, "system": "http://umm.de/fhir/sid/patient", "value": "42285299", "assigner": { "display": "UMM – Universitätsklinikum Mannheim", "identifier": { "system": "http://fhir.de/sid/arge-ik/iknr", "value": "260820569" } } } ], "name": [ { "use": "official", "family": "Mustermann", "given": [ "Max" ] } ], "gender": "male", "birthDate": "1997-10-23", "address": [ { "type": "both", "line": [ "Teststraße 2" ], "city": "Erfurt", "postalCode": "99089", "country": "DE" } ] }
Organisatorische Regelungen für die Befüllung des FHIR-Profils
Herausforderungen
- Welche Felder im KIS sind übertragbar auf FHIR-Ressourcen?
- z.B. werden Email-Adressen häufig in dem Feld "sonstiges" eingegeben, solche Informationen sind aber nicht sinnvoll für ein direktes Mapping und Darstellung in der Patienten-App. z.B.: wenn im Feld sonstiges steht "peter.meier@example.com Patient keine Email schreiben", so sollte dies nicht in der App angezeigt werden
- Patienten können im KIS doppelt angelegt sein.
- Patienten haben mehrere externe Pseudonyme (z.B. von Melderegistern, speziellen klinischen Studien, DiGAs, klinikinterne PROM-Apps).
Lösungen
- Jedes der folgenden Felder muss im KIS eine eindeutige Entsprechung haben und es müssen SOPs definiert werden, wie diese Felder zu befüllen sind: name, gender, birthdate.
- Das Problem mit doppelt angelegten Patienten muss über SOPs klinikintern gelöst werden.
- Im KIS muss eine Möglichkeit bestehen, die entsprechenden Pseudonyme zu verwalten/upzudaten.
Beschreibung eines Anwendungsszenarios
Ein Use Case für die Verwendung des Profils ist zum Beispiel die Registrierung der Stammdaten des Patienten im Rahmen der Aufnahme für eine OP im Krankenhaus. Jeder Patient erhält bei der Aufnahme eine eindeutige Patientennummer (Business Identifier), die bei wiederholten Krankenhausaufenthalten wieder verwendet werden soll.
Beschreibung der Elemente und Implementierungshilfen
Hier finden Sie nochmal eine kurze Erklärung zu einigen der verwendeten Datenelemente:
Person.identifier: unter anderem die Patientennummer (Business Identifier), die zur eindeutigen Identifizierung des Patienten im Krankenhaus dient.
Person.name: Vor- und Nachname des Patienten
Person.birthdate: Geburtsdatum des Patienten
Person.gender: administrative Geschlecht des Patienten
Person.address: aktuelle Adresse des Patienten