From abc7a94c7b6573d4ad8d6a7f72417b530b0d3b2b Mon Sep 17 00:00:00 2001 From: patrick-werner Date: Sun, 17 Mar 2024 09:02:59 +0100 Subject: [PATCH] feat: merged with add-MS-Patient.link-PTDATA-676 --- Material/Patient_merge.md | 554 ------------------ .../Patient-merge_Use-Case-Diagram.iuml | 35 -- ...ce-Diagram-Patient-Merge-Notification.puml | 16 - Material/images/src/plantuml/infomodel.puml | 251 -------- .../src/plantuml/infomodel_condobs.puml | 224 ------- .../images/src/plantuml/resourcediagram.puml | 161 ++--- Material/images/src/plantuml/usecases.puml | 2 +- Resources/fsh-generated/fsh-index.json | 114 +++- Resources/fsh-generated/fsh-index.txt | 36 +- ...nt-ISiKCapabilityStatementBasisServer.json | 97 +++ ...ructureDefinition-ISiKAbrechnungsfall.json | 12 - ...StructureDefinition-ISiKAlkoholAbusus.json | 32 - ...nition-ISiKAllergieUnvertraeglichkeit.json | 17 - .../StructureDefinition-ISiKAngehoeriger.json | 17 - ...StructureDefinition-ISiKBerichtBundle.json | 22 - ...ctureDefinition-ISiKBerichtSubSysteme.json | 27 - .../StructureDefinition-ISiKBinary.json | 7 - .../StructureDefinition-ISiKCodeSystem.json | 22 - .../StructureDefinition-ISiKDiagnose.json | 32 - ...ion-ISiKKontaktGesundheitseinrichtung.json | 22 - ...StructureDefinition-ISiKLebensZustand.json | 32 - .../StructureDefinition-ISiKPatient.json | 29 +- ...finition-ISiKPersonImGesundheitsberuf.json | 22 - .../StructureDefinition-ISiKProzedur.json | 22 - ...StructureDefinition-ISiKRaucherStatus.json | 32 - ...ngerschaftErwarteterEntbindungstermin.json | 32 - ...Definition-ISiKSchwangerschaftsstatus.json | 33 +- .../StructureDefinition-ISiKStillstatus.json | 32 - .../StructureDefinition-ISiKValueSet.json | 22 - ...SiKVersicherungsverhaeltnisGesetzlich.json | 32 - ...KVersicherungsverhaeltnisSelbstzahler.json | 32 - .../StructureDefinition-PlannedEndDate.json | 7 - .../StructureDefinition-PlannedStartDate.json | 7 - ...Definition-patient-merge-subscription.json | 12 - Resources/input/fsh/ISiKPatient.fsh | 4 +- 35 files changed, 267 insertions(+), 1783 deletions(-) delete mode 100644 Material/Patient_merge.md delete mode 100644 Material/images/diagrams/Patient-merge_Use-Case-Diagram.iuml delete mode 100644 Material/images/diagrams/Sequence-Diagram-Patient-Merge-Notification.puml delete mode 100644 Material/images/src/plantuml/infomodel.puml delete mode 100644 Material/images/src/plantuml/infomodel_condobs.puml diff --git a/Material/Patient_merge.md b/Material/Patient_merge.md deleted file mode 100644 index 2c1c11e5b..000000000 --- a/Material/Patient_merge.md +++ /dev/null @@ -1,554 +0,0 @@ -# Konzept Patient merge (WIP) - -## Table of Contents -- [Zusammenfassung](#zusammenfassung) -- [1. Motivation und Hintergrund](#1-motivation-und-hintergrund) -- [2. Ziele](#2-ziele) -- [3. Stakeholder und User](#3-stakeholder-und-user) -- [4. Randbedingungen](#4-randbedingungen) - - [4.1. Technische Randbedingungen](#41-technische-randbedingungen) - - [4.2. Organisatorische Randbedingungen](#42-organisatorische-randbedingungen) - - [4.3. Konventionen](#43-konventionen) -- [5. Kontextabgrenzung](#5-kontextabgrenzung) - - [5.1. User und Systeme](#51-user-und-systeme) - - [5.2. Kontext der Festlegung](#52-kontext-der-festlegung) - - [5.3. Patient Data Journey](#53-patient-data-journey) -- [6. Lösungsstrategie](#6-lösungsstrategie) - - [6.1. Bestehende Standards](#61-bestehende-standards) - - [6.2. merge (und match)](#62-merge-und-match) - - [6.3. merge-inform](#63-merge-inform) -- [7. User Stories und Use Cases](#7-user-stories-und-use-cases) - - [7.1. User Stories - Business](#71-user-stories---business) - - [7.2. US-01: Terminbuchung Patientenportal](#72-us-01-terminbuchung-patientenportal) - - [7.3. US-02: händische Patientenaufnahme](#73-us-02-händische-patientenaufnahme) - - [7.4. US-03: Anlegen in Subsystem](#74-us-03-anlegen-in-subsystem) - - [7.5. Fazit zu User Stories](#75-fazit-zu-user-stories) - - [7.6. Use Cases - Technisch](#76-use-cases---technisch) - - [7.6.1. UC-01: Patient-merge](#761-uc-01-patient-merge) - - [7.6.2. UC-02: match (Patientendatenabgleich)](#762-uc-02-match-patientendatenabgleich) - - [7.6.3. UC-03: Inform about merge](#763-uc-03-inform-about-merge) - - [7.6.4. UC-XY](#764-uc-xy) -- [8. Priorisierte Liste der Use Cases nach Bedarf](#8-priorisierte-liste-der-use-cases-nach-bedarf) -- [9. Priorisierte Liste weiterer Bedarfe an die Spezifikation](#9-priorisierte-liste-weiterer-bedarfe-an-die-spezifikation) -- [10. Annex I - Patient Journey](#10-annex-i---patient-journey) -- [11. Annex II - Patient Data Journey](#11-annex-ii---patient-data-journey) - -## Zusammenfassung -Es besteht aus Sicht der befragten Stakeholder der Bedarf nach einer AG zum Patientendatenzusammenführung (Patient merge) im Kontext von ISiK. -Derzeitiges Umsetzungsziel der AG im Rahmen der ISIK Ausbaustufe 4 ist die fachliche Konsolidierung und Spezifikation zu einer Interaktion im FHIR Kontext, die über einen geschehenen Patient merge informiert ('Patient merge Notification' - zum benannten Umsetzungsziel siehe [7.6.3. UC-03: Inform about merge](#763-uc-03-inform-about-merge) und zur Priorisierung weiterer Bedarfe siehe [8. Priorisierte Liste der Use Cases nach Bedarf](#8-priorisierte-liste-der-use-cases-nach-bedarf)). - -## 1. Motivation und Hintergrund -Im Rahmen von Krankenhausbesuchen umfassen u.a. die Aufnahme-Workflows regelmäßig die manuelle Bearbeitung von Patientenstammdaten. Daher ist hier das Risiko redundant persistierter Patientendaten stets vorhanden. Dies hat auch zur Folge, dass Zusammenführungen von Patientendaten in Krankenhäusern an der Tagesordnung stehen. Ein Standard, der sich dem Austausch von Patientendaten innerhalb eines Krankenhauses verschreibt, sollte daher auch das Thema der Patientendatenzusammenführung (Patient merge) abdecken. Ziel ist es, dass externe Clients merge-Vorgänge nachvollziehen und entsprechend verarbeiten können. - -Bisher trifft ISiK keine Festlegung zum Patient merge. Aus diesem Grund ist die AG 'Patient merge' etabliert worden, die sich dem beschriebenen Thema im Rahmen von ISiK annehmen soll. - -Dieses Dokument soll der Harmonisierung der Problemdefinition zum Patient merge in ISiK dienen. Änderungswünsche am Dokument per Pull Request sind willkommen. - -## 2. Ziele (Update 29.01.2024) -Ziel der Arbeiten im Rahmen der Ausbaustufe 4 ist: -Die Schaffung eines modulübergreifenden Implementierungsleitfadens zum Vorgehen bei der Patientenzusammenführung. -Die Patientendatenzusammenführung (Patient merge) bezeichnet den Workflow der Bereinigung redundanter Patienten-Instanzen innerhalb eines KIS oder einer KH-IT-Umgebung. Die Bereinigung geschieht erfahrungsgemäß als halb-automatisierter Prozess, für den dedizierte Komponenten eingesetzt werden können. - -Für die Implementierung wurde gemeinsam mit den beteiligten Stakeholdern in der ersten Projektphase entschieden, zu welchem Vorgang die Spezifikation eine mögliche Festlegung treffen soll: -1. Eine Festlegung zur Kommunikation eines stattgefundenen Patient merges gegenüber einem Subsystem oder einem externen Service wird festgelegt und dafür wir eine Lösung mit FHIR-subscriptions angestrebt. - - Eine Lösung mittels FHIR-Subscriptions MUSS auf den in R5 definierten Lösungen aufbauen; eine Nutzung des R4 Subscription Profils genügt nicht. - - Die technische Lösung DARF NICHT auf einer Persistierung obsoleter Ressourcen beruhen. Auch DARF (aus Gründen der Performance) in der resultierenden Ressource keine (vollständige) History obsoleter Ressourcen (z.B. über das .link-Element) geführt werden. -1. Im Zuge des POC SOLLEN auch Sicherheitsaspekte umgesetzt werden (ggf. Autorisierung und Authentifizierung über SMART on FHIR / ISiK Connect). - - Subscriptions sollen nur von System gelesen werden können, das sie geschrieben hat. -1. Es SOLL ein Recovery-Mechanismus eingeführt werden (dieser SOLL über den Business-Identifier umgesetzt werden), um den Fall einer fehlgeschlagenen Notification abzufangen. -1. Vorgaben zum eigentlichen Patient-merge-Workflow werden im Rahmen der Ausbaustufe 4 nicht oder nur bedingt festgelegt. - - -## 3. Stakeholder und User -Die Spezifikation richtet sich insbesondere an SW-Hersteller von KIS und Patientenportalen. Alle anderen Hersteller von ISiK-nahen Systemen sind auch eingeladen sich zu beteiligen, da ihre Prozesse potenziell betroffen sein werden. - -Es handelt sich um eine technische Spezifikation, zu der keine weiteren medizinischen Fachexperten zu Rate gezogen werden müssen. - -## 4. Randbedingungen -### 4.1. Technische Randbedingungen -In den bisherigen ISiK Spezifikationen bestehen keine expliziten Festlegungen, wie mit dem Zusammenführen von Patientendaten umzugehen ist. - -Grundsätzlich stellt sich die Frage welche Vorgänge im Rahmen eines Patient merge Workflows Teil der Festlegung in einer zukünftigen Spezifikation sein sollten. Neben der in der Zielstellung beschriebenen Unterscheidung zwischen den merge-Workflows (merge) und der Kommunikation des merge-Prozesses (merge-inform), lassen sich weitere Aspekte anführen, die auch einzeln betrachtet werden können: - -* Patient.link - ein FHIR-Mechanismus der sich auch zum referenzieren unterschiedlicher (ggf. obsoleter) Patienten-Instanzen eignet -* match - Der Abgleich zweier Patienten-Instanzen (dies wird immer Voraussetzung für den eigentlichen Bereinigungs-Workflow, also das merge, sein) mit dem Resultat einer Übereinstimmung oder dem Erkennen zwei verschiedener Patienten -* merge in HL7v2 - hier existieren eine Reihe von ADT-Nachrichten mittels derer ein Patient merge (link, match, merge-inform etc.) implementiert werden kann - -Im Kontext des letztgenannten Aspekts muss auch geklärt werden, ob beim Festzulegenden eine Schnittstelle zur Überführung von v2-getriebenen merge-Prozessen in ein query-getriebenes (REST-)Paradigma zu priorisieren wäre. Ein exemplarischer Use Case für letzteres wäre: - -* Ein Subsystem erkennt (query-getrieben) eine Änderung einer Patienten-Ressource nach einem Patient merge im KIS, um daraufhin in eigenen Ressourcen mittels Patient-ID (PID) auf die korrekte FHIR-Ressource / Patienteninstanz referenzieren zu können. (Das System wäre damit nicht mehr auf die erfolgreiche Übermittlung einer entsprechenden PUSH-Nachricht angewiesen). - -Um die Problemdefinition besser abzugrenzen, treffen wir folgende Annahmen: - -* Operationen zum merge-Verhalten sind in HL7-v2 gelöst und werden durch verschiedene KIS entsprechend umgesetzt. - * hierbei orientieren wir uns an HL7 v2.3 (http://www.hl7.eu/HL7v2x/v23/std23/ch3.htm#Heading43), da wir annehmen, dass für diese Version die Verbreitung in deutschen Krankenhäusern am größten. -* Ebenso existieren Lösungen und Operationen in FHIR (Patient-link, $match (R4) und $merge (R5)). -* Neben der Patient-Ressource sollte auch der Encounter für den merge-Prozess prioritär berücksichtigt werden - -Neben den genannten Standards, existieren auch relevante IHE-Standards - diese sind u.a.: -- [PIX (Patient Identifier Cross-referencing)](https://profiles.ihe.net/ITI/TF/Volume1/ch-5.html) - - hier ggf. Use Case [ Multiple Identity Domains within a Single Facility](https://profiles.ihe.net/ITI/TF/Volume1/ch-5.html#5.3.1) -- [PIXm (Patient Identifier Cross-referencing for mobile](https://profiles.ihe.net/ITI/PIXm/index.html) - - insbesondere Use Case: [Resolve duplicate patient identity data in Multiple Identifier Domains](https://profiles.ihe.net/ITI/PIXm/volume-1.html#141423-resolve-duplicate-patient-identity-data-in-multiple-identifier-domains) -- PAM (Patient Administration Management) - https://profiles.ihe.net/ITI/TF/Volume1/ch-14.html#14 -- [Patient Identity Management [ITI-30] ](https://profiles.ihe.net/ITI/TF/Volume2/ITI-30.html) -- [Patient Identity Feed [ITI-8] ](https://profiles.ihe.net/ITI/TF/Volume2/ITI-8.html#3.8) -- XCPD (Cross-Community Patient Discovery) - https://profiles.ihe.net/ITI/TF/Volume1/ch-27.html#27 - -Insbesondere PIX/PIXm ist für den gesamten Patient-merge-Prozess relevant, aber auch PAM - für Kontexte der provisorischen [Instanz-Erzeugung](https://profiles.ihe.net/ITI/TF/Volume1/ch-14.html#14.2) und das [Kontakt-Management bzw. die Fachabteilungs-Überweisung](https://profiles.ihe.net/ITI/TF/Volume1/ch-14.html#14.2.1). Für Aspekte des Patient matching ist insbesondere XCPD (Cross-Community Patient Discovery) relevant. - -### 4.2. Organisatorische Randbedingungen -Es gelten die Fristen wie in anderen Modulen. - -Die Konsentierung der Use Cases soll auch eine rein asynchrone Mitarbeit erlauben. Dies schließt eine asynchrone Entscheidungsfindung ein. - -### 4.3. Konventionen -Die Draft-Dokumente werden auf github zur Diskussion gestellt. - -Pull Requests, die grundsätzliche Änderungen bewirken, sollten in der Regel im Rahmen der AG angekündigt und ggf. diskutiert werden. - -## 5. Kontextabgrenzung -### 5.1. User und Systeme -Zu berücksichtigende User sind -* Krankenhausmitarbeiter (MFAs, Ärzte etc.) -* Patienten (nur bei Nutzung Patientenportal, z.B. Terminplanung) - -Beteiligte Systeme sind prinzipiell alle bestätigungsrelevanten Systeme (siehe [DKG Festlegung](https://www.dkgev.de/themen/digitalisierung-daten/elektronische-datenuebermittlung/datenuebermittlung-nach-373-sgb-v-informationssysteme-im-krankenhaus/)). Hervorzuheben sind dabei: - -* KIS - -Zudem sind hervorzuheben als mögliche Clients, Subsysteme (oder ggf. Drittanbieter-Systeme außerhalb der Krankenhausumgebung): - -* Patientenportale - -Eine im Zuge des merges genutzte Komponenten ist ein Master Patient Index (MPI). Die Nutzung von MPIs in Krankenhäusern wird bei Use Cases (s.u.) mitbedacht. - -### 5.2. Kontext der Festlegung -Die Spezifikationsarbeit schließt die Festlegung oder Definition neuer Identifier (analog zu gID, eID etc.) aus. Es kann lediglich darum gehen, technische Verfahren und organisatorische Mechanismen aufzuzeigen und festzulegen, die mit gegebenen Patienten-Identifiers (PID) innerhalb einer Organisation operieren. - -Diese Verfahren oder Maßnahmen können nur für eine Institution gelten. Die Zusammenführung von Patientendaten zwischen unterschiedlichen Institutionen ist nicht im Scope der AG 'Patient merge' enthalten. - -Die genauere Problemdefinition und Anforderungserhebung unter Einbeziehung der interessierten Stakeholder ist selbst Teil der der Projektarbeit (erste Projektphase). - -### 5.3. Patient Data Journey - -Um die Regelungsbedarfe rund um den Patient merge genauer zu verstehen, ist die Analyse der Patient Journey, die möglichst viele Patientenattribute und die unterschiedlichen "Etappen" des Patienten durch das Krankenhaus erfasst, zunächst nicht zielführend (siehe dazu [Annex I](#annex-i---patient-journey)), da zu abstrakt gegenüber dem technischen Regelungsbedarf. - -Vielmehr, so die Annahmen, sollte es zunächst darum gehen eine Sicht auf die Synchronisierungsbedarfe zu legen, die zwischen unterschiedlichen Systemen bei Manipulationen einer Patienten-Instanz bestehen (in diesem Sinne ist es präziser hier von einer Patient Data Journey als von einer Patient Journey zu sprechen). Diese kann mittels folgendes, vereinfachenden Szenarios erfasst werden: - -Gegeben seien zwei Systeme, die beide Patientendaten speichern können - auch von denselben Patienten. Patientendaten bestehen nur aus einem Attribut X, logischer ID sowie einer Geschäfts-ID (PID), wobei nur die logische ID innerhalb eines Patientendatensatzes in beiden Systemen erforderlich ist. Beide Systeme verwenden ihre eigene logische ID, die niemals manuell eingegeben wird und daher immer von einem der Systeme zugewiesen wird. Nur ein System kann vom Krankenhauspersonal Eingaben empfangen (System A), das andere nur vom Patienten (System B). - -Basierend auf dem beschriebenen Szenario sind die möglichen Datenmanipulationen unterscheidbar, die eine Synchronisation zwischen den beiden Systemen (System A und System B) erfordern würden (und damit ggf. auch einen Regelungsbedarf durch die ISiK Spezifikation). Für eine ausführliche Liste der Szenarien siehe [Annex II](#annex-ii---patient-data-journey). - -Im Rahmen von ISiK ist es entscheidend Schnittstellen und Abläufe für einige aus diesem Szenario abgeleiteten Fälle festzulegen, um sicherzustellen, dass Patientendaten in allen Systemen konsistent bleiben. Dabei ist zunächst auszuwählen welche Szenarien anhand feingranularer Use Cases (siehe unten) genauer zu beachten sind. - -## 6. Lösungsstrategie -Vor der Entwicklung einer Lösungsstrategie, die eine Auswahl konkreter Bedarfe benennt, müssen zunächst Ziel- und Problemdefinition besser ausgearbeitet werden. Dennoch lassen sich grundsätzliche Lösungsszenarien nennen. - -Zunächst sollte für jedes bestätigungsrelevante System der Umfang des Festzulegenden einzeln bestimmt werden. - -Allgemein sollte im Zuge des Patient merge auch eine Ablösungsstrategie zu Hl7 v2 festgehalten werden - zwar nicht als ein Ausschluss des bestehenden Standards - dieser wird vermutlich noch weitere Jahre produktiv sein -, zumindest aber als perspektivische Alternative zur Einbindung von externen Dienst im Sinne eines Best-of-Breed-Ansatzes auf FHIR-Basis - z.B. bei Patientenportalen (s.u.). - -### 6.1. Bestehende Standards -Neben geltenden Festlegungen in FHIR und HL7v2 sind bei der weiteren Problemdefinition auch die oben benannten IHE-Profile zu berücksichtigen - -### 6.2. merge (und match) -Eine erste Spezifikation zum Patient merge sollte nicht auf eine vollumfängliche Abdeckung der Workflows zum Patient merge zielen. - -Sollte die Festlegung eines merge-Verhaltens auf FHIR-Basis als Zieldefinition konsentiert werden, sollte auf bestehende Festlegungen im FHIR Kontext zurückgegriffen werden. - -Da ein merge immer einen Abgleich von Ressourcen voraussetzt, wäre der Ansatz, zunächst eine match-Operation festzulegen (womöglich als eine erste normative Festlegung eines IGs). - -Zudem stellt FHIR Version R5 eine dezidierte Operation bereit (siehe https://hl7.org/fhir/patient.html#merge, insbesondere Operation "merge"). - -Im Kontext von Hl7 v2 sind zur Bereinigung von Duplikaten und Fehlzuordnungen folgende Mechanismen zu beachten: -- merge patient/account/visit: Zusammenführen von zwei Patientenstämmen, Abrechnungsfällen bzw. Aufenthalten in einem System und den abhängigen Subsystemen -- move patient/account/visit information: Verschieben eines Patienten zu einem anderen "Master-Patienten", Verschieben eines Abrechnungsfalls zu einem anderen Patienten bzw. Verschieben eines Aufenthalts zu einem anderen Abrechnungsfall etc. - -Hier sind auch die IHE Profile PIX, PAM und XCPD zu beachten. -Insbesondere für -- merge : [Patient Identity Feed FHIR [ITI-104]](https://profiles.ihe.net/ITI/PIXm/ITI-104.html) -- match: In PIXm - [Mobile Patient Identifier Cross-reference Query [ITI-83]](https://profiles.ihe.net/ITI/PIXm/ITI-83.html) - -### 6.3. merge-inform -Sollte allein die Festlegung zum merge-inform als Zieldefinition konsentiert werden, sollten auch bestehenden Mechanismen aus HL7v2 berücksichtigt werden. - -Zum merge-Inform könnten Lösungsansätze in FHIR sein: -- FHIR-Messaging -- (Topic-Based-)Subscription -- passiv über Link-Element in REST-Ressource. -- kombiniert, z.B.: Resolve Duplicate Patient(https://profiles.ihe.net/ITI/PIXm/ITI-104.html#2310442-resolve-duplicate-patient) - -Mittels HL7 ADT sind relevante Vorarbeiten: -- - [Patient Identity Feed [ITI-8] ](https://profiles.ihe.net/ITI/TF/Volume2/ITI-8.html#3.8) - mit ADT^A40 - - -## 7. User Stories und Use Cases - -In folgendem wird zwischen User Stories (Business-Seite) und Use Cases (technisch) unterschieden. - -User Stories sollen dazu dienen die Bereiche der Bedarfsanalyse grob abzudecken, daraufhin zu präzisieren und die Problemdefinition zu schärfen. Bei User Stories stellt sich zunächst die Frage: Wo entsteht der Bedarf nach einem Patient merge? - -Unsere Annahme ist, dass uns zur Schärfung der Problemdefinition zunächst eine Sicht auf die involvierten Komponenten-Arten hilft – zum Beispiel: - -- KIS (Interface mit Mitarbeiter) -- Subsystem (ggf. PDMS mit Interface zu trackender HW - z.B. Spritzenpumpe/Infusionspumpe) -- Patientenportal (Interface zu Patient) - -Diese Systeme können stellvertretend für Komponenten-Arten stehen, die eine Interaktion mit einem spezifischen User oder eine automatisierte Form des Daten-Inputs vorweisen. - -Die Präzisierung der Frage nach dem "Wo?" wäre daher: Was für ein spezifischer Bedarf an ein Patient merge ergibt sich bei verschiedenen Komponentenarten aufgrund der unterschiedlichen Art des Inputs (nach Rolle des Users oder automatisiert/händisch)? - -Jenseits der komponentenzentrierten Sicht wäre es zusätzlich möglich zur Identifikation weiterer User Stories die eigentliche Patient Journey (siehe Annex I) zu analysieren in Hinblick auf die Frage wo ein Patient merge wünschenswert wäre. - -### 7.1. User Stories - Business - -Zur Konkretisierung der Frage, lassen sich verschiedene User Stories erzählen, für die jeweils die Frage zu beantworten wäre: Was für ein spezifischer Bedarf an ein Patient merge ergibt sich in diesem Szenario? - -Drei User Stories beschreiben exemplarisch die grundlegenden Kontexte, in denen der Bedarf nach einem Patient merge entsteht – mit unterschiedlicher Komponenten für die User-System Interaktion: - -- US-01 - Terminbuchung Patientenportal: - - Eine Patientin bucht über ein Patientenportal einen Termin bei einem Krankenhaus. -- US-02 - händische Patientenaufnahme: - - Ein KH-Mitarbeiter legt bei der Patientenaufnahme eines Patienten in einem KIS händisch eine Patienteninstanz an. -- US-03 - Anlegen in Subsystem: - - Eine MFA der Intensivstation legt eine Instanz für den Patienten im PDMS an, sodass andere KH-Mitarbeiterinnen in Zukunft vom KIS die Herzfrequenz abfragen können. - -Für US-01 und US-02 sollte der Fall berücksichtigt werden, dass eine lokale Instanz eines Subsystems bei Update mit zusätzlichen Informationen auf den Status 'aktiv' überprüft wird. Dieser Fall sollte für alle UCs (s.u.) und alle Komponenten (Subsystem-Typen - ggf. aus ISiK) bedacht werden. - -### 7.2. US-01: Terminbuchung Patientenportal -Bei US-01 kann man differenzieren zwischen Fällen, in denen ein externes Patientenportal angeschlossen ist und eine hausinterne Komponente verwendet wird. Weiterhin könnte man in diesem Sinne differenzieren zwischen fachspezifischen und internen Terminplanungs-Systeme, z.B. für OP-Planung oder Strahlentherapie-Planung. - -Eine Ablauf-Darstellung der Terminbuchung mit Patientenportal ist im folgenden [GITHUB Issue](https://github.com/gematik/spec-ISiK-Basismodul/issues/264#issuecomment-1553022809) vorgestellt worden. - -Bereits an dieser Stelle lässt sich eine erste funktionale Anforderung (REQ) festhalten: - -**REQ-002**: "Ein Termin-Repository MUSS einen Benachrichtigungsmechanismus bereitstellen, der einen Termin-Requestor über erfolgte Patient merges informiert." - -### 7.3. US-02: händische Patientenaufnahme -Eine händische Aufnahme kommt vor, wenn z.B. ein Patient eine Karte vergessen hat. -Auch ein Fall sind bereits gedruckte Etiketten (z.B. im Kontext von Labor-Informations-Systeme - LIS), sodass alle im Umlauf befindlichen IDs verfügbar sein müssen. -Diese Story ist auch relevant für Patientenportale. - -### 7.4. US-03: Anlegen in Subsystem -Nach Praxiserfahrung kommt es durchaus vor, dass eine Instanz ad-hoc in einem PDMS angelegt wird (mit eigener ID), ohne dass ein merge mit einem KIS/Patientenführenden-System gewährleistet werden kann. - -Hier besteht womöglich der Bedarf nach einem vom KIS unabhängigen PDMS. - -### 7.5. Fazit zu User Stories -Wir nehmen an, dass für US-02 und US-03 es in der Regel dem KIS intern überlassen ist wie es einen Merge regelt oder nicht. Daher wären diese User Stories aus ISiK-Sicht nicht prioritär. Z.B. wenn im KIS händisch eine Aufnahme erfolgt, muss das System entscheiden, wie die Patient-Ressource erstellt wird. Wenn das KIS intern merged und direkt die richtige Ressource herausgibt, besteht keine Notwendigkeit für einen Merge oder ein Merge-Event. - -In diesem Sinne wäre US-01 für die folgende Entwicklung technischer Use Cases zum Patient merge zu priorisieren, wobei als externer Client nicht nur ein Patientenportal zu berücksichtigen ist, sondern auch sonstige Client-Systeme die auf ISiK-Schnittstellen zugreifen. - -### 7.6. Use Cases - Technisch -Aus einer Perspektive der Workflows lassen sich weitere Use Cases (UCs) ausdifferenzieren. - -In der Interaktion mit einem System, das Patientendaten verwaltet, lassen sich zunächst zwei UCs feststellen, die direkt Aspekte des Patientendatenzusammenführung betreffen: - -- Erzeugen einer neuen Patienten-Instanz (Vorbedingung) -- und das Mergen einer Instanz - -Dabei darf die merge-Interaktion nur von KH-Mitarbeitern mit dedizierten Rechten durchgeführt werden (nie von Patienten selbst). Auch vollständig automatisierte merge-Vorgänge sind möglich, bestenfalls sind sie die Regel. - -An den beschriebenen zentralen Use-Case grenzen weitere. Wobei nicht alle gelisteten Use Cases von einer technischen Festlegung betroffen sein sollten. - -Besondere Beachtung sollten folgenden UCs erhalten: - -* **UC-00: Instanz anlegen** - * *Beschreibung:* Anlegen einer Patienteninstanz. Vorbedingung für den zentralen Use Case - * *Akteure:* System (meistens Server), Mitarbeiterin , Patienten (bei Portal) -* **UC-01: Patient-merge** - * *Beschreibung:* Zentraler Use Case, der den Merge von Patientendaten im Krankenhauskontext darstellt. - * *Akteure:* System, Mitarbeiterin -* **UC-02: match (Patientendatenabgleich)** - * *Beschreibung:* Identifikation von potenziell zusammenzuführenden Patientendaten. - * *Akteure:* System -* **UC-03: Inform about merge** - * *Beschreibung:* Benachrichtigung über den erfolgten Merge an relevante Parteien. - * *Akteure:* System -* **UC-04: Clearing** - * *Beschreibung:* Manueller Bereinigungsprozess von Patientendaten nach einer erfolgreichen Identifikation von zusammenzuführenden Daten, die allerdings nicht automatisiert zusammengeführt werden konnten (aufgrund niedrigen Threshholds (bei MPI) oder von Konflikten) - * *Akteure:* System, Mitarbeiterin -* **UC-05: Datenbereinigung** - * *Beschreibung:* Bereinigung von Daten vor oder während des Merge-Prozess. - * *Akteure:* System, Mitarbeiterin -* **UC-06: Konfliktlösung** - * *Beschreibung:* Wenn es Inkonsistenzen oder Konflikte zwischen den zu mergenden Daten gibt (z.B. unterschiedliche Blutgruppen), muss ein Mechanismus zur Konfliktlösung implementiert werden. - * *Akteure:* System, Mitarbeiterin -* **UC-07: Meldung von Dateninkonsistenzen** - * *Beschreibung:* Falls während des Merge-Prozesses Inkonsistenzen oder Unstimmigkeiten festgestellt werden, sollten Mechanismen zur Meldung und Bearbeitung dieser Probleme bereitgestellt werden. - * *Akteure:* System, Mitarbeiterin -* **UC-08: Neu referenzieren** - * *Beschreibung:* Verarbeitung und Update der Referenzen, der in einer Patienten-Instanz referenzierter Ressourcen oder auf diese Patienten-Instanz referenzierende Dokumente im Zuge des Patient-merge - -Weiterhin sind relevant, sollten aber nicht teil einer normativen Spezifikationsabdeckung sein: - -* **UC-09: Datenvalidierung** - * *Beschreibung:* Vor dem Zusammenführen der Patientendaten müssen die Daten validiert werden, um sicherzustellen, dass sie korrekt und vollständig sind. - * *Akteure:* System (ggf. Mitarbeiterin)  -* **UC-10: Historie verwalten (Audit-Trail)** - * *Beschreibung:* Es ist wichtig, eine Historie der durchgeführten Merges zu führen, um nachverfolgen zu können, welche Daten zusammengeführt wurden und wann dies geschah, einschließlich der beteiligten Akteure und Zeitstempel. - * Akteure: System -* **UC-11: Fehlerbehandlung** - * *Beschreibung:* Es sollte ein Mechanismus zur Behandlung von Fehlern und Ausnahmesituationen implementiert werden, um sicherzustellen, dass der Merge-Prozess robust und fehlertolerant ist. - * *Akteure:* System -* **UC-12: Datenschutz und Compliance** - * *Beschreibung:* Sicherstellen, dass der Merge-Prozess den geltenden Datenschutzrichtlinien und -vorschriften entspricht, um die Privatsphäre und Sicherheit der Patientendaten zu schützen. - * *Akteure:* Mitarbeiterin, System - -![Use Case Diagram](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.github.com/gematik/spec-ISiK-Basismodul/Patient-merge/ImplementationGuide/markdown/UebergreifendeFestlegungen/Use-Case-Diagram.iuml) - -Die im UC Diagram grün gekennzeichneten UCs sind besonders zu priorisieren, daher in Folge eine schematische Analyse. - -Die hervorgehobenen Anwendungsfälle (UC-01, UC-02, UC-03) können Interaktionen mit externen Systemen oder Datenbanken beinhalten, um zusätzliche Patienteninformationen abzurufen (z.B. bei der Anbindung eines Patientenportals). - -Ein weitere Sonderfall, der ggf. einzeln zu betrachten wäre, ist folgender: - -* Ein Subsystem kommuniziert dem Primärsystem eine Änderung und möglichen Bedarf an Zusammenführung (operation / gegeben in V2?). - -Use Cases werden je nach IT-Architektur einer Einrichtung abweichen. Man kann beispielsweise folgende Aspekte benennen: -* (monolithische) KIS-Systeme, die eine FHIR-Fassade nutzen, um den REST-Abfragen nach ISiK zu entsprechen (wird die Regel sein) -* Systeme, die einen (teil-)automatisierten Clearing-Mechanismus zur Zusammenführung von Patienten-Instanzen implementiert haben. -* Systeme, die einen Master Patient Index (MPI) implementiert haben, um in ihrer (heterogenen) IT-Landscape PIDs zu administrieren -* FHIR-nativen IT-Landscapes – diese gibt es in Deutschland vermutlich (noch) überhaupt nicht (jedoch ggf. angestrebt und sollten daher mitgedacht werden) - -Die Analyse dieser Ausprägungen sollen zunächst keinen großen Stellenwert einnehmen, da wir uns einer IT-Architektur-neutralen Problemdefinition nähern möchten. - -Weitere UCs in Zusammenhang mit den FHIR Ressourcen Encounter und Abrechnung sind folgende: - -* bei der administrativen Aufnahme wird geprüft, ob der Patient im Haus bereits bekannt ist, oder ob ein neuer Patient angelegt werden muss -* bei der administrativen Aufnahme wird ein neuer Aufenthalt angelegt und einem in System bestehenden Patienten zugeordnet -* bei der administrativen Aufnahme wird geprüft, ob zu dem Patienten noch ein offene Abrechnungsfall besteht, dem der Aufenthalt zugeordnet werden muss, oder ob ein neuer Abrechnungsfall anzulegen ist -* bei der administrativen Aufnahme wird der neue Aufenthalt zu einem Abrechnungsfall zugeordnet -* sofern das Haus Fallakten unterstützt oder seine Berechtigungen analog der OH KIS organisiert, wird ein Aufenthalt bei der medizinischen Aufnahme einem medizinischem Fall zugeordnet oder es wird ein neuer medizinischer Fall angelegt. - -Auch diesen UC Cases rund um derivierte/referenzierte/referenzierende Ressourcen zu Patient können erst in einem zweiten Schritt der Verfeinerung der Use Case Analyse genauer betrachtet werden. - -Die folgende Liste der Use Cases entspricht der Priorisierung im Rahmen des Festlegungs-Vorhabens 'Patient merge'. - -#### 7.6.1. UC-01: Patient-merge -*Anwendungsfall-ID:* UC-01 - -*Anwendungsfall-Name:* Patient merge (Zusammenführung von Patientenressourcen) - -*Akteur:* Krankenhauspersonal, System - -*Beschreibung (ausführlich):* - -Dieser UC beinhaltet den (komplexen) Prozess der Zusammenführung von Patientenressourcen innerhalb des KIS eines Krankenhauses (inklusive angeschlossener Subsysteme), um kohärente Patientenidentifier sicherzustellen. Der zugrundenliegende Prozess im KIS beinhaltet auch die Bereinigung von doppelten oder fragmentierten Patientendaten. - -**REQ-001:** Ein bestätigungsrelevantes System (insbesondere KIS) muss sicherstellen, dass nach dem abgeschlossenen Patient merge alle Instanzen über eine führende Referenz auffindbar sind. - -Zur Illustration können erneut User Stories dienen: Eine Ärztin sucht in einem KIS nach möglichen anamnestischen Daten und Vitalparametern eines Patienten, wobei dieser doppelt im KIS aufgenommen worden war. Eine Patientin bucht über ein Patientenportal einen Termin bei einem Krankenhaus (s.o. US-01). - -Im Vergleich zum Standardfall des Auffindens bzw. Entdecken von Duplikaten ist der zweite Fall als kritisch zu betrachten, da hier das Subsystem, bspw. ein Patientenportal, regelmäßig neue Identifier erzeugt und dem KIS als Quelle dient. - - -**Beispiel-Sequenz:** Angenommen es ist ein weiteres Subsystem inklusive einer Schnittstelle (hier bspw. PDMS) beteiligt, so lässt sich eine exemplarische Sequenz für User Story 01 ableiten: -* Eine Ärztin gibt über eine Suchanfrage in der Maske Vor- und Nachnamen des Patienten an (Max Mustermann). Es erscheinen zwei Patienteninstanzen mit identischen Stammdaten (bis auf einen offensichtlichen Tippfehler). -* Die Ärztin führt die Patientendaten über einen Clearingmechanismus zusammen. -* Das KIS sendet über einen Kommunikationsserver eine PUSH-Nachricht (Hl7 v2) an alle Subsysteme (inklusive des PDMS), um den Update-Status der Patienten-Ressource und den geschehenen merge zu informieren. -* Die Subsysteme verarbeiten die merge-informationen und updaten die entsprechende organisationsinterne Patienten-ID (PID). -* Die Ärztin stellt eine Anfrage mit der nun bekannten Patientenintanz (oder über den Namen) für sämtliche Körpertemperaturmessungen der letzten Tage. -* Das KIS leitet diese Anfrage über eine REST-Schnittstelle weiter an das PDMS (über Suchparameter "Patient" nach https://simplifier.net/guide/Implementierungsleitfaden-ISiK-Modul-Vitalparameter-Stufe-3/ImplementationGuide-markdown-Interaktionen?version=current ) und gibt den entsprechenden Datensatz zurück. - - -**Beispiel-Sequenz:** Angenommen es ist die Komponente Patientenportal inklusive einer Schnittstelle beteiligt, so lässt sich eine exemplarische Sequenz für User Story 01 ableiten: -* Das Patientenportal erzeugt aufgrund der von der Patientin angegeben Fall- und Anamnese-Daten verschiedene FHIR-Ressourcen, die einer FHIR Patient Ressource (PatientMustermannPatientenportal) zugeordnet werden. -* Nach dem Synchronisierungsprozess der Terminbuchung zwischen Patientenportal und KIS des KHs wird die FHIR-Instanz PatientMustermannPatientenportal mit der im KIS vorhandenen Instance PatientMustermannKH im Rahmen eines Clearing-Prozesses unter Beteiligung einer KH-Mitarbeitern im KIS zusammengeführt zu PatientMustermannMerge. -* (extends) Die Referenzierten Ressourcen (FHIR Observations) werden (extrahiert und) mit den zusammengeführten Daten von PatientMustermannMerge verknüpft -* Das Patientenportal erkennt (query-getrieben) eine Änderung von Patienten-Ressource nach einem Patient-merge im KIS (dies wäre anzusiedeln bei **UC-03: Inform about merge**) - -*Voraussetzungen:* -* Das Krankenhaus verfügt über ein funktionierendes KIS, das in der Lage ist, HL7-v2-Nachrichten und/oder FHIR-Operationen bzw. vergleichbare proprietäre Operationen zu verarbeiten. -* Es wurden identifizierte doppelte oder fragmentierte Patientenakten festgestellt, die zusammengeführt werden müssen. - -*Annahmen:* -* Das KIS-System verfügt über die erforderlichen Funktionen zur Durchführung der Zusammenführung von Patientenakten. -* Das Krankenhauspersonal, das die Zusammenführung initiiert oder tätigt, verfügt über die entsprechenden Berechtigungen und Schulungen. - -*Nachbedingungen:* - -Die Patientenakten werden zusammengeführt, und eine vereinheitlichte, genaue Akte wird erstellt. - -*Priorität:* Hoch - -*Nutzungshäufigkeit:* Gelegentlich - -*Technischer Standardablauf:* -* Das Krankenhauspersonal startet den Zusammenführungsprozess über das KIS (ggf. Über das KAS). -* Das KIS ruft die für die Zusammenführung identifizierten Patientenakten ab. -* Das System analysiert die Akten auf potenzielle Duplikate anhand von Übereinstimmungskriterien (z. B. Name, Geburtsdatum usw.). -* Das System zeigt potenzielle Übereinstimmungen dem Krankenhauspersonal zur Überprüfung und Bestätigung an. -* Das Krankenhauspersonal überprüft und wählt die Akten aus, die zusammengeführt werden sollen. -* Das System führt die ausgewählten Akten zusammen und priorisiert Daten aus der genauesten und vollständigsten Quelle. -* Das System aktualisiert alle relevanten Verweise auf die zusammengeführte Patientenakte. - -*Alternative Abläufe:* - -Wenn keine identifizierten Duplikate vorhanden sind, benachrichtigt das System den Benutzer, und der Prozess endet. - -*Ausnahmen:* - -Bei technischen Problemen, die den Zusammenführungsprozess verhindern, wird eine Fehlermeldung generiert, und der Prozess wird abgebrochen. - -*Includes (weitere UCs):*  - * vollautomatisiertes matching und merging - * vollautomatisiertes matching mit manuellem merge - * (halb)automatisiertes matching mit vollautomatisiertem merge - * Notification über match/merge durch ein Subsystem - -*Extends (weitere UCs):* -* tbd. - -*Anmerkungen und Probleme:* -* Patient merges sollten protokolliert werden, um technische Verantwortlichkeit und Rückverfolgbarkeit zu gewährleisten. - -#### 7.6.2. UC-02: match (Patientendatenabgleich) - -*Anwendungsfall-ID:* UC-02 - -*Anwendungsfall-Name:* match (Patientendatenabgleich) - -*Akteur:* System, Krankenhauspersonal - -*Beschreibung:* Der Use Case umfasst den Abgleich von Patientendaten innerhalb des Gesundheitsinformationssystems (KIS) eines Krankenhauses. Dabei werden entweder adäquate HL7-v2-Nachrichten oder die FHIR ($match)-Operation oder vergleichbare proprietäre Operationen verwendet, um potenzielle Duplikate oder fragmentierte Datensätze zu identifizieren. - -#### 7.6.3. UC-03: Inform about merge - -*Anwendungsfall-ID:* UC-03 - -*Anwendungsfall-Name:* Inform about merge (Abgleich und Benachrichtigung nach Merge) - -*Akteur:* System - -*Beschreibung:* Dieser Anwendungsfall beinhaltet die Benachrichtigung angeschlossener Systeme - KIS sowie Subsysteme - über den erfolgreichen Merge. Diese Benachrichtigung eines anderen Systems kann auf verschiedene Arten erfolgen. -Die Benachrichtigung unterstützt das Kernziel einer reibungslosen Kommunikation zwischen zwei Systemen, nachdem eine Patientenzusammenführung stattgefunden hat. Durch die Benachrichtigung wird ein fehlerhafter Abruf oder falsche Referenzierung einer alten Patientenressource verhindert und damit eine Verbesserung der Qualität hinsichtlich Robustheit und damit auch eine Stärkung der Praxistauglichkeit erreicht. - -Zu klären bleibt ob im Rahmen der Spezifikation eine Bestätigungsrelevanz zu erlangen ist für: -a) den Versand einer Information zu einer Patientenzusammenführung für das KIS -b) den Empfang und die Verarbeitung einer Information zu einer Patientenzusammenführung für Subsysteme (nicht KIS) - -Weiter bleibt zu klären durch welche FHIR Lösungsalternativen (siehe [6.3. merge-inform](#63-merge-inform)) die Benachrichtigung konkret auszugestalten ist. - -Zudem ist zu klären, ob die Nutzung von FHIR-Mitteln eine optionale Bestätigung sein sollte, wenn das KIS / Subsysteme die besagte Funktionalität mittels HL7 V2.x bereitstellen. - -Weitere Lösungsalternativen und -kontexte: -* Als direkte FHIR Message. -* Als HLV7x2 Message durch einen Messageserver, z.B. nach Auslesen eines Flags. -* Als direkter Aufruf einer Merge Operation im Fremdsystem -* Im Rahmen einer allgemeinen Refresh-Benachrichtigung -* Im Rahmen eines Detektierungs-Events einer zugehörigen Subscription - -Beachte auch Festlegungen: - - FHIR - https://hl7.org/fhir/patient-operation-merge.html#notification - - IHE PIXm - https://profiles.ihe.net/ITI/PIXm/ITI-104.html#2310442-resolve-duplicate-patient - -#### 7.6.4. UC-XY -Sollten weitere UCs genauer erörtert werden? - -## 8. Priorisierte Liste der Use Cases nach Bedarf -Hier werden die UCs priorisiert. -Die Priorisierung entspricht Arbeitspaketen für die konzeptuelle Aufbereitung. Eine technische Umsetzung im Rahmen der Stufe 4 soll dabei explizit nicht für alle UCs angestrebt werden. - -Für folgende UCs soll eine Festlegung in Stufe 4 angestrebt werden (Stand 13.10.2023): - -1. **UC-03: Inform about merge** - - Bedarfsmeldung im Rahmen der 1. AG Patient merge vom 10.10.2023 und [hier](https://chat.fhir.org/#narrow/stream/287581-german.2Fisik/topic/.5BBasis.5D.20Patient.20merge.20-.20Kick-Off) - -Weitere UCs in priorisierter Reihenfolge: - -1. **UC-08: Neu referenzieren** - - Kommentar: ggf. ausarbeiten im Sinne der Kommunikation von geänderten Ressourcen - - Bedarfsmeldung im Rahmen der 1. AG Patient merge vom 10.10.2023 und [hier](https://chat.fhir.org/#narrow/stream/287581-german.2Fisik/topic/.5BBasis.5D.20Patient.20merge.20-.20Kick-Off) -1. **UC-02: match (Patientendatenabgleich)** - - -## 9. Priorisierte Liste weiterer Bedarfe an die Spezifikation -Hier werden Bedarfe an die Spezifikation vorgehalten, die nicht unmittelbar über die oben priorisierten UCs abgedeckt sind. - -1. Definition von Best-Practices für den Client im Falle eigener Datenhaltung -1. ... - -## 10. Annex I - Patient Journey - -Zur Abbildung der Patient Journey durch ein Krankenhaus kann ein typischer Prozess wie folgt skizziert werden, indem für die einzelnen Prozessschritte die jeweils relevanten ISiK Ressourcen neben Patient benannten werden: - -- Terminvereinbarung und Vorbereitung: - - Patient vereinbart einen Termin mit dem Arzt oder der Klinik. - - Die Rezeptionistin fragt nach persönlichen Informationen und Versicherungsdetails. - - Ressourcen: Appointment (Terminplanung), Encounter (Basis), Coverage (Basis) - -- Ankunft und Registrierung: - - Der Patient kommt zum vereinbarten Zeitpunkt im Krankenhaus an. - - An der Rezeption meldet er/sie sich und wird registriert. - - Der Patient füllt möglicherweise Formulare zu seiner Krankengeschichte und Versicherung aus. - - Ressourcen: ... - -- Wartezeit und Voruntersuchungen: - - Der Patient wartet im Wartezimmer aufgerufen zu werden. - - Eine Krankenschwester oder ein Pfleger ruft den Patienten auf und nimmt Vitalzeichen (Blutdruck, Puls, etc.) auf. - - Der Patient wird gegebenenfalls zu verschiedenen Abteilungen für spezifische Voruntersuchungen (z.B. Bluttests, Röntgen) geschickt. - -- Arztkonsultation: - - Der Arzt bespricht die Ergebnisse der Voruntersuchungen und untersucht den Patienten. - - Der Arzt stellt eine Diagnose und bespricht den Behandlungsplan. - -- Behandlung und Aufnahme: - - Wenn eine stationäre Aufnahme notwendig ist, wird ein Zimmer zugewiesen. - - Der Patient erhält Informationen zu seiner Krankheit, dem geplanten Verlauf und der geplanten Behandlung. - -- Behandlung und Pflege: - - Das Pflegepersonal übernimmt die Pflege und Unterstützung des Patienten während seines Aufenthalts. - - Der Patient erhält Medikamente und Therapien gemäß dem Behandlungsplan. - -- Überwachung und Visiten: - - Der Zustand des Patienten wird regelmäßig überwacht. - - Ärzte führen tägliche Visiten durch, um den Fortschritt zu überprüfen und Anpassungen am Behandlungsplan vorzunehmen. - -- Entlassungsvorbereitung: - - Wenn der Patient sich verbessert hat, wird die Entlassung vorbereitet. - - Der Arzt gibt Anweisungen zur weiteren Erholung, Medikamenteneinnahme und eventuellen Folgeterminen. - -- Entlassung: - - Der Patient erhält Entlassungspapiere und Rezepte für benötigte Medikamente. - - Die Rezeptionistin klärt finanzielle Angelegenheiten und gibt Anweisungen zur Nachsorge. - -- Nachsorge und Folgetermine: - - Der Patient folgt den Anweisungen zur Nachsorge, nimmt Medikamente ein und vereinbart gegebenenfalls Folgetermine. - - - - -## 11. Annex II - Patient Data Journey - -Hier eine ausführliche Liste der Szenarien, aus dem in [Patient Data Journey](#patient-data-journey) geschilderten Modell. - -1. Initiale Dateneingabe: - - Wenn ein neuer Patient in einem der Systeme registriert wird, müssen Attribut X und/oder die Business-ID (PID) des Patienten mit dem anderen System synchronisiert werden. -2. Aktualisierungen der Patienteninformationen: - - Wenn Attribut X oder Business-ID (PID) von Patienten in einem System geändert werden (System A oder System B), muss die Änderung mit dem anderen System synchronisiert werden. -3. Zuweisung logischer IDs: - - Beide Systeme weisen den Patientendateninstanzen ihre eigenen logischen IDs zu. Wenn eine logische ID von einem der Systeme generiert wird, muss sie mit dem anderen System synchronisiert werden. -4. Löschung von Patientendaten: - - Wenn ein Patient in einem System (System B) darum bittet, seine Daten zu löschen, sollte dieser Wunsch mit dem anderen System (System A) synchronisiert werden. -5. Wiederherstellung gelöschter Daten: - - Wenn ein Patient die Wiederherstellung zuvor gelöschter Daten in einem System beantragt (System B), sollte diese Aktion mit dem anderen System (System A) synchronisiert werden, um die Konsistenz sicherzustellen. -6. Konfliktlösung: - - Falls es zu Konflikten bei den Daten kommt (z.B. wenn die Informationen zu Patienten in beiden Systemen aktualisiert werden, bevor die Synchronisation erfolgt), muss es einen Prozess zur Lösung dieser Konflikte geben, um sicherzustellen, dass die aktuellsten Informationen in beiden Systemen wiedergegeben werden. -7. Zugriffsberechtigungen für Daten: - - Wenn der Patient seine Berechtigungen oder Zustimmungseinstellungen für den Datenzugriff in einem System aktualisiert (System B), sollten diese Änderungen mit dem anderen System (System A) synchronisiert werden, um sicherzustellen, dass der Zugriff entsprechend gewährt oder eingeschränkt wird. -8. Datenintegritätsprüfungen: - - Regelmäßige Überprüfungen sollten durchgeführt werden, um sicherzustellen, dass die in beiden Systemen gespeicherten Daten konsistent und korrekt bleiben. Etwaige Diskrepanzen oder Fehler sollten identifiziert und durch Synchronisation behoben werden. -9. Datenbackups und -wiederherstellung: - - Beide Systeme sollten einen Mechanismus für das Backup und die Wiederherstellung von Daten haben. Die Synchronisation ist wichtig, um sicherzustellen, dass die Backups in beiden Systemen konsistent und auf dem neuesten Stand sind. -10. Synchronisation der Protokolldatei: - - Jegliches Protokollieren von Datenzugriff und -modifikation sollte zwischen den beiden Systemen synchronisiert werden, um einen vollständigen Datensatz aller Aktivitäten zu behalten. - -Das Szenario kann um eine weitere Komponenten erweitert werden: - -Ein System C kann weitere Daten zum Patienten bereitstellen in Form eines Attribut Y (z.B. Vitalzeichen oder Labordaten), das aber lediglich von einer IT-Komponente automatisch befüllt wird. Sonst gelten auch für dieses System die obigen Restriktionen und Umstände. Zusätzliche Szenarien für das System C: - -11. Automatische Befüllung von Attribut Y (z.B. Vitalzeichen und Labordaten): - - Da System C automatisch von einer IT-Komponente befüllt wird, müssen die übermittelten Daten Attribut Y (z.B. Vitalzeichen oder Labordaten) in regelmäßigen Abständen zwischen den Systemen synchronisiert werden, um sicherzustellen, dass alle relevanten Patienteninformationen aktuell und korrekt sind. -12. Automatische Aktualisierung der logischen ID: - - Da System C von einer IT-Komponente betrieben wird, die automatisch logische IDs vergibt, muss sichergestellt werden, dass diese IDs in den anderen Systemen entsprechend aktualisiert werden, um die Konsistenz der Daten zu wahren. diff --git a/Material/images/diagrams/Patient-merge_Use-Case-Diagram.iuml b/Material/images/diagrams/Patient-merge_Use-Case-Diagram.iuml deleted file mode 100644 index 7a0ddc874..000000000 --- a/Material/images/diagrams/Patient-merge_Use-Case-Diagram.iuml +++ /dev/null @@ -1,35 +0,0 @@ -@startuml -left to right direction - -package "ISIK Patient merge"{ -usecase (UC01: Patient-merge) as UC01 #palegreen;line:green;line.dashed;text:green -usecase (UC02: Match) as UC02 #palegreen;line:green;line.dashed;text:green -usecase (UC03: Inform about merge) as UC03 #palegreen;line:green;line.dashed;text:green -usecase (UC04: Clearing) as UC04 -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: -:Patient: - -usecase (UC0: Patienten-Instanz anlegen) as UC0 - -usecase UC9 as "UC09: Datenvalidierung" -usecase UC10 as "UC10: Historie verwalten (Audit-Trail)" -usecase UC11 as "UC11: Fehlerbehandlung" -usecase UC12 as "UC12: Datenschutz und Compliance" - - -Mitarbeiterin -> UC0 -Mitarbeiterin -> UC01 - -Patient -> UC0 - -note "Patienten-Instanzen können sowohl in KIS,\nSubsystem oder externem System erzeugt werden \nund sind per se keine FHIR Patient Ressource" as NC0 - -UC0 .. NC0 -@enduml \ No newline at end of file diff --git a/Material/images/diagrams/Sequence-Diagram-Patient-Merge-Notification.puml b/Material/images/diagrams/Sequence-Diagram-Patient-Merge-Notification.puml deleted file mode 100644 index 3b3cff2bb..000000000 --- a/Material/images/diagrams/Sequence-Diagram-Patient-Merge-Notification.puml +++ /dev/null @@ -1,16 +0,0 @@ -@startuml - -participant "Client System" as ClientSystem -participant "Server System" as ServerSystem - -activate ClientSystem -activate ServerSystem -ClientSystem -> ServerSystem: subscribe to SubscriptionTopic: http://hl7.org/SubscriptionTopic/patient-merge - -ServerSystem -> ClientSystem: confirm subscription - - -ServerSystem -> ServerSystem: $patient-merge with source and target patient -ServerSystem -> ClientSystem: send notification Bundle - -@enduml \ No newline at end of file diff --git a/Material/images/src/plantuml/infomodel.puml b/Material/images/src/plantuml/infomodel.puml deleted file mode 100644 index dae2955b0..000000000 --- a/Material/images/src/plantuml/infomodel.puml +++ /dev/null @@ -1,251 +0,0 @@ -@startuml dummy -' package Dummy{ -' entity Entität01 { -' optionales Attribut -' **optionales fettes Attribut** -' * **vorgeschriebens fettes Attribut** -' } -' -' entity Entität01 { -' optionales Attribut : text -' **optionales fettes Attribut** nummer <> -' * **vorgeschriebens fettes Attribut** -' } -' Entität01 }|..|| Entität02 -' Entität03 }o..o| Entität04 -' Entität05 ||--o{ Entität06 -' Entität07 |o--|| Entität08 -' } -@enduml - - -@startuml infomodel -'verhindere Probleme mit gewinkelten Krähenfüßen -'skinparam linetype ortho - -'ISiK_Medikation.ISiKMedikationsListe::subject --> ISiK_Basis.ISiKPatient -'ISiK_Medikation.ISiKMedikationTransaction --> R4_Core.Bundle -'ISiK_Medikation.ISiKMedikationTransactionResponse --|> R4_Core.Bundle - - 'ISiKMedikation::itemReference --> ISiKMedikation - -'AMTS related -'together { -class ISiKAllergieUnvertraeglichkeit <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikallergieunvertraeglichkeit ISiK AllergieUnvertraeglichkeit]] - --- - clinicalStatus : **AllergyIntoleranceClinicalStatusCodes** - |_ coding - verificationStatus : **AllergyIntoleranceVerificationStatusCodes** - |_ coding - type : **AllergyIntoleranceType** - category : **AllergyIntoleranceCategory** - criticality : **AllergyIntoleranceCriticality** - code - |_ coding - . . . -} - -class ISiKLebensZustand <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isiklebenszustand ISiK LebensZustand]] - --- - status : **ObservationStatus** - code - subject : Reference ( **Patient** | \nGroup | Device | Location) - . . . -} - - - class ISiKAlkoholAbusus <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikalkoholabusus ISiK Alkohol Abusus]] - --- - code : snomed sct **15167005** - . . . - } - class ISiKRaucherStatus <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikraucherstatus ISiK Raucherstatus]] - --- - code : snomed sct **77176002** - . . . - } -'Oservation Childs -together Observations { - - class ISiKSchwangerschaftErwarteterEntbindungstermin <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikschwangerschafterwarteterentbindungstermin ISiK Schwangerschaft - Erwarteter Entbindungstermin]] - --- - code : **SchwangerschaftEtMethodeVS** - . . . - } - class ISiKSchwangerschaftsstatus <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikschwangerschaftsstatus ISiK Schwangerschaftsstatus]] - --- - code : loinc **82810-3** - . . . - } - - class SchwangerschaftsstatusVS <<(V,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/schwangerschaftsstatusvs Schwangerschaft Status]] from [[http://loinc.org LOINC]] - } - - class ISiKStillstatus <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikstillstatus ISiK Stillstatus]] - --- - code : snomed sct **1260078007** - . . . - } -} - - -' Weiteres Basis -together { - - class ISiKPatient <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikpatient ISiK Patient]] - } - - class ISiKPersonImGesundheitsberuf <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikpersonimgesundheitsberuf ISiK Person im Gesundheitsberuf]] - } - class ISiKKontaktGesundheitseinrichtung <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikkontaktgesundheitseinrichtung ISiK Kontakt Gesundheitseinrichtung]] - } - - class ISiKAbrechnungsfall <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-labor-v4/isiklabrechnungsfall ISiK Abrechnungsfall]] - --- - extension : **ExtensionAbrechnungsDiagnoseProzedur** - |_ AbrechnungsDiagnoseProzedur - . . . - } - - class ISiKAngehoeriger <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikangehoeriger ISiK Angehoeriger]] - --- - patient : Reference ( **Patient**) - name : HumanName - address : Address - |_ Strassenanschrift : **Adresse** - |_ Postfach : **Adresse** - . . . - } - - class ISiKBerichtBundle <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikberichtbundle ISiK Bericht bundle]] - --- - type : **document** - entry - |_ Composition - |_ resource : **ISiKBerichtSubSysteme** - . . . - } - - class ISiKBerichtSubSysteme <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikberichtsubsysteme ISiK Bericht SubSysteme]] - } - -} - -'Valuesets Observations - - class LOINCCodes <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[http://hl7.org/fhir/ValueSet/observation-codes Observation Codes]] from [[https://loinc.org/ LOINC]] - } - - class SchwangerschaftEtMethodeVS <<(V,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/schwangerschaftetmethodevs Schwangerschaft Estimated Methode]] from [[http://loinc.org LOINC]] - } - - -together { - class AllergyIntoleranceCriticality <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[https://hl7.org/fhir/R4/valueset-allergy-intolerance-criticality.html Allergy Intolerance Criticality]] from [[https://hl7.org/fhir/R4/codesystem-allergy-intolerance-criticality.html HL7]] - } - class AllergyIntoleranceVerificationStatus <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[https://www.hl7.org/fhir/R4/valueset-allergyintolerance-verification.html Allergy Intolerance Verification Status]] from [[https://www.hl7.org/fhir/R4/codesystem-allergyintolerance-verification.html HL7]] - } - class AllergyIntoleranceClinicalStatus <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[https://www.hl7.org/fhir/R4/valueset-allergyintolerance-clinical.html Allergy Intolerance Clinical Status]] from [[https://www.hl7.org/fhir/R4/codesystem-allergyintolerance-clinical.html HL7]] - } - class AllergyIntoleranceType <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[http://hl7.org/fhir/ValueSet/allergy-intolerance-type Allergy Intolerance Type]] from [[http://hl7.org/fhir/allergy-intolerance-type Code System of Allergy Intolerance]] - } - class AllergyIntoleranceCode <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[http://hl7.org/fhir/ValueSet/allergyintolerance-code Substance/Product, Condition, NegationCodes]] from [[http://snomed.info/sct SNOMED CT]] - } - class ReactionEventSeverity <<(V,#8DA5C4)>> { - Dokumentation auf HL7 Org - [[https://hl7.org/fhir/R4/valueset-reaction-event-severity.html Reaction Eventu Severity]] from [[https://hl7.org/fhir/R4/codesystem-reaction-event-severity.html HL7]] - } -} - - -'Relations regarding basis AMTS - -'diamonds -'together { -<> MultiRef_PracPatRel -MultiRef_PracPatRel -- ISiKPersonImGesundheitsberuf -MultiRef_PracPatRel -- ISiKPatient -MultiRef_PracPatRel -- ISiKAngehoeriger -<> MultiRef_AllergyDetails -MultiRef_AllergyDetails -up- AllergyIntoleranceCriticality -MultiRef_AllergyDetails -up- AllergyIntoleranceVerificationStatus -MultiRef_AllergyDetails -up- AllergyIntoleranceClinicalStatus -MultiRef_AllergyDetails -up- ReactionEventSeverity -MultiRef_AllergyDetails -up- AllergyIntoleranceType -MultiRef_AllergyDetails -up-> " 1..1 " AllergyIntoleranceCode -'} - -'AMTS -ISiKAllergieUnvertraeglichkeit::patient --> " 1..1 " ISiKPatient -ISiKAllergieUnvertraeglichkeit::encounter --> " 0..1 " ISiKKontaktGesundheitseinrichtung -ISiKAllergieUnvertraeglichkeit::recorder --> " 0..1 " MultiRef_PracPatRel -ISiKAllergieUnvertraeglichkeit::recorder .up. MultiRef_AllergyDetails - -'Specific Observations inherit from generic obseration -ISiKLebensZustand <|-- ISiKAlkoholAbusus -ISiKLebensZustand <|-- ISiKRaucherStatus -ISiKLebensZustand <|-- ISiKSchwangerschaftsstatus -ISiKLebensZustand <|-- ISiKSchwangerschaftErwarteterEntbindungstermin -ISiKLebensZustand <|-- ISiKStillstatus - -ISiKSchwangerschaftsstatus::hasMember -down-> " 0..1 " ISiKSchwangerschaftErwarteterEntbindungstermin -ISiKSchwangerschaftsstatus::value ..> " 0..1 " SchwangerschaftsstatusVS -ISiKSchwangerschaftErwarteterEntbindungstermin::code ..> " 1..1 " SchwangerschaftEtMethodeVS - -' namespace dummy { -' class Foo { -' + field1 -' + field2 -' } -' class Bar { -' + field3 -' + field4 -' } -' Foo::field1 --> Bar::field3 : foo -' Foo::field2 --> Bar::field4 : bar -' } -@enduml \ No newline at end of file diff --git a/Material/images/src/plantuml/infomodel_condobs.puml b/Material/images/src/plantuml/infomodel_condobs.puml deleted file mode 100644 index 5d076dc53..000000000 --- a/Material/images/src/plantuml/infomodel_condobs.puml +++ /dev/null @@ -1,224 +0,0 @@ -@startuml dummy -' package Dummy{ -' entity Entität01 { -' optionales Attribut -' **optionales fettes Attribut** -' * **vorgeschriebens fettes Attribut** -' } -' -' entity Entität01 { -' optionales Attribut : text -' **optionales fettes Attribut** nummer <> -' * **vorgeschriebens fettes Attribut** -' } -' Entität01 }|..|| Entität02 -' Entität03 }o..o| Entität04 -' Entität05 ||--o{ Entität06 -' Entität07 |o--|| Entität08 -' } -@enduml - - -@startuml infomodel_condobs -'verhindere Probleme mit gewinkelten Krähenfüßen -'skinparam linetype ortho - -'ISiK_Medikation.ISiKMedikationsListe::subject --> ISiK_Basis.ISiKPatient -'ISiK_Medikation.ISiKMedikationTransaction --> R4_Core.Bundle -'ISiK_Medikation.ISiKMedikationTransactionResponse --|> R4_Core.Bundle - - 'ISiKMedikation::itemReference --> ISiKMedikation - -'AMTS related -'together { -class ISiKAllergieUnvertraeglichkeit <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikallergieunvertraeglichkeit ISiK AllergieUnvertraeglichkeit]] - --- - clinicalStatus : **AllergyIntoleranceClinicalStatusCodes** - |_ coding - verificationStatus : **AllergyIntoleranceVerificationStatusCodes** - |_ coding - type : **AllergyIntoleranceType** - category : **AllergyIntoleranceCategory** - criticality : **AllergyIntoleranceCriticality** - code - |_ coding - . . . -} - -class ISiKLebensZustand <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isiklebenszustand ISiK LebensZustand]] - --- - status : **ObservationStatus** - code - subject : Reference ( **Patient** | \nGroup | Device | Location) - . . . -} - - - class ISiKAlkoholAbusus <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikalkoholabusus ISiK Alkohol Abusus]] - --- - code : snomed sct **15167005** - . . . - } - class ISiKRaucherStatus <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikraucherstatus ISiK Raucherstatus]] - --- - code : snomed sct **77176002** - . . . - } -'Oservation Childs -together { - class ISiKSchwangerschaftErwarteterEntbindungstermin <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikschwangerschafterwarteterentbindungstermin ISiK Schwangerschaft - Erwarteter Entbindungstermin]] - --- - code : **SchwangerschaftEtMethodeVS** - . . . - } - class ISiKSchwangerschaftsstatus <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikschwangerschaftsstatus ISiK Schwangerschaftsstatus]] - --- - code : loinc **82810-3** - . . . - } - - class SchwangerschaftsstatusVS <<(V,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/schwangerschaftsstatusvs Schwangerschaft Status]] from [[http://loinc.org LOINC]] - } - - class ISiKStillstatus <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikstillstatus ISiK Stillstatus]] - --- - code : snomed sct **1260078007** - . . . - } -} - - -' Weiteres Basis -together { - class ISiKPatient <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikpatient ISiK Patient]] - } - - class ISiKPersonImGesundheitsberuf <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikpersonimgesundheitsberuf ISiK Person im Gesundheitsberuf]] - } - class ISiKKontaktGesundheitseinrichtung <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikkontaktgesundheitseinrichtung ISiK Kontakt Gesundheitseinrichtung]] - } - - class ISiKAngehoeriger <<(P,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/isikangehoeriger ISiK Angehoeriger]] - --- - patient : Reference ( **Patient**) - name : HumanName - address : Address - |_ Strassenanschrift : **Adresse** - |_ Postfach : **Adresse** - . . . - } - -} - -'Valuesets Observations - - class LOINCCodes <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[http://hl7.org/fhir/ValueSet/observation-codes Observation Codes]] from [[https://loinc.org/ LOINC]] - } - - class SchwangerschaftEtMethodeVS <<(V,#8DA5C4)>>{ - Dokumentation auf Simplifier - [[https://simplifier.net/isik-basis-v4/schwangerschaftetmethodevs Schwangerschaft Estimated Methode]] from [[http://loinc.org LOINC]] - } - - -together { - class AllergyIntoleranceCriticality <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[https://hl7.org/fhir/R4/valueset-allergy-intolerance-criticality.html Allergy Intolerance Criticality]] from [[https://hl7.org/fhir/R4/codesystem-allergy-intolerance-criticality.html HL7]] - } - class AllergyIntoleranceVerificationStatus <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[https://www.hl7.org/fhir/R4/valueset-allergyintolerance-verification.html Allergy Intolerance Verification Status]] from [[https://www.hl7.org/fhir/R4/codesystem-allergyintolerance-verification.html HL7]] - } - class AllergyIntoleranceClinicalStatus <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[https://www.hl7.org/fhir/R4/valueset-allergyintolerance-clinical.html Allergy Intolerance Clinical Status]] from [[https://www.hl7.org/fhir/R4/codesystem-allergyintolerance-clinical.html HL7]] - } - class AllergyIntoleranceType <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[http://hl7.org/fhir/ValueSet/allergy-intolerance-type Allergy Intolerance Type]] from [[http://hl7.org/fhir/allergy-intolerance-type Code System of Allergy Intolerance]] - } - class AllergyIntoleranceCode <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[http://hl7.org/fhir/ValueSet/allergyintolerance-code Substance/Product, Condition, NegationCodes]] from [[http://snomed.info/sct SNOMED CT]] - } - class ReactionEventSeverity <<(V,#8DA5C4)>> { - Dokumentation auf HL7 Org - [[https://hl7.org/fhir/R4/valueset-reaction-event-severity.html Reaction Eventu Severity]] from [[https://hl7.org/fhir/R4/codesystem-reaction-event-severity.html HL7]] - } -} - - -'Relations regarding basis AMTS - -'diamonds -'together { -<> MultiRef_PracPatRel -MultiRef_PracPatRel -- ISiKPersonImGesundheitsberuf -MultiRef_PracPatRel -- ISiKPatient -MultiRef_PracPatRel -- ISiKAngehoeriger -<> MultiRef_AllergyDetails -MultiRef_AllergyDetails -up- AllergyIntoleranceCriticality -MultiRef_AllergyDetails -up- AllergyIntoleranceVerificationStatus -MultiRef_AllergyDetails -up- AllergyIntoleranceClinicalStatus -MultiRef_AllergyDetails -up- ReactionEventSeverity -MultiRef_AllergyDetails -up- AllergyIntoleranceType -MultiRef_AllergyDetails -up-> " 1..1 " AllergyIntoleranceCode -'} - -'AMTS -ISiKAllergieUnvertraeglichkeit::patient --> " 1..1 " ISiKPatient -ISiKAllergieUnvertraeglichkeit::encounter --> " 0..1 " ISiKKontaktGesundheitseinrichtung -ISiKAllergieUnvertraeglichkeit::recorder --> " 0..1 " MultiRef_PracPatRel -ISiKAllergieUnvertraeglichkeit::recorder .up. MultiRef_AllergyDetails - -'Specific Observations inherit from generic obseration -ISiKLebensZustand <|-- ISiKAlkoholAbusus -ISiKLebensZustand <|-- ISiKRaucherStatus -ISiKLebensZustand <|-- ISiKSchwangerschaftsstatus -ISiKLebensZustand <|-- ISiKSchwangerschaftErwarteterEntbindungstermin -ISiKLebensZustand <|-- ISiKStillstatus - -ISiKSchwangerschaftsstatus::hasMember -down-> " 0..1 " ISiKSchwangerschaftErwarteterEntbindungstermin -ISiKSchwangerschaftsstatus::value ..> " 0..1 " SchwangerschaftsstatusVS -ISiKSchwangerschaftErwarteterEntbindungstermin::code ..> " 1..1 " SchwangerschaftEtMethodeVS - -' namespace dummy { -' class Foo { -' + field1 -' + field2 -' } -' class Bar { -' + field3 -' + field4 -' } -' Foo::field1 --> Bar::field3 : foo -' Foo::field2 --> Bar::field4 : bar -' } -@enduml \ No newline at end of file diff --git a/Material/images/src/plantuml/resourcediagram.puml b/Material/images/src/plantuml/resourcediagram.puml index 58a115fbd..982ba9a42 100644 --- a/Material/images/src/plantuml/resourcediagram.puml +++ b/Material/images/src/plantuml/resourcediagram.puml @@ -34,6 +34,10 @@ set separator none 'ISiK_Medikation.ISiKMedikationTransactionResponse --|> R4_Core.Bundle namespace ISiK_Basis { + class identifierAbrechnungsnummer <<(P,#8DA5C4)>>{ + Dokumentation auf Simplifier + [[https://simplifier.net/isik-basis-v3/identifierabrechnungsnummer Identifier-Profil]] für die "Fallnummer" + } 'ISiKMedikation::itemReference --> ISiKMedikation class ISiKAbrechnungsfall <<(P,#8DA5C4)>>{ @@ -54,6 +58,36 @@ namespace ISiK_Basis { |_ coverage } + class ISiKAngehoeriger <<(P,#8DA5C4)>>{ + patient : Reference ( **Patient**) + name : HumanName // deutsches Basisprofil + address : Address + |_ Strassenanschrift : Adresse // deutsches BasisprofilPattern + |_ extension + |_ Stadtteil + |_ type : AddressType.both + |_ line + |_ extension + |_ Strasse + |_ Hausnummer + |_ Adresszusatz + |_ Postfach + |_ city + |_ postalCode + |_ country + |_ Postfach : Adresse // deutsches BasisprofilPattern + |_ type : AddressType.postal + |_ line + |_ extension + |_ Strasse + |_ Hausnummer + |_ Adresszusatz + |_ Postfach + |_ city + |_ postalCode + |_ country + } + class ISiKAllergieUnvertraeglichkeit <<(P,#8DA5C4)>>{ clinicalStatus : **AllergyIntoleranceClinicalStatusCodes** |_ coding @@ -116,101 +150,6 @@ namespace ISiK_Basis { |_ code |_ text } - - class ISiKAngehoeriger <<(P,#8DA5C4)>>{ - patient : Reference ( **Patient**) - name : HumanName // deutsches Basisprofil - address : Address - |_ Strassenanschrift : Adresse // deutsches BasisprofilPattern - |_ extension - |_ Stadtteil - |_ type : AddressType.both - |_ line - |_ extension - |_ Strasse - |_ Hausnummer - |_ Adresszusatz - |_ Postfach - |_ city - |_ postalCode - |_ country - |_ Postfach : Adresse // deutsches BasisprofilPattern - |_ type : AddressType.postal - |_ line - |_ extension - |_ Strasse - |_ Hausnummer - |_ Adresszusatz - |_ Postfach - |_ city - |_ postalCode - |_ country - } - - class ISiKBerichtBundle <<(P,#8DA5C4)>>{ - identifier - type : **document** - timestamp - entry - |_ fullUrl - |_ resource - |_ search - |_ request - |_ response - |_ Composition - |_ resource : **ISiKBerichtSubSysteme** - } - - class ISiKBerichtSubSysteme <<(P,#8DA5C4)>>{ - - } - - namespace Observations { - - class ISiKLebensZustand <<(P,#8DA5C4)>>{ - status : **ObservationStatus** - code - subject : Reference ( **Patient** | \nGroup | Device | Location) - |_ reference - effective[x] - value[x] - } - - class ISiKAlkoholAbusus <<(P,#8DA5C4)>>{ - category : secondary-finding **social-history** - code : snomed sct **15167005** - value[x] - |_ valueBoolean - } - - class ISiKRaucherStatus <<(P,#8DA5C4)>>{ - category : secondary-finding **social-history** - code : snomed sct **77176002** - value[x] - |_ valueBoolean - } - - class ISiKSchwangerschaftErwarteterEntbindungstermin <<(P,#8DA5C4)>>{ - code : **SchwangerschaftEtMethodeVS** - value[x] - |_ valueDateTime - } - - class ISiKSchwangerschaftsstatus <<(P,#8DA5C4)>>{ - code : loinc **82810-3** - value[x] - |_ valueCodeableConcept : **SchwangerschaftsstatusVS** - hasMember : Reference \n\t( **ISiKSchwangerschaftErwarteterEntbindungstermin** ) - |_ reference - } - - class ISiKStillstatus <<(P,#8DA5C4)>>{ - code : snomed sct **1260078007** - value[x] - |_ valueBoolean - } - - } namespace ValueSets { class ISiKAccountIdentifierType <<(V,#8DA5C4)>>{ @@ -257,7 +196,7 @@ namespace ISiK_Basis { namespace DE_Basisprofile_R4 { - class Basisprofile_DE <<(M,#FFAAAA)>>{ + class Basisprofile_Modul <<(M,#FFAAAA)>>{ Dokumentation auf HL7 Org [[https://simplifier.net/basisprofil-de-r4 Basisprofil DE (RE4)]] } @@ -348,19 +287,29 @@ namespace HL7_FHIR_R4_Core { [[https://hl7.org/fhir/R4/valueset-reaction-event-severity.html Reaction Eventu Severity]] Das entsprechende Standard-ValueSet beeinhatet das komplette \nCode System des zugehörigen [[https://hl7.org/fhir/R4/codesystem-reaction-event-severity.html Code System of Severity]] } - - class ObservationCategoryCodes <<(V,#8DA5C4)>>{ + class ObservationCategory <<(V,#8DA5C4)>>{ Dokumentation auf HL7 Org - [[https://hl7.org/fhir/R4/valueset-observation-category Observation Category]] - Includes all codes from the underlying code system - [[https://hl7.org/fhir/R4/codesystem-observation-category.html Code System of Observation Category]] + [[https://hl7.org/fhir/R4/valueset-observation-category.html Observation Category]] + Das entsprechende Standard-ValueSet beeinhatet das komplette \nCode System des zugehörigen [[https://hl7.org/fhir/R4/codesystem-observation-category.html Code System of Observation Category]] + } } - class ObservationStatus <<(V,#8DA5C4)>>{ - Dokumentation auf HL7 Org - [[https://hl7.org/fhir/R4/valueset-observation-status Observation Status]] - Includes all codes from the underlying code system - [[https://hl7.org/fhir/R4/codesystem-observation-status.html Code System of Observation Status]] +namespace ISiK_Basis { + class Basismodul_Stufe_4 <<(M,#FFDC36)>>{ + Dokumentation auf Simplifier + [[https://simplifier.net/isik-basis-v3/~introduction ISiK Basis Stufe 3]] + } + class ISiKPatient <<(P,#8DA5C4)>>{ + Dokumentation auf Simplifier + [[https://simplifier.net/isik-basis-v3/isikpatient ISiK Patient]] + } + class ISiKKontaktGesundheitseinrichtung <<(P,#8DA5C4)>>{ + Dokumentation auf Simplifier + [[https://simplifier.net/isik-basis-v3/isikkontaktgesundheitseinrichtung ISiK Kontakt Gesundheitseinrichtung]] + } + class ISiKPractitioner <<(P,#8DA5C4)>>{ + Dokumentation auf Simplifier + [[https://simplifier.net/isik-basis-v3/isikpersonimgesundheitsberuf ISiK Person im Gesundheitsberuf]] } } diff --git a/Material/images/src/plantuml/usecases.puml b/Material/images/src/plantuml/usecases.puml index d6d777caf..cd2dd2f7a 100644 --- a/Material/images/src/plantuml/usecases.puml +++ b/Material/images/src/plantuml/usecases.puml @@ -66,7 +66,7 @@ storage adverseUC as "Adverse Use Cases" { (Merhfachdokumentation) (Dokumentationslücken) (Nicht-Verfügbarkeit) - (InformationsVerlust) + (Verlust) } storage techUC as "Technical Use Case" { diff --git a/Resources/fsh-generated/fsh-index.json b/Resources/fsh-generated/fsh-index.json index d7a1215d8..f23375a6c 100644 --- a/Resources/fsh-generated/fsh-index.json +++ b/Resources/fsh-generated/fsh-index.json @@ -55,13 +55,21 @@ "startLine": 24, "endLine": 38 }, + { + "outputFile": "Bundle-SubscriptionNotificationBundleExample.json", + "fshName": "SubscriptionNotificationBundleExample", + "fshType": "Instance", + "fshFile": "IsiKPatientMerge.fsh", + "startLine": 93, + "endLine": 102 + }, { "outputFile": "CapabilityStatement-ISiKCapabilityStatementBasisServer.json", "fshName": "ISiKCapabilityStatementBasisServer", "fshType": "Instance", "fshFile": "ISiKCapabilityStatementBasisServer.fsh", "startLine": 1, - "endLine": 775 + "endLine": 810 }, { "outputFile": "CodeSystem-CodeSystemExample.json", @@ -164,48 +172,72 @@ "fshName": "ISiKAlkoholAbususBeispiel", "fshType": "Instance", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 72, - "endLine": 81 + "startLine": 73, + "endLine": 82 }, { "outputFile": "Observation-ISiKRaucherStatusBeispiel.json", "fshName": "ISiKRaucherStatusBeispiel", "fshType": "Instance", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 93, - "endLine": 102 + "startLine": 94, + "endLine": 103 }, { "outputFile": "Observation-ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel.json", "fshName": "ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel", "fshType": "Instance", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 51, - "endLine": 60 + "startLine": 52, + "endLine": 61 }, { "outputFile": "Observation-ISiKSchwangerschaftsstatusBeispiel.json", "fshName": "ISiKSchwangerschaftsstatusBeispiel", "fshType": "Instance", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 31, - "endLine": 40 + "startLine": 32, + "endLine": 41 }, { "outputFile": "Observation-ISiKStillstatusBeispiel.json", "fshName": "ISiKStillstatusBeispiel", "fshType": "Instance", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 114, - "endLine": 124 + "startLine": 115, + "endLine": 125 + }, + { + "outputFile": "Patient-DorisQuelle.json", + "fshName": "DorisQuelle", + "fshType": "Instance", + "fshFile": "IsiKPatientMerge.fsh", + "startLine": 46, + "endLine": 58 + }, + { + "outputFile": "Patient-DorisResultat.json", + "fshName": "DorisResultat", + "fshType": "Instance", + "fshFile": "IsiKPatientMerge.fsh", + "startLine": 74, + "endLine": 91 + }, + { + "outputFile": "Patient-DorisZiel.json", + "fshName": "DorisZiel", + "fshType": "Instance", + "fshFile": "IsiKPatientMerge.fsh", + "startLine": 60, + "endLine": 72 }, { "outputFile": "Patient-PatientinMusterfrau.json", "fshName": "PatientinMusterfrau", "fshType": "Instance", "fshFile": "ISiKPatient.fsh", - "startLine": 116, - "endLine": 166 + "startLine": 122, + "endLine": 172 }, { "outputFile": "Patient-PatientinMusterfrauMinimal.json", @@ -268,8 +300,8 @@ "fshName": "ISiKAlkoholAbusus", "fshType": "Profile", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 62, - "endLine": 70 + "startLine": 63, + "endLine": 71 }, { "outputFile": "StructureDefinition-ISiKAllergieUnvertraeglichkeit.json", @@ -341,7 +373,7 @@ "fshType": "Profile", "fshFile": "ISiKLebenszustandOberservations.fsh", "startLine": 1, - "endLine": 14 + "endLine": 15 }, { "outputFile": "StructureDefinition-ISiKPatient.json", @@ -349,7 +381,7 @@ "fshType": "Profile", "fshFile": "ISiKPatient.fsh", "startLine": 1, - "endLine": 114 + "endLine": 120 }, { "outputFile": "StructureDefinition-ISiKPersonImGesundheitsberuf.json", @@ -372,32 +404,32 @@ "fshName": "ISiKRaucherStatus", "fshType": "Profile", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 83, - "endLine": 91 + "startLine": 84, + "endLine": 92 }, { "outputFile": "StructureDefinition-ISiKSchwangerschaftErwarteterEntbindungstermin.json", "fshName": "ISiKSchwangerschaftErwarteterEntbindungstermin", "fshType": "Profile", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 42, - "endLine": 49 + "startLine": 43, + "endLine": 50 }, { "outputFile": "StructureDefinition-ISiKSchwangerschaftsstatus.json", "fshName": "ISiKSchwangerschaftsstatus", "fshType": "Profile", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 17, - "endLine": 29 + "startLine": 18, + "endLine": 30 }, { "outputFile": "StructureDefinition-ISiKStillstatus.json", "fshName": "ISiKStillstatus", "fshType": "Profile", "fshFile": "ISiKLebenszustandOberservations.fsh", - "startLine": 104, - "endLine": 112 + "startLine": 105, + "endLine": 113 }, { "outputFile": "StructureDefinition-ISiKValueSet.json", @@ -439,6 +471,22 @@ "startLine": 123, "endLine": 127 }, + { + "outputFile": "StructureDefinition-patient-merge-subscription.json", + "fshName": "PatientMergeSubscription", + "fshType": "Profile", + "fshFile": "IsiKPatientMerge.fsh", + "startLine": 2, + "endLine": 17 + }, + { + "outputFile": "Subscription-PatientMergeSubscriptionExample.json", + "fshName": "PatientMergeSubscriptionExample", + "fshType": "Instance", + "fshFile": "IsiKPatientMerge.fsh", + "startLine": 19, + "endLine": 30 + }, { "outputFile": "ValueSet-DiagnosesSCT.json", "fshName": "DiagnosesSCT", @@ -447,6 +495,14 @@ "startLine": 1, "endLine": 8 }, + { + "outputFile": "ValueSet-FhirMimeTypeVS.json", + "fshName": "FhirMimeTypeVS", + "fshType": "ValueSet", + "fshFile": "IsiKPatientMerge.fsh", + "startLine": 39, + "endLine": 44 + }, { "outputFile": "ValueSet-ISiKAccountType.json", "fshName": "ISiKAccountType", @@ -487,6 +543,14 @@ "startLine": 16, "endLine": 25 }, + { + "outputFile": "ValueSet-RestAndWSSubscriptionChannelType.json", + "fshName": "RestAndWSSubscriptionChannelType", + "fshType": "ValueSet", + "fshFile": "IsiKPatientMerge.fsh", + "startLine": 32, + "endLine": 37 + }, { "outputFile": "ValueSet-SchwangerschaftEtMethodeVS.json", "fshName": "SchwangerschaftEtMethodeVS", diff --git a/Resources/fsh-generated/fsh-index.txt b/Resources/fsh-generated/fsh-index.txt index d223ca2b8..d4da353a9 100644 --- a/Resources/fsh-generated/fsh-index.txt +++ b/Resources/fsh-generated/fsh-index.txt @@ -6,7 +6,8 @@ Binary-Binary-JPEG-Example.json Binary- Binary-Binary-PDF-Example-short.json Binary-PDF-Example-short Instance ISiKBinary.fsh 23 - 28 Binary-Binary-PDF-Example.json Binary-PDF-Example Instance ISiKBinary.fsh 36 - 41 Bundle-ISiKBundle-Example.json ISiKBundle-Example Instance ISiKBerichtBundle.fsh 24 - 38 -CapabilityStatement-ISiKCapabilityStatementBasisServer.json ISiKCapabilityStatementBasisServer Instance ISiKCapabilityStatementBasisServer.fsh 1 - 775 +Bundle-SubscriptionNotificationBundleExample.json SubscriptionNotificationBundleExample Instance IsiKPatientMerge.fsh 93 - 102 +CapabilityStatement-ISiKCapabilityStatementBasisServer.json ISiKCapabilityStatementBasisServer Instance ISiKCapabilityStatementBasisServer.fsh 1 - 810 CodeSystem-CodeSystemExample.json CodeSystemExample Instance ISiKCodeSystem.fsh 17 - 27 Composition-composition-blutdruck.json composition-blutdruck Instance ISiKBerichtSubSysteme.fsh 66 - 83 Condition-BehandlungsDiagnoseFreitext.json BehandlungsDiagnoseFreitext Instance ISiKDiagnose.fsh 123 - 130 @@ -19,12 +20,15 @@ Coverage-CoverageGesetzlich.json Coverag Coverage-CoveragePrivat.json CoveragePrivat Instance ISiKVersicherungsverhaeltnisSelbstzahler.fsh 16 - 22 Encounter-Fachabteilungskontakt.json Fachabteilungskontakt Instance ISiKKontaktGesundheitseinrichtung.fsh 136 - 173 Encounter-FachabteilungskontaktMinimal.json FachabteilungskontaktMinimal Instance ISiKBerichtBundle.fsh 55 - 68 -Observation-ISiKAlkoholAbususBeispiel.json ISiKAlkoholAbususBeispiel Instance ISiKLebenszustandOberservations.fsh 72 - 81 -Observation-ISiKRaucherStatusBeispiel.json ISiKRaucherStatusBeispiel Instance ISiKLebenszustandOberservations.fsh 93 - 102 -Observation-ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel.json ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel Instance ISiKLebenszustandOberservations.fsh 51 - 60 -Observation-ISiKSchwangerschaftsstatusBeispiel.json ISiKSchwangerschaftsstatusBeispiel Instance ISiKLebenszustandOberservations.fsh 31 - 40 -Observation-ISiKStillstatusBeispiel.json ISiKStillstatusBeispiel Instance ISiKLebenszustandOberservations.fsh 114 - 124 -Patient-PatientinMusterfrau.json PatientinMusterfrau Instance ISiKPatient.fsh 116 - 166 +Observation-ISiKAlkoholAbususBeispiel.json ISiKAlkoholAbususBeispiel Instance ISiKLebenszustandOberservations.fsh 73 - 82 +Observation-ISiKRaucherStatusBeispiel.json ISiKRaucherStatusBeispiel Instance ISiKLebenszustandOberservations.fsh 94 - 103 +Observation-ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel.json ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel Instance ISiKLebenszustandOberservations.fsh 52 - 61 +Observation-ISiKSchwangerschaftsstatusBeispiel.json ISiKSchwangerschaftsstatusBeispiel Instance ISiKLebenszustandOberservations.fsh 32 - 41 +Observation-ISiKStillstatusBeispiel.json ISiKStillstatusBeispiel Instance ISiKLebenszustandOberservations.fsh 115 - 125 +Patient-DorisQuelle.json DorisQuelle Instance IsiKPatientMerge.fsh 46 - 58 +Patient-DorisResultat.json DorisResultat Instance IsiKPatientMerge.fsh 74 - 91 +Patient-DorisZiel.json DorisZiel Instance IsiKPatientMerge.fsh 60 - 72 +Patient-PatientinMusterfrau.json PatientinMusterfrau Instance ISiKPatient.fsh 122 - 172 Patient-PatientinMusterfrauMinimal.json PatientinMusterfrauMinimal Instance ISiKBerichtBundle.fsh 41 - 53 Practitioner-PractitionerWalterArzt.json PractitionerWalterArzt Instance ISiKPersonImGesundheitsberuf.fsh 93 - 128 Procedure-Appendektomie.json Appendektomie Instance ISiKProzedur.fsh 52 - 65 @@ -32,7 +36,7 @@ RelatedPerson-ISiKAngehoerigerMustermann.json ISiKAng SearchParameter-Encounter-date-start.json Encounter-date-start Instance ISiKKontaktGesundheitseinrichtung.fsh 216 - 234 SearchParameter-Encounter-end-date.json Encounter-end-date Instance ISiKKontaktGesundheitseinrichtung.fsh 236 - 254 StructureDefinition-ISiKAbrechnungsfall.json ISiKAbrechnungsfall Profile ISiKAbrechnungsfall.fsh 1 - 29 -StructureDefinition-ISiKAlkoholAbusus.json ISiKAlkoholAbusus Profile ISiKLebenszustandOberservations.fsh 62 - 70 +StructureDefinition-ISiKAlkoholAbusus.json ISiKAlkoholAbusus Profile ISiKLebenszustandOberservations.fsh 63 - 71 StructureDefinition-ISiKAllergieUnvertraeglichkeit.json ISiKAllergieUnvertraeglichkeit Profile ISiKAllergieUnvertraeglichkeit.fsh 1 - 105 StructureDefinition-ISiKAngehoeriger.json ISiKAngehoeriger Profile ISiKAngehoeriger.fsh 1 - 45 StructureDefinition-ISiKBerichtBundle.json ISiKBerichtBundle Profile ISiKBerichtBundle.fsh 1 - 22 @@ -41,24 +45,28 @@ StructureDefinition-ISiKBinary.json ISiKBin StructureDefinition-ISiKCodeSystem.json ISiKCodeSystem Profile ISiKCodeSystem.fsh 1 - 15 StructureDefinition-ISiKDiagnose.json ISiKDiagnose Profile ISiKDiagnose.fsh 1 - 55 StructureDefinition-ISiKKontaktGesundheitseinrichtung.json ISiKKontaktGesundheitseinrichtung Profile ISiKKontaktGesundheitseinrichtung.fsh 1 - 120 -StructureDefinition-ISiKLebensZustand.json ISiKLebensZustand Profile ISiKLebenszustandOberservations.fsh 1 - 14 -StructureDefinition-ISiKPatient.json ISiKPatient Profile ISiKPatient.fsh 1 - 114 +StructureDefinition-ISiKLebensZustand.json ISiKLebensZustand Profile ISiKLebenszustandOberservations.fsh 1 - 15 +StructureDefinition-ISiKPatient.json ISiKPatient Profile ISiKPatient.fsh 1 - 120 StructureDefinition-ISiKPersonImGesundheitsberuf.json ISiKPersonImGesundheitsberuf Profile ISiKPersonImGesundheitsberuf.fsh 1 - 89 StructureDefinition-ISiKProzedur.json ISiKProzedur Profile ISiKProzedur.fsh 1 - 50 -StructureDefinition-ISiKRaucherStatus.json ISiKRaucherStatus Profile ISiKLebenszustandOberservations.fsh 83 - 91 -StructureDefinition-ISiKSchwangerschaftErwarteterEntbindungstermin.json ISiKSchwangerschaftErwarteterEntbindungstermin Profile ISiKLebenszustandOberservations.fsh 42 - 49 -StructureDefinition-ISiKSchwangerschaftsstatus.json ISiKSchwangerschaftsstatus Profile ISiKLebenszustandOberservations.fsh 17 - 29 -StructureDefinition-ISiKStillstatus.json ISiKStillstatus Profile ISiKLebenszustandOberservations.fsh 104 - 112 +StructureDefinition-ISiKRaucherStatus.json ISiKRaucherStatus Profile ISiKLebenszustandOberservations.fsh 84 - 92 +StructureDefinition-ISiKSchwangerschaftErwarteterEntbindungstermin.json ISiKSchwangerschaftErwarteterEntbindungstermin Profile ISiKLebenszustandOberservations.fsh 43 - 50 +StructureDefinition-ISiKSchwangerschaftsstatus.json ISiKSchwangerschaftsstatus Profile ISiKLebenszustandOberservations.fsh 18 - 30 +StructureDefinition-ISiKStillstatus.json ISiKStillstatus Profile ISiKLebenszustandOberservations.fsh 105 - 113 StructureDefinition-ISiKValueSet.json ISiKValueSet Profile ISiKValueSet.fsh 1 - 22 StructureDefinition-ISiKVersicherungsverhaeltnisGesetzlich.json ISiKVersicherungsverhaeltnisGesetzlich Profile ISiKVersicherungsverhaeltnisGesetzlich.fsh 1 - 41 StructureDefinition-ISiKVersicherungsverhaeltnisSelbstzahler.json ISiKVersicherungsverhaeltnisSelbstzahler Profile ISiKVersicherungsverhaeltnisSelbstzahler.fsh 1 - 14 StructureDefinition-PlannedEndDate.json PlannedEndDate Extension ISiKKontaktGesundheitseinrichtung.fsh 130 - 134 StructureDefinition-PlannedStartDate.json PlannedStartDate Extension ISiKKontaktGesundheitseinrichtung.fsh 123 - 127 +StructureDefinition-patient-merge-subscription.json PatientMergeSubscription Profile IsiKPatientMerge.fsh 2 - 17 +Subscription-PatientMergeSubscriptionExample.json PatientMergeSubscriptionExample Instance IsiKPatientMerge.fsh 19 - 30 ValueSet-DiagnosesSCT.json DiagnosesSCT ValueSet valueSets.fsh 1 - 8 +ValueSet-FhirMimeTypeVS.json FhirMimeTypeVS ValueSet IsiKPatientMerge.fsh 39 - 44 ValueSet-ISiKAccountType.json ISiKAccountType ValueSet valueSets.fsh 35 - 40 ValueSet-ISiKLocationPhysicalType.json ISiKLocationPhysicalType ValueSet valueSets.fsh 27 - 32 ValueSet-ISiKValueSetExample.json ISiKValueSetExample Instance ISiKValueSet.fsh 24 - 37 ValueSet-ProzedurenCodesSCT.json ProzedurenCodesSCT ValueSet valueSets.fsh 10 - 14 ValueSet-ProzedurenKategorieSCT.json ProzedurenKategorieSCT ValueSet valueSets.fsh 16 - 25 +ValueSet-RestAndWSSubscriptionChannelType.json RestAndWSSubscriptionChannelType ValueSet IsiKPatientMerge.fsh 32 - 37 ValueSet-SchwangerschaftEtMethodeVS.json SchwangerschaftEtMethodeVS ValueSet valueSets.fsh 50 - 56 ValueSet-SchwangerschaftsstatusVS.json SchwangerschaftsstatusVS ValueSet valueSets.fsh 42 - 48 \ No newline at end of file diff --git a/Resources/fsh-generated/resources/CapabilityStatement-ISiKCapabilityStatementBasisServer.json b/Resources/fsh-generated/resources/CapabilityStatement-ISiKCapabilityStatementBasisServer.json index aca62b001..ccdd9d154 100644 --- a/Resources/fsh-generated/resources/CapabilityStatement-ISiKCapabilityStatementBasisServer.json +++ b/Resources/fsh-generated/resources/CapabilityStatement-ISiKCapabilityStatementBasisServer.json @@ -1775,6 +1775,103 @@ ] } ] + }, + { + "extension": [ + { + "url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation", + "valueCode": "MAY" + } + ], + "type": "Composition", + "supportedProfile": [ + "https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtSubSysteme" + ] + }, + { + "extension": [ + { + "url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation", + "valueCode": "SHALL" + } + ], + "type": "Bundle", + "supportedProfile": [ + "https://gematik.de/fhir/isik/StructureDefinition/ISiKBerichtBundle" + ] + }, + { + "extension": [ + { + "url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/capabilitystatement-subscriptiontopic-canonical", + "valueCode": "SHALL", + "valueCanonical": "https://gematik.de/fhir/isik/SubscriptionTopic/patient-merge" + } + ], + "type": "Subscription", + "supportedProfile": [ + "https://gematik.de/fhir/isik/StructureDefinition/patient-merge-subscription" + ], + "_supportedProfile": [ + { + "extension": [ + { + "url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation", + "valueCode": "MAY" + } + ] + } + ], + "interaction": [ + { + "extension": [ + { + "url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation", + "valueCode": "MAY" + } + ], + "code": "read" + }, + { + "extension": [ + { + "url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation", + "valueCode": "MAY" + } + ], + "code": "create" + }, + { + "extension": [ + { + "url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation", + "valueCode": "MAY" + } + ], + "code": "update" + }, + { + "extension": [ + { + "url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation", + "valueCode": "MAY" + } + ], + "code": "delete" + } + ], + "operation": [ + { + "extension": [ + { + "url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation", + "valueCode": "MAY" + } + ], + "name": "$get-ws-binding-token", + "definition": "http://hl7.org/fhir/uv/subscriptions-backport/OperationDefinition/backport-subscription-get-ws-binding-token" + } + ] } ] } diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKAbrechnungsfall.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKAbrechnungsfall.json index b168b8989..a652a25e5 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKAbrechnungsfall.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKAbrechnungsfall.json @@ -10,18 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil beschreibt die Gruppierung von medizinischen Leistungen in ISiK-Szenarien", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - } - ], "kind": "resource", "abstract": false, "type": "Account", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKAlkoholAbusus.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKAlkoholAbusus.json index 7e90576c5..13a7b56ff 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKAlkoholAbusus.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKAlkoholAbusus.json @@ -10,38 +10,6 @@ "date": "2024-01-16", "publisher": "gematik GmbH", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "sct-concept", - "uri": "http://snomed.info/conceptdomain", - "name": "SNOMED CT Concept Domain Binding" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "sct-attr", - "uri": "http://snomed.org/attributebinding", - "name": "SNOMED CT Attribute Binding" - } - ], "kind": "resource", "abstract": false, "type": "Observation", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKAllergieUnvertraeglichkeit.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKAllergieUnvertraeglichkeit.json index 07e7a61e5..b5fc43180 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKAllergieUnvertraeglichkeit.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKAllergieUnvertraeglichkeit.json @@ -10,23 +10,6 @@ "publisher": "gematik GmbH", "description": "Diese Profil ermöglicht die Dokumentation von Allergien und Unverträglichkeiten in ISiK Szenarien.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - } - ], "kind": "resource", "abstract": false, "type": "AllergyIntolerance", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKAngehoeriger.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKAngehoeriger.json index d16c8395c..4185f530b 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKAngehoeriger.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKAngehoeriger.json @@ -10,23 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil ermöglicht die Nutzung von Angehörigen in ISiK Szenarien.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - } - ], "kind": "resource", "abstract": false, "type": "RelatedPerson", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKBerichtBundle.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKBerichtBundle.json index d7bdbb264..24d2aacc9 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKBerichtBundle.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKBerichtBundle.json @@ -11,28 +11,6 @@ "publisher": "gematik GmbH", "description": "A document style representation of the receipt (complete, self-contained, signed)", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "cda", - "uri": "http://hl7.org/v3/cda", - "name": "CDA (R2)" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - } - ], "kind": "resource", "abstract": false, "type": "Bundle", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKBerichtSubSysteme.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKBerichtSubSysteme.json index 48b4a7e29..070b85edd 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKBerichtSubSysteme.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKBerichtSubSysteme.json @@ -10,33 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil ermöglicht die Krankenhaus-interne Übermittlung eines Berichtes in Form eines Dokumentes, die in ISiK Szenarien von Subsystemen an Primärsysteme gesendet werden.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "cda", - "uri": "http://hl7.org/v3/cda", - "name": "CDA (R2)" - }, - { - "identity": "fhirdocumentreference", - "uri": "http://hl7.org/fhir/documentreference", - "name": "FHIR DocumentReference" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - } - ], "kind": "resource", "abstract": false, "type": "Composition", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKBinary.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKBinary.json index c469446df..d0de5e597 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKBinary.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKBinary.json @@ -11,13 +11,6 @@ "publisher": "gematik GmbH", "description": "Die Binary-Ressource erlaubt den Umgang mit FHIR-fremden Formaten (z.B. PDFs, Bilder, CDA) innerhalb des FHIR-Frameworks.\r\nDazu werden die Daten base64-codiert in der Binary-Ressource (in XML oder JSON) transportiert oder \r\nüber die REST-API am Binary-Endpunkt in ihrem nativen Format bereitgestellt. \r\nBinary-Ressourcen werden von Attachment-Elementen in DocumentReference-Ressourcen verlinkt und damit in den Kontext anderer FHIR-Ressourcen\r\n(z.B. Patient und Encounter) gestellt. ", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - } - ], "kind": "resource", "abstract": false, "type": "Binary", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKCodeSystem.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKCodeSystem.json index acefcd1ad..bad1c6cf5 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKCodeSystem.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKCodeSystem.json @@ -10,28 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil beschreibt die maschinenlesbare Repräsentation von system-sepzifischen Kodierungen in ISiK-Szenarien", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "objimpl", - "uri": "http://hl7.org/fhir/object-implementation", - "name": "Object Implementation Information" - } - ], "kind": "resource", "abstract": false, "type": "CodeSystem", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKDiagnose.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKDiagnose.json index bb284b7e6..433ce23e1 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKDiagnose.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKDiagnose.json @@ -10,38 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil ermöglicht die Nutzung von Diagnosen in ISiK Szenarien.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "sct-concept", - "uri": "http://snomed.info/conceptdomain", - "name": "SNOMED CT Concept Domain Binding" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "sct-attr", - "uri": "http://snomed.org/attributebinding", - "name": "SNOMED CT Attribute Binding" - } - ], "kind": "resource", "abstract": false, "type": "Condition", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKKontaktGesundheitseinrichtung.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKKontaktGesundheitseinrichtung.json index 656d7166d..a62909492 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKKontaktGesundheitseinrichtung.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKKontaktGesundheitseinrichtung.json @@ -10,28 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil ermöglicht die Herstellung eines Fallbezuges welcher in der Mehrheit der ISiK Szenarien im Krankenhaus essentiell ist.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - } - ], "kind": "resource", "abstract": false, "type": "Encounter", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKLebensZustand.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKLebensZustand.json index f171fdade..24aad5c23 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKLebensZustand.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKLebensZustand.json @@ -11,38 +11,6 @@ "publisher": "gematik GmbH", "description": "Basisprofil für ISiKLebensZustand Observation", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "sct-concept", - "uri": "http://snomed.info/conceptdomain", - "name": "SNOMED CT Concept Domain Binding" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "sct-attr", - "uri": "http://snomed.org/attributebinding", - "name": "SNOMED CT Attribute Binding" - } - ], "kind": "resource", "abstract": false, "type": "Observation", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json index 0df2a5536..786da5ba1 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKPatient.json @@ -10,33 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil beschreibt die Nutzung von administrativen Patientendaten in ISiK-Szenarien.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "cda", - "uri": "http://hl7.org/v3/cda", - "name": "CDA (R2)" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "loinc", - "uri": "http://loinc.org", - "name": "LOINC code for the element" - } - ], "kind": "resource", "abstract": false, "type": "Patient", @@ -283,7 +256,7 @@ ], "rules": "open" }, - "comment": "In order to maintain the differntiations of name parts as given in the VSDM dataset or qualify prefixes as academic titles, vendors can opt to support the extensions specified in the German HumanName Base Profile https://simplifier.net/basisprofil-de-r4/humannamedebasis\r\nThis is however not required within the scope of this specification.", + "comment": "In order to maintain the differentiations of name parts as given in the VSDM dataset or qualify prefixes as academic titles, vendors can opt to support the extensions specified in the German HumanName Base Profile https://simplifier.net/basisprofil-de-r4/humannamedebasis\r\nThis is however not required within the scope of this specification.", "min": 1, "mustSupport": true }, diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKPersonImGesundheitsberuf.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKPersonImGesundheitsberuf.json index 3310e9e91..4d90bea96 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKPersonImGesundheitsberuf.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKPersonImGesundheitsberuf.json @@ -10,28 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil ermöglicht die Nutzung von in Gesundheitsberufen tätigen Personen in ISiK Szenarien.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "servd", - "uri": "http://www.omg.org/spec/ServD/1.0/", - "name": "ServD" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - } - ], "kind": "resource", "abstract": false, "type": "Practitioner", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKProzedur.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKProzedur.json index 016678e7a..b8f7b156d 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKProzedur.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKProzedur.json @@ -10,28 +10,6 @@ "publisher": "gematik GmbH", "description": "Diese Profil ermöglicht die Nutzung von Prozedur-bezogenen Informationen in ISiK Szenarien.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - } - ], "kind": "resource", "abstract": false, "type": "Procedure", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKRaucherStatus.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKRaucherStatus.json index 092a6584e..f80636fa3 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKRaucherStatus.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKRaucherStatus.json @@ -10,38 +10,6 @@ "date": "2024-01-16", "publisher": "gematik GmbH", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "sct-concept", - "uri": "http://snomed.info/conceptdomain", - "name": "SNOMED CT Concept Domain Binding" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "sct-attr", - "uri": "http://snomed.org/attributebinding", - "name": "SNOMED CT Attribute Binding" - } - ], "kind": "resource", "abstract": false, "type": "Observation", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKSchwangerschaftErwarteterEntbindungstermin.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKSchwangerschaftErwarteterEntbindungstermin.json index 47fd1eb23..2d22f259a 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKSchwangerschaftErwarteterEntbindungstermin.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKSchwangerschaftErwarteterEntbindungstermin.json @@ -10,38 +10,6 @@ "date": "2024-01-16", "publisher": "gematik GmbH", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "sct-concept", - "uri": "http://snomed.info/conceptdomain", - "name": "SNOMED CT Concept Domain Binding" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "sct-attr", - "uri": "http://snomed.org/attributebinding", - "name": "SNOMED CT Attribute Binding" - } - ], "kind": "resource", "abstract": false, "type": "Observation", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKSchwangerschaftsstatus.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKSchwangerschaftsstatus.json index cd0c7a2a6..c8306e5fa 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKSchwangerschaftsstatus.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKSchwangerschaftsstatus.json @@ -7,38 +7,6 @@ "status": "draft", "description": "Schwangerschaftsstatus einer Patientin", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "sct-concept", - "uri": "http://snomed.info/conceptdomain", - "name": "SNOMED CT Concept Domain Binding" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "sct-attr", - "uri": "http://snomed.org/attributebinding", - "name": "SNOMED CT Attribute Binding" - } - ], "kind": "resource", "abstract": false, "type": "Observation", @@ -94,6 +62,7 @@ "path": "Observation.hasMember", "short": "Erwartetes Geburtsdatum", "definition": "Eine Referenz auf die ErwartetesGeburtsdatum Observation", + "max": "1", "type": [ { "code": "Reference", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKStillstatus.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKStillstatus.json index 3bad0a686..17c1688ea 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKStillstatus.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKStillstatus.json @@ -11,38 +11,6 @@ "publisher": "gematik GmbH", "description": "Profil zur Abbildung ob gestillt/Muttermilch abgepumpt und gefüttert wird", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "sct-concept", - "uri": "http://snomed.info/conceptdomain", - "name": "SNOMED CT Concept Domain Binding" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "sct-attr", - "uri": "http://snomed.org/attributebinding", - "name": "SNOMED CT Attribute Binding" - } - ], "kind": "resource", "abstract": false, "type": "Observation", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKValueSet.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKValueSet.json index e37d78121..7bfaf424f 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKValueSet.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKValueSet.json @@ -10,28 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil beschreibt die maschinenlesbare Auswahl von Codes für die Kodierung spezifischer FHIR-Elemente in ISiK-Szenarien", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "objimpl", - "uri": "http://hl7.org/fhir/object-implementation", - "name": "Object Implementation Information" - } - ], "kind": "resource", "abstract": false, "type": "ValueSet", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKVersicherungsverhaeltnisGesetzlich.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKVersicherungsverhaeltnisGesetzlich.json index 918dee979..0d26bf4c5 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKVersicherungsverhaeltnisGesetzlich.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKVersicherungsverhaeltnisGesetzlich.json @@ -10,38 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil ermöglicht die Darstellung eines gesetzlichen Versicherungsverhältnisses in ISiK Szenarien.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "cdanetv4", - "uri": "http://www.cda-adc.ca/en/services/cdanet/", - "name": "Canadian Dental Association eclaims standard" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "cpha3pharm", - "uri": "http://www.pharmacists.ca/", - "name": "Canadian Pharmacy Associaiton eclaims standard" - } - ], "kind": "resource", "abstract": false, "type": "Coverage", diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKVersicherungsverhaeltnisSelbstzahler.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKVersicherungsverhaeltnisSelbstzahler.json index 7bc0efcf8..20dfb00aa 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKVersicherungsverhaeltnisSelbstzahler.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKVersicherungsverhaeltnisSelbstzahler.json @@ -10,38 +10,6 @@ "publisher": "gematik GmbH", "description": "Dieses Profil ermöglicht Selbstzahler Szenarien in ISiK.", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "workflow", - "uri": "http://hl7.org/fhir/workflow", - "name": "Workflow Pattern" - }, - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - }, - { - "identity": "cdanetv4", - "uri": "http://www.cda-adc.ca/en/services/cdanet/", - "name": "Canadian Dental Association eclaims standard" - }, - { - "identity": "v2", - "uri": "http://hl7.org/v2", - "name": "HL7 v2 Mapping" - }, - { - "identity": "cpha3pharm", - "uri": "http://www.pharmacists.ca/", - "name": "Canadian Pharmacy Associaiton eclaims standard" - } - ], "kind": "resource", "abstract": false, "type": "Coverage", diff --git a/Resources/fsh-generated/resources/StructureDefinition-PlannedEndDate.json b/Resources/fsh-generated/resources/StructureDefinition-PlannedEndDate.json index 7da1aa08e..2ef7a0365 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-PlannedEndDate.json +++ b/Resources/fsh-generated/resources/StructureDefinition-PlannedEndDate.json @@ -9,13 +9,6 @@ "date": "2024-01-16", "publisher": "gematik GmbH", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - } - ], "kind": "complex-type", "abstract": false, "context": [ diff --git a/Resources/fsh-generated/resources/StructureDefinition-PlannedStartDate.json b/Resources/fsh-generated/resources/StructureDefinition-PlannedStartDate.json index a829e8bb9..fd86660fa 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-PlannedStartDate.json +++ b/Resources/fsh-generated/resources/StructureDefinition-PlannedStartDate.json @@ -9,13 +9,6 @@ "date": "2024-01-16", "publisher": "gematik GmbH", "fhirVersion": "4.0.1", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - } - ], "kind": "complex-type", "abstract": false, "context": [ diff --git a/Resources/fsh-generated/resources/StructureDefinition-patient-merge-subscription.json b/Resources/fsh-generated/resources/StructureDefinition-patient-merge-subscription.json index a77effdf8..fa772124e 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-patient-merge-subscription.json +++ b/Resources/fsh-generated/resources/StructureDefinition-patient-merge-subscription.json @@ -7,18 +7,6 @@ "status": "draft", "description": "Patient Merge Subscription", "fhirVersion": "4.3.0", - "mapping": [ - { - "identity": "rim", - "uri": "http://hl7.org/v3", - "name": "RIM Mapping" - }, - { - "identity": "w5", - "uri": "http://hl7.org/fhir/fivews", - "name": "FiveWs Pattern Mapping" - } - ], "kind": "resource", "abstract": false, "type": "Subscription", diff --git a/Resources/input/fsh/ISiKPatient.fsh b/Resources/input/fsh/ISiKPatient.fsh index 36637e5dc..f9d18068e 100644 --- a/Resources/input/fsh/ISiKPatient.fsh +++ b/Resources/input/fsh/ISiKPatient.fsh @@ -47,7 +47,7 @@ Description: "Dieses Profil beschreibt die Nutzung von administrativen Patienten * ^slicing.discriminator.type = #pattern * ^slicing.discriminator.path = "$this" * ^slicing.rules = #open - * ^comment = "In order to maintain the differntiations of name parts as given in the VSDM dataset or qualify prefixes as academic titles, vendors can opt to support the extensions specified in the German HumanName Base Profile https://simplifier.net/basisprofil-de-r4/humannamedebasis\r\nThis is however not required within the scope of this specification." + * ^comment = "In order to maintain the differentiations of name parts as given in the VSDM dataset or qualify prefixes as academic titles, vendors can opt to support the extensions specified in the German HumanName Base Profile https://simplifier.net/basisprofil-de-r4/humannamedebasis\r\nThis is however not required within the scope of this specification." * name contains Name 1..1 MS and Geburtsname 0..1 MS @@ -172,8 +172,6 @@ Usage: #example * address[=].country = "DE" - - Invariant: isik-pat-1 Description: "Falls die Geschlechtsangabe 'other' gewählt wird, muss die amtliche Differenzierung per Extension angegeben werden" Severity: #error