Skip to content

Commit

Permalink
fix: modified patient merge to reflect the R5 backport
Browse files Browse the repository at this point in the history
  • Loading branch information
patrick-werner committed Feb 26, 2024
1 parent 2db4509 commit d2d8633
Show file tree
Hide file tree
Showing 67 changed files with 584 additions and 341 deletions.
3 changes: 1 addition & 2 deletions .devcontainer/Dockerfile
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,7 @@ FROM mcr.microsoft.com/devcontainers/base:alpine-3.18
# Setzen der Umgebungsvariablen
ENV FIRELY_TERMINAL_VERSION=3.1.0
ENV JAVA_VALIDATOR_VERSION=6.0.11
ENV SUSHI_VERSION=3.5.0

ENV SUSHI_VERSION=3.7.0
# Installieren der notwendige Tools
# Add Microsoft's .NET SDK repository and install .NET SDK
RUN wget https://dot.net/v1/dotnet-install.sh \
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
## Subscription patient-merge [(R5 Backport Subscription)](https://hl7.org/fhir/uv/subscriptions-backport/components.html)

---
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
### Anmerkungen zu den Must-Support-Feldern

### `Subscription.status`

**Bedeutung:** Der Status der Subscription, der den Serverstatus der Subscription angibt. Neue Subscriptions werden immer mit dem Status `requested` an den Server übergeben. Der Server ändert im Anschluss den status auf `active` oder im Fehlerfall auf `error`.

**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)

### `Subscription.reason`

**Bedeutung:** Beschreibung wieso diese Subscription erstellt wurde.

**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)

### `Subscription.category`

**Bedeutung:** Canonical URL des Subscription-Topics, aktuell nur unterstützt: https://gematik.de/fhir/isik/SubscriptionTopic/patient-merge

**Hinweise:** Siehe [Subscriptions R5 Backport](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription.html)

### `Subscription.type`

**Bedeutung:** Der Typ des Kommunikationskanals, über den Subscription-Benachrichtigungen gesendet werden sollen.

**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)

### `Subscription.endpoint`

**Bedeutung:** Adresse des Kommunikationskanals/ Endpunkts an den Subscription-Benachrichtigungen gesendet werden sollen. Dies ist nur für rest-hook Subscriptions relevant.

**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)

### `Subscription.payload`

**Bedeutung:** Format in dem Subscription Notifications versendet werden sollen (JSON oder XML)

**Hinweise:** Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)

### `Subscription.payload.extension[content]`

**Bedeutung:** Welcher Ressourceninhalt in der Nutzlast der Benachrichtigung geliefert werden soll. Zur Auswahl stehen eine leere Nutzlast (`empty`), nur die Ressourcenid (`id-only`) oder der gesamte Inhalt der Ressource (`full-resource`).

**Hinweise:** Siehe [Extension: Backport R5 Subscription Payload Content Information](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-payload-content.html)

### `Subscription.header`

**Bedeutung:** http-Header welcher dazu genutzt werden kann einen Authorization-header zu setzen. Dies ist nur für rest-hook Subscriptions relevant.

**Hinweise:** ACHTUNG: dieses Datenfeld muss bei READ-Interaktionen maskiert werden! Siehe [R4 Subscriptions](https://hl7.org/fhir/R4/subscription.html)
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
### Beispiele

#### Subscription

{{json:PatientMergeSubscriptionExample}}

#### SubscriptionNotification-Bundle

{{json:SubscriptionNotificationBundleExample}}

#### Patientenobjekte
"Quell" Patienten-Ressource:
{{json:DorisQuelle}}

und

"Ziel" Patienten-Ressource:
{{json:DorisZiel}}

Mittels eines Patient-merge-Vorgangs wird die "Ziel" Patienten-Ressource ausgewählt und beide Ressourcen entsprechend modifiziert:

Resultierende Patientin:
{{json:DorisResultat}}

---
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
### Interaktionen

Für die Ressource Subscription MUSS die REST-Interaktion "READ", "CREATE", "UPDATE", "DELETE" implementiert werden.

---
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
### Kompatibilität

Das Profil PatientMergeSubscription basiert auf dem [Backport-Subscription Profil](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription.html).
Der [SubscriptionStatus](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription-status-r4.html), sowie das [Subscription Notification Bundle](https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription-notification-r4.html) werden unverändert direkt aus dem [Subscriptions R5 Backport IG](https://hl7.org/fhir/uv/subscriptions-backport/index.html) genutzt.

---


Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
## Motivation

Duplizierte Patientendatensätze innerhalb eines patientenführenden Systems treten im betrieblichen Alltag immer wieder auf. Diese Duplikate werden nach dem Bekanntwerden auf ein Patientenobjekt zusammengeführt (gemerged).

Um als Subsystem über ein Patienten-Merge-Event informiert zu werden, wird der FHIR Subscription Mechanismus gemäß der FHIR R5 Spezifikation genutzt.

---
11 changes: 11 additions & 0 deletions ImplementationGuide/markdown/Subscription/Subscription_Profil.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
## Profil

@```
from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription' select Name: name, Canonical: url
```
{{tree:https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription, hybrid}}
@``` from StructureDefinition where url = 'https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription' for differential.element.constraint select key, severity, human, expression```

---
Original file line number Diff line number Diff line change
Expand Up @@ -15,44 +15,47 @@ Ein externes Starten eines Patient merge - bspw. durch die [$patient-merge Opera
## Gemergte Patienten Instanz
Wenn ein Patient merge geschieht, gelten für das patientenführende System folgende Anforderungen:

**REQ_BAS_PAT-MER-010**: Das patientenführende System MUSS sicherstellen, dass ein externer Client, dem ein lesender Zugriff auf eine Patienten-Ressource erteilt wurde, auch nach einem Patient merge auf diese obsolete Ressource zugreifen kann, um eine Abfrage auf die resultierende Ressource mittels .link-Elements zu ermöglichen. Dies MUSS solange gelten, bis das patientenführende System sicherstellen kann - z.B. mittels eines vereinbarten Workflows -, dass alle Abfragen des Clients, die potentiell auf die obsolete Ressource zielen könnten, in Zukunft auf die resultierende Ressource zielen.
**REQ_BAS_PAT-MER-010**: Das patientenführende System MUSS sicherstellen, dass alle auf die obsolete Ressource referenzierenden FHIR-Ressourcen nach dem merge auf die resultierende Ressource referenzieren.

### Datenelemente der obsoleten Patienten-Ressource
### Die obsolete Patienten-Ressource

**REQ_BAS_PAT-MER-011**: Das patientenführende System MUSS nach einem merge die Elemente der obsoleten Ressource folgendermaßen befüllen, um sicherzustellen, dass die obsolete Ressource auf die resultieren Ressource verweist und das die obsolete Ressource als inaktiv gekennzeichnet ist:
**REQ_BAS_PAT-MER-011**: Das patientenführende System KANN die obsolete Patienten-Ressource weiter vorhalten. Ein Entfernen der obsoleten Ressource ist ebenfalls erlaubt.

Soll die obsolete Ressource nach einem merge weiter vorgehalten werden MÜSSEN die Elemente der obsoleten Ressource folgendermaßen befüllt werden, um sicherzustellen, dass die obsolete Ressource auf die resultieren Ressource verweist und das die obsolete Ressource als inaktiv gekennzeichnet ist:
- .active = false
- .link.other = Reference(auf “resultierenden” Patient)
- .link.type = “replaced-by”

### Datenelemente der resultierenden Patienten-Ressource

**REQ_BAS_PAT-MER-012**: Das patientenführende System MUSS nach einem merge die Elemente der resultierende Ressource folgendermaßen befüllen, um sicherzustellen, dass die resultierende Ressource auf die obsolete Ressource verweist:
- .link.other = Reference(auf “obsoleten” Patient)
- .link.type = “replaced-by”

## Beispiele
Die Patient merge Notification kann folgendermaßen illustriert werden: es existieren fälschlicherweise zwei Instanzen, die sich lediglich hinsichtlich der organisationsspezifischen Patienten-ID unterscheiden.
Diese sind:
Diese sind:

"Quell" Patienten-Ressource:
"Quell" Patienten-Ressource:
{{json:DorisQuelle}}

und

"Ziel" Patienten-Ressource:
"Ziel" Patienten-Ressource:
{{json:DorisZiel}}

Mittels eines Patient-merge-Vorgangs wird die "Ziel" Patienten-Ressource ausgewählt und beide Ressourcen entsprechend modifiziert:

Obsolete Patienten-Ressource:
{{json:DorisObsolet}}

Resultierende Patientin:
{{json:DorisResultat}}

### Datenelemente der resultierenden Patienten-Ressource

**REQ_BAS_PAT-MER-012**: Das patientenführende System MUSS nach einem merge die Elemente der resultierenden Ressource folgendermaßen befüllen, um sicherzustellen, dass die resultierende Ressource auf die obsolete Ressource verweist:
- .link.other = Reference.identifier (logische Referenz mittels Patientennummer Identifier auf “obsoleten” Patient)
- .link.type = “replaces”

## Patient merge Notification
**REQ_BAS_PAT-MER-020**: Das patientenführende System MUSS einen Client mittels FHIR Subscription über einen erfolgten Patienten merge informieren können.
**REQ_BAS_PAT-MER-020**: Das patientenführende System MUSS einen Client mittels FHIR Subscription über einen erfolgten Patienten merge informieren können. Dieser Mechanismus basiert auf dem [Subscriptions R5 Backport IG](https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/channels.html) und nutzt das Konzept der "Topic-Based Subscription" aus FHIR R5.

Hier wird aktuell geklärt ob dies mittels r4 Subscription oder R5 backport topic-based Subscription erfolgen soll.
Hierfür wurde das Subscription Topic: *https://gematik.de/fhir/isik/SubscriptionTopic/patient-merge* definiert.

Das patientenführende System MUSS den Support dieser Subscription inneralb des CapabilityStatements bekannt geben.

## Client-System
**REQ_BAS_PAT-MER-021**: Client-Systeme MÜSSEN den Status einer gecachten Patienteninstanz vor der Interaktion mit einem patientenführenden System per READ auf das Patientenobjekt überprüfen.
Sollte das Patientenobjekt nicht mehr bereitstehen, oder hat den status `active=false` muss das Patientenobjekt mittels Suche auf einen bekannten & stabilen Identifier neu geladen werden.
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ usecase (UC05: Datenbereinigung) as UC05
usecase (UC06: Konfliktlösung) as UC06
usecase UC07 as "UC07: Meldung von Dateninkonsistenzen"
usecase UC08 as "UC08: Neu refrenzieren"
    

}

:Mitarbeiterin:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
"id": "AbrechnungsfallAmbulant",
"meta": {
"profile": [
"https://gematik.de/fhir/isik/Basismodul/StructureDefinition/ISiKAbrechnungsfall"
"https://gematik.de/fhir/isik/StructureDefinition/ISiKAbrechnungsfall"
]
},
"identifier": [
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
"id": "ISiKBundle-Example",
"meta": {
"profile": [
"https://gematik.de/fhir/isik/Basismodul/StructureDefinition/ISiKBerichtBundle"
"https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtBundle"
]
},
"type": "document",
Expand All @@ -27,7 +27,7 @@
"id": "composition-blutdruck",
"meta": {
"profile": [
"https://gematik.de/fhir/isik/Basismodul/StructureDefinition/ISiKBerichtSubSysteme"
"https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtSubSysteme"
]
},
"status": "final",
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,116 @@
{
"resourceType": "Bundle",
"id": "SubscriptionNotificationBundleExample",
"type": "history",
"entry": [
{
"fullUrl": "urn:uuid:9bb6fcbd-8391-4e35-bd4c-620a2db47af0",
"resource": {
"resourceType": "Parameters",
"id": "SubscriptionNotification",
"meta": {
"profile": [
"http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-subscription-status-r4"
]
},
"parameter": [
{
"name": "subscription",
"valueReference": {
"reference": "Subscription/1"
}
},
{
"name": "topic",
"valueCanonical": "https://gematik.de/fhir/isik/SubscriptionTopic/patient-merge"
},
{
"name": "status",
"valueCode": "active"
},
{
"name": "type",
"valueCode": "event-notification"
},
{
"name": "events-since-subscription-start",
"valueString": "1"
},
{
"name": "notification-event",
"part": [
{
"name": "event-number",
"valueString": "1"
},
{
"name": "timestamp",
"valueDate": "2024-02-22"
},
{
"name": "focus",
"valueReference": {
"reference": "Patient/DorisQuelle"
}
}
]
}
]
}
},
{
"fullUrl": "http://example.com/fhir/Patient/DorisQuelle/_history/2",
"resource": {
"resourceType": "Patient",
"id": "DorisQuelle",
"meta": {
"profile": [
"https://gematik.de/fhir/isik/StructureDefinition/ISiKPatient"
]
},
"identifier": [
{
"type": {
"coding": [
{
"code": "MR",
"system": "http://terminology.hl7.org/CodeSystem/v2-0203"
}
]
},
"system": "https://fhir.krankenhaus.example/sid/PID",
"value": "654321"
},
{
"system": "http://fhir.de/sid/gkv/kvid-10",
"type": {
"coding": [
{
"code": "GKV",
"system": "http://fhir.de/CodeSystem/identifier-type-de-basis"
}
]
},
"value": "A123456789"
}
],
"name": [
{
"use": "official",
"family": "Duplikat",
"given": [
"Doris"
]
}
],
"active": false,
"gender": "female",
"birthDate": "1964-08-12"
},
"request": {
"method": "PUT",
"url": "Patient/DorisQuelle"
}
}
]
}
Loading

0 comments on commit d2d8633

Please sign in to comment.