Profil Arztbrief mit Befund
Ziel
Der Patient hat ein Anrecht und ein Interesse daran, seine Arztbriefe zu erhalten. Die Weitergabe von Befunden ist im Sinne der Patientensicherheit und Ressourcensparsamkeit sinnvoll und notwendig. Gleichzeitig ist eines der Ziele, die Datenweitergabe auch elektronisch lesbar zu gestalten, d.h. dass auch Inhalte verstanden werden können, da diese annotiert sind.
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 "Dokumentenaustausch Stufe 4" als Basis verwendet.
- https://simplifier.net/isik-dokumentenaustausch-v4/isikdokumentenmetadaten (DocumentReference)
ZIV-Profil Laborwerte
Spalten "Klinik" und "Patient" geben die Relevanz für die jeweilige Partei an und ob eine Änderung möglich sein so
Name | Flags | Card. | Type | Description & Constraints | Klinik | Patient |
---|---|---|---|---|---|---|
1. masterIdentifier | 1..1 | Identifier | Nicht relevant | |||
2. identifier | 0..* | Identifier | Business identifier for this medication | Nicht relevant | ||
3. status | 1..1 | code | Nicht relevant → Nur Freigegebenes wird angezeigt | |||
4. docStatus | 0..1 | code | Nicht relevant | |||
5. type | 1..1 | CodeableConcept | Nicht relevant | |||
6. category | 0..1 | CodeableConcept | Nicht relevant | |||
7. subject | 1..1 | Reference | Einsehbar | |||
8. date | 0..1 | instant | Einsehbar | |||
9. author | 0..* | Reference | Nicht relevant | |||
10. authenticator | 0..1 | Reference | Nicht relevant | |||
11. relatesTo | 0..* | Backbone | Nicht relevant | |||
12. description | 1..1 | string | Nicht relevant | |||
13. securityLabel | 1..* | CodeableConcept | Nicht relevant | |||
14. content | 1..1 | Backbone | Änderbar | Einsehbar | ||
15. context | 1..1 | Backbone | Nicht relevant |
Beispiel-FHIR-Ressource
{ "resourceType": "DocumentReference", "id": "dok-beispiel-server", "meta": { "security": [ { "code": "HTEST", "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason" } ], "profile": [ "https://gematik.de/fhir/isik/StructureDefinition/ISiKDokumentenMetadaten" ] }, "masterIdentifier": { "system": "urn:ietf:rfc:3986", "value": "urn:oid:1.2.840.113556.1.8000.2554.58783.21864.3474.19410.44358.58254.41281.46340" }, "type": { "coding": [ { "system": "http://dvmd.de/fhir/CodeSystem/kdl", "code": "PT130102", "display": "Molekularpathologiebefund" }, { "system": "http://ihe-d.de/CodeSystems/IHEXDStypeCode", "code": "PATH", "display": "Pathologiebefundberichte" } ] }, "category": [ { "coding": [ { "system": "http://ihe-d.de/CodeSystems/IHEXDSclassCode", "code": "BEF", "display": "Befundbericht" } ] } ], "status": "current", "description": "Molekularpathologiebefund vom 31.12.21", "subject": { "reference": "Patient/PatientinMusterfrau" }, "securityLabel": [ { "coding": [ { "code": "N", "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality" } ] } ], "content": [ { "attachment": { "contentType": "application/pdf", "url": "https://mein-Dokumentenserver/dokumente/1.2.840.113556.1.8000.2554.58783.21864.3474.19410.44358.58254.41281.46340.pdf", "language": "de", "creation": "2020-12-31T23:50:50-05:00" }, "format": { "code": "urn:ihe:iti:xds:2017:mimeTypeSufficient", "system": "http://ihe.net/fhir/ihe.formatcode.fhir/CodeSystem/formatcode", "display": "mimeType Sufficient" } } ], "context": { "facilityType": { "coding": [ { "code": "KHS", "system": "http://ihe-d.de/CodeSystems/PatientBezogenenGesundheitsversorgung", "display": "Krankenhaus" } ] }, "practiceSetting": { "coding": [ { "code": "ALLG", "system": "http://ihe-d.de/CodeSystems/AerztlicheFachrichtungen" } ] }, "encounter": [ { "reference": "Encounter/BeispielBesuch" } ] } }
Organisatorische Regelungen für die Befüllung des FHIR-Profils
Herausforderungen
- Die Freigabe von Arztbriefen und Befunden muss nach ethischen Gesichtspunkten abgewägt werden, d.h. ein Patient sollte nicht von seiner lebensverändernden Erkrankung über ein Popup in einer App informiert werden. Hierfür müssen Freigabeprozesse im Krankenhaus erstellt werden, die auch das Recht des Patienten an seinen Information mit berücksichtigen.
- Es gibt eine große Menge an möglichen zu erhebenden Befunden. Bisher sind allgemein nur wenige (wenn auch häufige) Befunde in Ansätzen spezifiziert, d.h. sie können semantisch annotiert und verstanden werden (z.B. Pathologiebefund und Radiologiebefund). Eine vollständige Abdeckung aller Befundtypen und Befundausprägungen ist jedoch nicht möglich. Deshalb wird stets eine Freitextübermittlung Bestandteil jedes Befundtyps sein. Es wird trotzdem angestrebt, möglichst viele Befundtypen zu spezifizieren.
- Dokumente oder Befunde können in verschiedenen Sprachen verfügbar sein (z.B. Landessprache des Krankenhauses, Muttersprache des Patienten, einfache Sprache), ggf. existieren verschiedene Versionen des gleichen Dokumentes.
- Dokumentrevisionen: Es können inhaltliche Änderungen an Briefen/Befunden entstehen, bzw. Nachbefunde erzeugt werden.
Lösungen
An jedem Krankenhaus muss eine Projektgruppe einen Freigabeprozess sowohl für Arztbriefe und Befunde erstellen. An den meisten Krankenhäusern sollte zumindest für den Arztbrief bereits ein solcher Prozess existieren. Hierbei ist zu beachten:
- Die Inhaltliche Freigabe (d.h. Korrektheit des Befundes) impliziert nicht die ethische Freigabe (d.h. Patient wird von einem Menschen über seinen Befund informiert)
- Welche Personengruppe kann eine Freigabe erstellen? (Assistenzarzt vs. Oberarzt?)
- Eine Freigabe muss ggf. für jede Revision erneut erfolgen
Radiologie und Pathologiebefunde sind bereits in der MII (vorläufig) spezifiziert
weitere Befundspezifikationen werden in Austausch mit Stakeholdern, z.B. der MII weiterspezifiziert.
Die Sprachversion wird im FHIR-Element hinterlegt (
Resource.language
, vgl. https://hl7.org/fhir/R4/valueset-all-languages.html). Eine Verknüpfung verschiedener Sprachversionen des gleichen Dokumentes geschieht überDocumentReference.relatesTo
.Die Revision von Dokumenten ist möglich über
DocumentReference.status
, die Reihenfolge der Revisionen ist über das Dokumentendatum möglich.
Validierungsregeln
Technische FHIR-Validierung
Die Validierung einer gesendeten FHIR-Ressource erfolgt gegenüber dem ZIV-Profil, indem die Ressourcen-Struktur auf ZIV-Konformität überprüft wird. Konkret muss überprüft werden, ob alle Datenelemente mit Pflichtfeld oder mustSupport-Flag in der Ressource vorhanden sind oder ob nicht zugelassene Datenelemente existieren.
Die Validierung erfolgt via Simplifier, da darüber das Profil spezifiziert ist.
https://hapifhir.io/hapi-fhir/docs/validation/introduction.html
Organisatorische Validierung
Solange die o.g. Freigabeprozesse eingehalten werden, ist keine organisatorische Validierung notwendig.
Die Klinik muss dafür Sorge tragen, dass nur Briefe und Befunde an die Schnittstelle übermittelt werden, die explizit freigegeben und ggfs. vorher direkt mündlich mitgeteilt wurden.