Initiative Intersektorale Kommunikation

Transkript

1 Initiative Intersektorale Kommunikation AUFTRAGSKOMMUNIKATION AUF BASIS VON HL7 VERSION 3 FÜR DAS DEUTSCHE GESUNDHEITSWESEN Implementierungsleitfaden Version 0.98 Stand: Dokumenten-OID: VHitG

2 Auftragskommunikation HL7 Version 3 Seite 2 IMPLEMENTIERUNGSLEITFADEN AUFTRAGSKOMMUNIKATION AUF BASIS VON HL7 VERSION 3 FÜR DAS DEUTSCHE GESUNDHEITSWESEN vorgelegt vom VHitG Geschäftsstelle: Verband der Hersteller von IT-Lösungen für das Gesundheitswesen VHitG Neustädtische Kirchstr Berlin Ansprechpartner Andreas Kassner ( andreas.kassner@vhitg.de) VHitG Geschäftsstelle Kai U. Heitmann ( hl7@kheitmann.nl) Heitmann Consulting and Services Sciphox Arbeitsgemeinschaft GbR mbh HL7-Benutzergruppe in Deutschland e.v.

3 Auftragskommunikation HL7 Version 3 Seite 3 Der Inhalt dieses Dokumentes ist öffentlich. Zu beachten ist, dass Teile dieses Dokuments auf dem Abstimmungspaket 17 vom Mai 2007 und der Normative Edition 2006 von HL7 Version 3 beruhen, für die HL7 Inc gilt. Disclaimer Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann der VHitG keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.

4 Auftragskommunikation HL7 Version 3 Seite 4 Dokumenteninformation Status Entwurf Revisionsliste Version Autor Inhalt Datum 0.10 KH Draft, Übernahme des Scope Dokuments und der ersten Storyboard 0.20 KH Änderungen und Ergänzungen Storyboards während des Treffens AG Auftrag 0.30 AK Use Cases, Auftragsdienste UM Kapitel 2 überarbeitet SK Use Cases und Storyboards überarbeitet KH Kapitel 3 bearbeitet KH Kapitel 5 Grafiken, Modellbeschreibungen KH Kapitel 5 bearbeitet SK Use Cases und Storyboards bearbeitet KH Kapitel 4 nachbearbeitet KH Kapitel 3, 5, 6 und 7 finalisiert PW Beispiele Reha KH Update auf neues Ballot 17, u.a. Abort Care Provision hinzugefügt 0.97b Team Bearbeitung auf Teambesprechung KH, SK Zwei Storyboards hinzugefügt, Nachbearbeitung

5 Auftragskommunikation HL7 Version 3 Seite 5 Editoren Kai U. Heitmann (KH), Heitmann Consulting & Services Andreas Kassner (AK), VHitG e.v. Autoren Kai U. Heitmann (KH), Heitmann Consulting & Services Andreas Kassner (AK), VHitG e.v. Ulrich Maier (UM), Siemens Medical Solutions Peter Sachs (PS), Medos Stefan Benzschawel (SB) Agfa Healthcare Peter Wegmann (PW), All for One Ralf Brandner, InterComponentWare Sang-Il Kim (SK), Siemens Medical Solutions Mit Beiträgen von René Spronk

6 Auftragskommunikation HL7 Version 3 Seite 6 Autoren und Copyright-Hinweis, Nutzungshinweise Nachnutzungs- bzw. Veröffentlichungsansprüche Das vorliegende Dokument wurde vom Verband der Hersteller von IT für das Gesundheitswesen (VHitG) entwickelt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt. Der Inhalt dieser Spezifikation ist öffentlich. Aus der Nutzung ergibt sich kein weiter gehender Anspruch gegenüber dem VHitG, zum Beispiel eine Haftung bei etwaigen Schäden, die aus dem Gebrauch der Spezifikationen bzw. der zur Verfügung gestellten Dateien entstehen.

7 Inhaltsverzeichnis Dokumenteninformation... 4 Status... 4 Revisionsliste... 4 Autoren... 5 Mit Beiträgen von... 5 Autoren und Copyright-Hinweis, Nutzungshinweise... 6 Nachnutzungs- bzw. Veröffentlichungsansprüche... 6 Inhaltsverzeichnis Einleitung Aufbau dieses Implementierungsleitfadens HL7 und Referenz-Modelle Konzept und Begründung Zweck Bezug auf bestehende Standards Abgrenzung Abhängigkeiten und Synergien mit weiteren Profilen Anforderungen Grundlagen Zertifizierung Stabilität der verwendeten Standards Bezug zum HL7 Version 3 Dokumentenstandard Konzept und Modellbeschreibung Nachrichten im Gesundheitswesen Das Care Provision Modell Dynamisches Modell Beschreibung der Use Cases und Storyboards Akteure Order Placer Order Filler Informer und Tracker Liste der Interaktionen Care Transfer Request (REPC_IN002120UV) Revise Care Transfer Request (REPC_IN002220UV) Abort Care Transfer Request (REPC_IN002620UV) Care Transfer Promise (REPC_IN003130UV) Reject Care Transfer (REPC_IN002040UV) Replace Care Transfer Promise (REPC_IN003930UV) Activate Care Provision (REPC_IN004110UV) Complete Care Provision (REPC_IN004410UV) Append Care Provision (REPC_IN004211UV) Correct Care Provision (REPC_IN004210UV) Nullify Care Provision (REPC_IN004810UV) Replace Care Provision (REPC_IN004913UV) Report Care Provision (REPC_IN004014UV) Suspend Care Provision (REPC_IN004310UV) Resume Care Provision (REPC_IN004510UV)... 36

8 Auftragskommunikation HL7 Version 3 Seite Use Cases und Storyboards Anforderung Order Placer an Order Filler Rückmeldung Order Filler an Order Placer Übersicht Use Cases und Storyboards Use Case 1 Auftrag ohne Änderung oder Storno + Leistungserbringung wie gewünscht Use Case 2 Ändern eines Auftrags durch Order Placer (bevor die Leistungserbringung gestartet hat) Use Case 3 Ändern eines Auftrags durch Order Placer (bevor die Leistungserbringung gestartet hat) Use Case 4 Ändern eines Auftrags durch Order Filler (bevor die Leistungserbringung gestartet hat) Use Case 5 Ändern einer Auftragsausführung durch Order Filler (nachdem die Leistungserbringung gestartet hat) Use Case 6 Abbruch eines Auftrags durch Order Placer (bevor die Leistungserbringung gestartet hat) Use Case 7 Abbruch eines Auftrags durch Order Filler (bevor die Leistungserbringung gestartet hat) Use Case 8 Abbruch einer Auftragsausführung durch Order Placer (nachdem die Leistungserbringung gestartet hat) Use Case 9 Abbruch einer Auftragsausführung durch Order Filler (nachdem die Leistungserbringung gestartet hat) Use Case 10 Abbruch eines Auftrags durch Order Filler (nachdem die Leistungserbringung gestartet hat) und Wiederaufnahme Use Case 11 Nachreichen von Ergebnissen (Prozedur durch Leistungserbringer abgeschlossen) Statisches Modell Refined Message Information Modell R-MIM Care Transfer Request (REPC_RM002000) R-MIM Übersicht Care Transfer Promise (REPC_RM003000) Act Status Generic (COMT_RM001000UV01) Care Provision Event (REPC_RM004000) gemeinschaftliche Definitionen und Transport Datentypen Common Message Element Types (CMETs) Patient (R_Patient) Heilberufler (Person, Organisation, R_AssignedParty) Wrapper Transmission Wrapper Trigger Event Control Act Wrapper Transport Unterstützende Dokumente Schemas Beispiel Nachrichten Templates/Profile Anhang HL Hinweise zur Vergabe und Verwendung von Object Identifiern (OIDs) Identifikationen von Objekten Identifikationen von Codesystemen...139

9 Auftragskommunikation HL7 Version 3 Seite Auftragsvermittlung durch Auftragsdienste Vermittlungsdienst Zuweiserportal Beschreibung Broker Ungerichtete Kommunikation Referenzen Allgemein und HL Internationale Spezifikationen allgemein Klassifikationen / Terminologien Konferenzen/Proceedings...146

10

11 1 Einleitung

12 Auftragskommunikation HL7 Version 3 Seite Aufbau dieses Implementierungsleitfadens Dieser Implementierungsleitfaden verfolgt drei Ziele. Neben dem grundlegenden Konzept und dessen Begründung sollen die zugrunde liegenden Modelle ausführlich beschrieben werden, die für die Kommunikation genutzt werden. Aus ihnen leiten sich die Nachrichten/Dokumente in ihrem Aufbau und ihrer Semantik ab. Gleichzeitig können die Modelle Hinweise liefern für den Aufbau von Datenbanken oder Anwendungssystemen, die in diesem Kommunikationsszenario als Sender oder Empfänger fungieren. Zum dritten soll dieser Leitfaden praktische Implementierungshilfen geben. Dies kann bis zu einem gewissen Detaillierungsgrad geschehen und ist in der Regel mit Beispielen angereichert, so dass ein Programmierer einer Schnittstelle das nötige Wissen erlangen kann, wie die Schnittstelle aufzubauen ist. Auf dieser Basis werden schließlich die tatsächlichen Informationsinhalte beschrieben und die Beziehung an die entsprechenden Klassen und Attribute im Modell aufgezeigt. Daraus folgen dann Nachrichten und zugehörige Beispiele. Zudem sind in diesem Leitfaden einige Anhänge aufgenommen, die als Referenzmaterial dienen können und Hinweise geben für eine XMLbasierte Implementierung HL7 und Referenz-Modelle Allen Modellen bei HL7 Version 3 liegt das so genannte Referenz- Informations-Modell (RIM) zugrunde. Es beschreibt generisch zum Beispiel einen Behandlungsprozess. Dabei wird von einer Aktivität (Act) ausgegangen, an der Entitäten (z. B. Personen) in bestimmten Rollen (Arzt, Patient, Angehöriger) teilnehmen (Participation). Aktivitäten können miteinander in Beziehung (Kontext) stehen (Act Relationship), beispielsweise eine Laboranforderung und das daraus folgende Resultat. In der folgenden Abbildung sind die Basisklassen des RIM wiedergegeben. Darunter sind im Gesamt-RIM natürlich noch Spezialisierungen der Klassen zu finden. So ist eine Diagnose ein Sonderfall einer Beobachtung, diese wiederum eine Aktivität. Role Relationship Act Relationship Entity Role Participation Act Abbildung 1: RIM Basisklassen

13 2 Konzept und Begründung

14 Auftragskommunikation HL7 Version 3 Seite Zweck Dieses Dokument der Initiative "Intersektorale Kommunikation" beschreibt die Aufgaben der Arbeitsgruppe Auftrag für den elektronischen und organisationsübergreifenden Datenaustausch zur Anforderung und Erbringung von Auftragsleistungen im medizinischen Umfeld. Die Lösungskonzepte sollen den Leistungserbringern zur Verbesserung Ihrer Effizienz und Wirtschaftlichkeit dienen, respektive der Verkürzung der Kommunikationswege, Ressourcenoptimierung und -auslastung unter Einbindung des Patienten. Vor dem Hintergrund neu entstehender Gesundheitsnetze und Konzepten der integrierten Versorgung kann die Online-Übermittlung der Leistungsanforderung praktisch bei allen deutschen Krankenhäusern und Fachärzten realisiert werden, im Zusammenspiel mit ihren Zuweisern aus dem ambulanten, stationären und Reha-Bereich. Die Umsetzung der hier beschriebenen elektronischen Auftragskommunikation ist derzeit nicht als Ersatz zur papierbasierten Überweisung oder dem AHB Bogen zu sehen, da hierzu die gesetzlichen Rahmenbedingungen zu beachten wären. Sie kann aber bereits jetzt als Prozessunterstützung und zusätzlichen Service für Anwender und Patienten dienen. Darüber hinaus stellt es die technische Basis für die elektronische Ein- bzw. Überweisung dar. Wichtigstes Ziel ist die Erstellung eines Implementierungsleitfadens, der die Umsetzung von Standards anhand von Use Cases beschreibt und praktische Implementierungshilfen geben für die konkrete Umsetzung in der Softwareentwicklung und Projektierung Bezug auf bestehende Standards Dieser Abschnitt gibt Hinweise auf ähnliche Standards, ohne dass daraus unmittelbar Vorgaben für die Implementierung abzuleiten sind. Für die organisationsinterne Kommunikation von Radiologie und Labor Aufträgen ist das von IHE erstellte Profil Scheduled Workflow bekannt, basierend auf HL7 Version 2. Die Akteure im Kontext intersektorale Auftragskommunikation sind angelehnt an die IHE Profile und wurden entsprechend den unten beschriebenen Anforderungen erweitert. Als Grundlage für die technische Beschreibung soll HL7 Version 3 dienen Abgrenzung Zur Optimierung der Prozesse erfolgt die Kommunikation von Auftragsdaten auf Basis eines beim Leistungsanforderer bekannten Leistungsbaums des Leistungserbringers. So muss zum Beispiel für eine automatische Buchung eines CCT Kopf in einer Radiologie der Kenner für den CCT Kopf in Form eines Katalogs bei der Anforderung bekannt sein. Der Abgleich des Leistungsbaums zwischen Leistungserbringer und anforderer ist nicht Bestandteil des Implementierungsleitfadens (siehe Masterfiles im HL7 Kon-

15 Auftragskommunikation HL7 Version 3 Seite 15 text). Ebenso wird die Registratur der Leistungserbringer nicht beschrieben. Funktionen, Konnektorenkonzepte und Netzdienste einer zukünftigen nationalen oder regional organisierten Infrastruktur werden hier nicht aufgegriffen. Die Arbeiten der Arbeitsgruppe konzentrieren sich ausschließlich auf die Entwicklung der Syntax und teilweise auf die Semantik im Rahmen der Auftragskommunikation. Auf die Wiederverwendbarkeit der VHitG- Ergebnisse unter Einsatz späterer Übermittlungsdienste wird hingearbeitet. Die Protokolle für den Transport und unterer Schichten der Kommunikation von Auftragsnachrichten werden durch externe Arbeiten, wie beispielsweise die der gematik, beschrieben und sind nicht Bestandteile des Implementierungsleitfadens. Es ist kein Fokus des Implementierungsleitfadens die Übermittlung von Laboranforderungen zu beschreiben. Hierzu existieren im niedergelassenen Bereich das LDT-Format der KBV und im stationären Bereich die HL7 Konzepte der deutschen HL7 Benutzergruppe auf Basis HL7 Version 2. Es wird auf eine Anwendbarkeit für eine spätere Laborauftragskommunikation hingearbeitet. In dem Fall in dem der Patient nicht bei dem geplanten Leistungserbringer erscheint, sondern sich für einen anderen Leistungserbringer entscheidet (freie Arztwahl), wird im Rahmen der elektronischen Überweisung/Verordnung der tatsächliche Leistungserbringer ggf. die Möglichkeit haben müssen, die Überweisung/Verordnung online abrufen zu können, bevor er seine Leistung erbringt. Dieser Use Case der nichtgerichteten Kommunikation wird mit dem Leitfaden nicht abgedeckt. Konzeptuell werden die Szenarien Mitbehandlung (Beispiel Radiologie) und Weiterbehandlung (Beispiel: Bettendisposition Reha) betrachtet. Hierbei können in Zukunft neue Lösungsansätze wie Broker-/Portallösungen einbezogen werden. In dem vorliegenden Leitfaden wird die Kommunikation über Brokersysteme nicht betrachtet. Leistungsdatenübermittlung ist nicht Gegenstand dieses Leitfadens. Änderungen zum Termin werden zwar behandelt, sollten aber vor dem Hintergrund der organisatorischen Prozesse versus Nutzwert von IT (Telefon ist im Zweifel effizienter) geregelt werden, z. B. um einen Termin zu verlegen. Die Applikationslogik zur Vergabe und Buchung der Termine obliegt dem IT System und natürlich dem Anwender, hierzu erfolgen keine Vorgaben. Die patientenübergreifende Anforderung im Sinne der Resourcenplanung ist Gegenstand der HL7 Domäne Scheduling und wird nicht in diesem Leitfaden behandelt.

16 Auftragskommunikation HL7 Version 3 Seite Abhängigkeiten und Synergien mit weiteren Profilen Die folgenden Funktionen werden hier lediglich genutzt, jedoch nicht in diesem Dokument spezifiziert: Funktionalitäten gemäß der AG PID zur Übermittlung und Sicherstellung der Identität von Patienten in verschiedenen Domänen Eine Telematikinfrastruktur, die folgenden Punkte umfasst o Definition des physikalischen Transports o Standards für Ver- / Entschlüsselungsverfahren o PKI Infrastruktur für die (sichere) Verfügbarmachung der öffentlichen Schlüssel aller Teilnehmer am Verfahren Neben der Übermittlung des Auftrags zur Leistungserbringung soll das Ergebnis der Leistung, der Arztbrief, einbezogen werden, indem ein eindeutiger Bezug zwischen Auftrag und Arztbrief geschaffen wird (vgl. Implementierungsleitfaden VHitG Arztbrief) Anforderungen Jede Leistungsanforderung bezieht sich genau auf einen Patienten. Die Auftragskommunikation besteht im Detail aus unterschiedlichen Elementen: Patientendaten, Auftragsinformationen auf Katalogbasis, Zusatzinformationen zum Auftrag, Terminanfrage. Der Auftrag beinhaltet Teile der papiernen Überweisung. Jeder Auftrag kann mehrere Auftragspositionen gruppieren. Somit muss jede Auftragsposition eine eigene Identifikation besitzen. Die folgende Darstellung visualisiert die unterschiedlichen Auftragsebenen, die im Implementierungsleitfaden beschrieben werden. Gestrichelt markiert sind die weiteren notwendigen Schritte beim Auftragsmanagement, die außerhalb des Leitfadens definiert werden (Leistungsdaten, Befunddaten).

17 Auftragskommunikation HL7 Version 3 Seite 17 Abbildung 1: Darstellung der Beziehung von Auftrag zu Auftragspositionen (nach IHE) In einem realen Beispiel wird so ein Auftrag vergeben mit der medizinischen Fragestellung XY. Hieraus ergeben sich beim Order Placer zwei Auftragspositionen, 1. CT Thorax. Mit dem Auftragscode 1500 und der vom Order Placer vergebenen ID 1001 und 2. Röntgen Thorax. Der Patient trifft beim Order Filler ein, wo beide Untersuchungen tatsächlich erbracht werden (erbrachte Leistungen). Im Rahmen der Untersuchungsreihe wird durch den Arzt die Durchführung einer zusätzlichen Untersuchung entschieden. Diese Erweiterung des Auftrages um eine zusätzliche Leistung wird erst im Rahmen der Ergebnisrückmeldung an den Order Placer zurück kommuniziert. Die Ergebnisrückmeldung enthält ausschließlich die Information, ob die Untersuchung(en) erbracht oder ggf. abgebrochen wurde. Die Quittierung der Anforderung und die Rückübermittlung mit Befund werden in diesem Leitfaden beschrieben, nicht jedoch die Leistungsdatenübermittlung. Aufträge enthalten Zusatzinformationen, die vorab zwischen den Systemen abzustimmen sind und in Abhängigkeit von dem jeweiligen Auftragscode differieren. Beispiel: CT mit Kontrastmittel, Abfrage der Kontrastmittelallergie bei Antragsstellung; Herzschrittmacher, Metallimplantate; Reha Einzelzimmer, behindertengerecht, Klassifizierungsmerkmal. Im Kontext der Auftragskommunikation ist die freie Wahl des Leistungserbringers durch den Patienten zu beachten. Das bedeutet, dass der Patient abweichend von der ursprünglichen Buchung die Leistung nicht bei dem geplanten Leistungserbringer wahrnehmen muss. Es gibt keine Verpflichtung, die aus der Buchung hervorgeht. Da die ungerichtete Kommunikation kein Bestandteil des Konzeptes ist, soll in Vorbereitung auf späte-

18 Auftragskommunikation HL7 Version 3 Seite 18 re Use Cases als Empfänger dennoch sowohl ein bestimmter Heilberufler als auch z.b. nur die Angabe eine Fachgruppe möglich sein. Der Schwerpunkt liegt stärker auf dem Order-Aspekt, als auf dem Scheduling oder Referral. Die Kommunikation zum genauen Termin der Leistungserbringung wird somit als einfacher Terminwunsch übermittelt. Mit jeder Auftragsposition kann ein Wunschtermin übermittelt werden. Dieser kann für jede Auftragsposition individuell sein oder für alle Auftragspositionen die gleiche Terminanforderung enthalten. Gleichzeitig soll die Wiederholung von Terminen (Dialyse, Massagen) mit gleichem Terminmuster abbildbar sein. Die Angabe des Terminwunsches kann beispielsweise lauten: montags 15:00, immer nachmittags an Werkstagen oder innerhalb der nächsten 4 Tage. Diese sind als getrennte Aufträge zu kommunizieren, jedoch durch eine gemeinsame Identifikation gruppierbar. Ein weitgehend definierter Leistungskatalog beschreibt standardisierte Leistungen und deren Codes. (ICPM, und weitere ). Nicht codierte Leistungen werden als freier Text formuliert (ohne Code). Zu jeder Leistungsanforderung sind Meldungen zum Verarbeitungsstatus zu kommunizieren. Multimedia-Links, z. B. Referenzen auf Bilder, Töne oder Biosignale, oder auch weitere Dokumente können unterstützt werden Grundlagen Für XML als grundsätzliches Format spricht die Flexibilität nicht nur bei der Länge einzelner darzustellender Texte sondern auch bezüglich der a priori nicht begrenzten Schachtelungstiefe von Elementen. HL7 als Kommunikationsprotokoll ist vornehmlich in Krankenhäusern verbreitet und wird zum Datenaustausch zwischen Abteilungssystemen eingesetzt. Der ursprünglich aus Amerika stammende Ansatz ist im Laufe der Zeit zu einem international einsetzbaren Standard geworden, auch dank vieler internationaler Benutzergruppen, die seit langem an der Weiterentwicklung von HL7 mitwirken. Mittlerweile wird HL7 in vielen Ländern konkret eingesetzt, ist in manchen Ländern sogar offizielle Norm. Dennoch wurde HL7 in Deutschland im niedergelassenen Bereich oder in der ambulant-stationären Kommunikation bisher nicht umgesetzt. Zwischenzeitlich ist von der HL7-Organisation der Standard HL7 v3 international entwickelt und anerkannt worden (bzw. abhängig von den Anwendungsdomänen noch in Verabschiedung und Anerkennung). HL7 v3 bietet: eine konzeptuelle Grundlage in einem gemeinsamen, umfassenden Reference Information Model (RIM) für alle Teile von HL7 v3; dieses RIM ist ANSI- und ISO-Standard ein festes semantisches Fundament in explizit definierten Konzept- Domänen

19 Auftragskommunikation HL7 Version 3 Seite 19 ausgewählte standardisierte Terminologien, die in den Domänen semantische Interoperabilität garantieren die Trennung von Inhalten und Syntax (wenngleich die Verwendung bestimmter Elementnamen vor allem im Header eine gewisse Semantik suggerieren) eine technologie-unabhängige Entwurfsmethodik. In HL7 ist es vorgesehen Order- und Schedulingnachrichten getrennt zu kommunizieren Zertifizierung Die Verwendung des Implementierungsleitfadens in Softwareprodukten ist grundsätzlich frei von jeglicher Zertifizierung Stabilität der verwendeten Standards Standards in der Medizin, so auch Kommunikationsstandards, entwickeln sich kontinuierlich weiter, um den ständig ändernden Anforderungen gerecht zu werden. Allerdings ist eine kontinuierliche Weiterentwicklung in Bezug auf reale Implementierungen nicht handhabbar. Deshalb wählt man zu einem gegebenen Zeitpunkt, im Sinne einer Momentaufnahme, die zu verwendenden Standards aus und friert diesen für eine Zeit lang ein. Das heißt für diesen Leitfaden, dass in Bezug auf die verwendeten Standards stabile Verhältnisse für etwa zwei Jahre zu erwarten sind. Mit dem hier verwendeten Abstimmungspaket von HL7 vom Mai 2007 ist die verwendete Domäne Care Provision ein Draft Standard for Trial Use (DSTU), bei dem diese Stabilität von Standardisierungsseite her gewährleistet ist. HL7 konstatiert zudem die Möglichkeit, dass Versionen, die zum Beispiel auf unterschiedlichen Implementation Technology Specifications (ITS) beruhen, durch einfache Transformationen (z. B. mittels XSLT) ineinander überführbar sind. Die verwendeten Datentypen sind mit den Festlegungen in XML Implementation Technology Specification - Data Types Release 1 schon länger ANSI Standard (seit der Jahreswende 2004/05). Diese sind auch im Leitfaden "HL7 Version 3 Datentypen und CMETs Leitfaden für das Deutsche Gesundheitswesen" [dtcmetv3-hl7de] veröffentlicht Bezug zum HL7 Version 3 Dokumentenstandard Während HL7 Nachrichten wie die hier aus der Domäne Care Provision verwendeten zur direkten Prozesssteuerung verwendet werden, stellen Dokumente nach dem Standard Clinical Document Architecture (CDA) Release 2 eine persistente Dokumentation am Ende einer solchen Prozesskette dar.

20 Auftragskommunikation HL7 Version 3 Seite 20 So stellen also die Autragserteilung, Bestätigung und alle assoziierten und im dynamischen Modell ausgearbeiteten Interaktionen Nachrichten zur Prozesssteuerung dar. Mit ihnen wird der Prozess an sich unterstützt und Abläufe beeinflusst. Ein Befund wird dagegen typischerweise in einer Care Provision Complete Nachricht (Abschluss der Prozesskette) in der Form eines CDA Dokuments eingebettet.

21 3 Konzept und Modellbeschreibung

22 Auftragskommunikation HL7 Version 3 Seite Nachrichten im Gesundheitswesen Die Familie der Version 3 Standards von HL7 ist in Deutschland nicht unbekannt. Bereits im Jahre 2000 wurde von der Arbeitsgemeinschaft Sciphox ( die Clinical Document Architecture (CDA) in Deutschland adaptiert und eingeführt. Das Sciphox-Projekt ist als Initiative zur Kooperation zwischen ambulantem und stationärem Sektor gestartet, im ambulanten Sektor unter anderem unter Beteiligung der Kassenärztlichen Bundesvereinigung, und hat seitdem kontinuierlich daran weitergearbeitet. Mittlerweile fußen eine ganze Reihe von Spezifikationen für medizinische Anwendungsszenarien wie Entlassbrief, Überweisung etc. auf CDA/Sciphox. Auch CDA ist ein Version 3 Abkömmling, hier stehen jedoch das Dokument und seine Eigenschaften wie Kontextbewahrung und Persistenz im Vordergrund. So werden damit eher Formulare und z. B. normalerweise signierte Entlassbriefe abgebildet. Im Falle des hier fokussierten standardisierten Datenaustauschs für die Auftragskommunikation mittels HL7 Version 3 geht es mehr um den Ansatz der klassischen Nachrichtenübermittlung. Aus den Beständen des Senders wird eine Nachricht erzeugt und an den Empfänger versendet, der diese dann zu eigenen Zwecken in seiner strukturierten Datensammlung (Repository) speichert und dann wieder verwenden kann, zum Beispiel für Datenanalysen und Zusammenfassungen. Die Nachricht selbst kann danach verworfen werden. Zudem ist CDA deutlich mehr auf den Arzt und seine textlichen Beschreibungen von Sachverhalten wie Entlassoder Arztbriefe usw. gerichtet. Für die Übermittlung von Einzelwerten wie im hier vorliegenden Falle sind Nachrichten das Mittel der Wahl Das Care Provision Modell Im Folgenden wird eine Übersicht über das Care Provision Modell gegeben. Dies dient als Orientierung für spätere Detailbeschreibungen von Teilen des Modells. Im zur Basis gelegten Domänen-Modell steht zentral die generische Behandlung (Care Provision, siehe 2 Markierung 1). Damit ist eine geplante, zugesagte, stattfindende oder stattgefundene Behandlungsepisode als Teil des gesamten spezifischen Krankheitsfalles gemeint, sozusagen eine Episode in der Karriere des Patienten. Diese ist assoziiert mit dem Patienten und ggf. anderen Teilnehmern am Behandlungsprozess. Des Weiteren sind Diagnosen und Begründungen, ggf. Ausführende sowie Autoren der Dokumentation mit der Care Provision assoziiert. (siehe Markierung 3). In den jeweiligen hier beschriebenen Geschäftsvorfällen werden unterschiedliche Teile des Care Provision Modells bedeutsam. So wird für eine Anfrage bzw. Auftrag zu einer (Mit-)Behandlung ein so genannter Care Plan (siehe Markierung 4) mitgegeben, der die gewünschten auszuführenden Unteraufträge wiedergibt.

23 Auftragskommunikation HL7 Version 3 Seite 23 Die Begründung (reason) für eine Überweisung bzw. einen Auftrag wird in der Concern (Problem, Krankheit, etc.) wiedergegeben (siehe Markierung 6). Andererseits werden mit der Care Provision Aktivität einige Informationen mitgegeben, die in Zusammenhang eines Auftrags von Bedeutung sind, wie z. B. Voruntersuchungen. Die Informationen sind repräsentiert in den so genannten Clinical Statements (siehe Markierung 7). Die gleichen Strukturen werden zur Übermittlung von Untersuchungsergebnissen verwendet. Die medizinische Information in den Clinical Statements kann Unterteilungen beinhalten, die über entsprechende rekursive Modellkonstrukte wiedergegeben werden. Die eigentlichen Parameter werden wieder als Clinical Statements angegeben. Listen von Beobachtungen, Behandlungen, Medikationen etc. werden jeweils in einer Working Lists (5) zusammengefasst, Details werden auch hier über die Clinical Statements wiedergegeben. Abbildung 2: Übersicht über das Care Provision Modell, Erläuterungen siehe Text

24

25

26 4 Dynamisches Modell

27 Auftragskommunikation HL7 Version 3 Seite Beschreibung der Use Cases und Storyboards Die Auftragskommunikation kann in der realen Implementierung auf unterschiedliche Art und Weise kommuniziert werden. Die hierbei eingesetzten Softwarekomponenten agieren, je nach Leistungsumfang der kommunizierenden Partnersysteme, in unterschiedlichen Rollen, so genannten Akteuren. Für die Überleitung dieser Praxis in eine detailliertere Beschreibung werden sogenannte Use Cases und Storyboards, die eine Situation aus der Anwendersicht beschreiben, in eine mehr technische Darstellung, dem Interaktionsmodell, überführt. Es werden die häufigsten Use Cases beschrieben: Auftragskommunikation mit Änderung, Auftragskommunikation ohne Änderung, Storno eines Auftrages, Abbruch einer Anforderung oder der Auftragsausführung Akteure Order Placer Der Sender ist der Leistungsanforderer. Als Leistungsanforderer wird eine medizinische oder nichtmedizinische Einrichtung (Arzt, Klinik, Versicherungsgesellschaft, Patient,...) bezeichnet, welcher für einen Patienten eine bestimmte Leistung anfordern möchte. Der Order Placer hat nicht die Hoheit über die endgültige Terminvergabe. Grundsätzlich entscheidet das System oder der Anwender beim Order Filler über die Vergabe von Terminen. Es gibt jedoch Szenarios in denen der Order Filler dem Order Placer gewisse Zeitslots zur Verfügung stellt, aber die endgültige Terminvergabe oder Bestätigung bleibt nach wie vor beim Order Filler. Der vorliegende Leitfaden beinhaltet nicht die Resourcen- Planung beim Leistungserbringer. Im Kontext eines Care Transfer Requests spricht man statt von einem Order Placer von einem Care Transfer Placer Order Filler Der Order Filler ist der Erbringer der Leistung. Leistungserbringer ist die medizinische oder nichtmedizinische Einrichtung, welche in expliziter Zustimmung durch den Patienten zur Erbringung der Leistung ausgewählt wurde. Belange der freien Arztwahl werden organisatorisch gelöst, z.b. durch Verträge der Integrierten Versorgung, oder durch Definition des Buchungs-Workflows in einem speziellen Use Case. Grundsätzlich kann beim Order Filler die Antwortgeschwindigkeit zur Bestätigung oder Ablehnung eines Termins von den Möglichkeiten der Organisation und des IT Systems des Empfängers unterschiedlich sein. Bei hän-

28 Auftragskommunikation HL7 Version 3 Seite 28 discher Abarbeitung, wie z.b. über Arbeitslisten, ist von einem verzögerten Antwortverhalten auszugehen. Für die Organisation beim Order Placer hat das Antwortverhalten natürlich hohe Relevanz für die weitere hausinterne Bearbeitung des Falles. Aus diesem Grund ist zwischen Empfangs- Verarbeitungs- und Auftrags-/ Terminbestätigung zu unterscheiden. Im Kontext eines Care Transfer Requests spricht man statt von einem Order Filler (oder auch Fulfiller) von einem Care Transfer Filler Informer und Tracker Die Akteure während und nach der Behandlung nennt man Care Event Informer und Care Event Tracker. Häufig sind allerdings Placer und Tracker einerseits und Filler und Informer andererseits in einer Applikation vereint Liste der Interaktionen Die folgende tabellarische Zusammenstellung und Grafik gibt eine Übersicht über die hier verwendeten Interaktionen und die dazugehörigen domänenspezifischen Modelle (R-MIMs). Auftragsphase (request) Care Transfer Request Revise Care Transfer Request Abort Care Transfer Request Auftragszusage/-ablehnung Care Transfer Promise Reject Care Transfer Request Replace Care Transfer Promise Während der Behandlung Activate Care Provision Nach der Behandlung (Auftragsabwicklung) Complete Care Provision Append Care Provision Correct Care Provision Nullify Care Provision Replace Care Provision Report Care Provision Suspend Care Provision Resume Care Provision Abort Care Provision REPC_IN002120UV REPC_IN002220UV REPC_IN002620UV REPC_IN003130UV REPC_IN002040UV REPC_IN003930UV REPC_IN004110UV REPC_IN004410UV REPC_IN004211UV REPC_IN004210UV REPC_IN004810UV REPC_IN004913UV REPC_IN004014UV REPC_IN004310UV REPC_IN004510UV REPC_IN004610UV

29 Auftragskommunikation HL7 Version 3 Seite 29

30 Auftragskommunikation HL7 Version 3 Seite Care Transfer Request (REPC_IN002120UV) Strukturierte Bezeichnung: Care Transfer Request Activate Fulfillment Request Diese Interaktion wird benutzt, um eine Anfrage an den Empfänger zu richten, eine Care Provision zu übernehmen. Diese Interaktion löst ein von zwei möglichen Antworttypen aus. Mit Care Transfer Promise sagt der Empfänger die Übernahme zu, mit Reject Care Transfer wird eine Ablehnung signalisiert. Trigger Event Care Transfer Request REPC_TE002100UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Transfer Request REPC_MT002000UV Receiver Responsibilities Grund Trigger Event Interaction Der Leistungserbringer REPC_TE002040UV REPC_IN002040UV lehnt die An- forderung ab Der Leistungserbringer sagt die Übernahme der Leistung zu REPC_TE003130UV REPC_IN003130UV Sending and Receiving Roles Sender Care Transfer Placer REPC_AR002030UV Receiver Care Transfer Fulfiller REPC_AR002040UV Revise Care Transfer Request (REPC_IN002220UV) Strukturierte Bezeichnung: Care Transfer Request Revise Fulfillment Request Diese Interaktion wird benutzt, um eine Anfrage an den Empfänger zu richten, eine Änderung eines Care Provision Request zu akzeptieren. Diese Interaktion zieht zwei mögliche Antworttypen nach sich. Mit Care Transfer Promise akzeptiert der Empfänger die Korrektur, mit Reject Care Transfer wird eine Ablehnung der Änderung signalisiert. Trigger Event Notify Revise Care REPC_TE002200UV Transfer Request Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Transfer Request REPC_MT002000UV

31 Auftragskommunikation HL7 Version 3 Seite Receiver Responsibilities Reason Trigger Event Interaction Der Leistungserbringer REPC_TE002040UV REPC_IN002040UV lehnt die Korrektur Anforderung ab Der Leistungserbringer REPC_TE003130UV REPC_IN003130UV akzeptiert die Korrektur der Leistungsanforderung, wobei er die vorhergehende Anforderung noch nicht akzeptiert hatte Der Leistungserbringer akzeptiert die Korrektur der Leistungsanforderung REPC_TE003933UV REPC_IN003930UV Sending and Receiving Roles Sender Care Transfer Placer REPC_AR002030UV Receiver Care Transfer Fulfiller REPC_AR002040UV Abort Care Transfer Request (REPC_IN002620UV) Strukturierte Bezeichnung: Care Transfer Request Abort Fulfillment Notification Diese Interaktion signalisiert den Abbruch (Zurückziehen) einer vorher durch den Leistungserbringer akzeptierten Leistungsanforderung. Trigger Event Notify Abort Care REPC_TE002600UV Transfer Request Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Abort Care Transfer Request REPC_MT002600UV Sending and Receiving Roles Sender Care Transfer Placer REPC_AR002030UV Receiver Care Transfer Fulfiller REPC_AR002040UV

32 Auftragskommunikation HL7 Version 3 Seite Care Transfer Promise (REPC_IN003130UV) Strukturierte Bezeichnung: Care Transfer Promise Activate Confirmation Diese Interaktion ist eine Antwort auf ein Care Transfer Request und wird vom Empfänger benutzt, um anzugeben, dass er die Anforderung erfüllen wird. Trigger Event Care Transfer Promise REPC_TE003130UV Transmission Wrapper Application Level MCCI_MT000300UV01 Acknowledgement Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Transfer Promise REPC_MT003000UV Sending and Receiving Roles Sender Care Transfer Fulfiller REPC_AR002040UV Receiver Care Transfer Placer REPC_AR002030UV Reject Care Transfer (REPC_IN002040UV) Strukturierte Bezeichnung: Care Transfer Request Rejection Diese Interaktion ist eine Antwort auf ein Care Transfer Request und wird vom Empfänger benutzt, um anzugeben, dass er die Anforderung nicht akzeptiert (ablehnt). Trigger Event Reject Care Transfer REPC_TE002040UV Transmission Wrapper Application Level MCCI_MT000300UV01 Acknowledgement Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Act generic Status - Order COMT_MT001101UV Sending and Receiving Roles Sender Care Transfer Fulfiller REPC_AR002040UV Receiver Care Transfer Placer REPC_AR002030UV

33 Auftragskommunikation HL7 Version 3 Seite Replace Care Transfer Promise (REPC_IN003930UV) Strukturierte Bezeichnung: Care Transfer Promise Obsolete Confirmation Replace Diese Interaktion wird benutzt, um eine vorher akzeptierte Leistungsanforderung durch eine andere zu ersetzen. Trigger Event Replace Care Transfer REPC_TE003933UV Promise Transmission Wrapper Accept Acknowledgement MCCI_MT000200UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Transfer Promise REPC_MT003000UV Sending and Receiving Roles Sender Care Transfer Fulfiller REPC_AR002040UV Receiver Care Transfer Placer REPC_AR002030UV Activate Care Provision (REPC_IN004110UV) Strukturierte Bezeichnung: Care Record Event Activate Diese Interaktion informiert den Empfänger über den Beginn einer Care Provision. Trigger Event Activate Care Provision REPC_TE004110UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Record REPC_MT004000UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004010UV Receiver Care Transfer Tracker REPC_AR004020UV Complete Care Provision (REPC_IN004410UV) Strukturierte Bezeichnung: Care Record Event Complete Diese Interaktion informiert den Empfänger über eine abgeschlossene Care Provision.

34 Auftragskommunikation HL7 Version 3 Seite 34 Trigger Event Complete Care Provision REPC_TE004410UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Record REPC_MT004000UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004010UV Receiver Care Transfer Tracker REPC_AR004020UV Append Care Provision (REPC_IN004211UV) Strukturierte Bezeichnung: Care Record Event Revise Appended Diese Interaktion informiert den Empfänger über zusätzliche Details einer Care Provision. Trigger Event Append Care Provision REPC_TE004211UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Record REPC_MT004000UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004010UV Receiver Care Transfer Tracker REPC_AR004020UV Correct Care Provision (REPC_IN004210UV) Strukturierte Bezeichnung: Care Record Event Revise Corrected Diese Interaktion informiert den Empfänger über eine Korrekturen zu Details einer Care Provision. Trigger Event Correct Care Provision REPC_TE004210UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Record REPC_MT004000UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004010UV Receiver Care Transfer Tracker REPC_AR004020UV

35 Auftragskommunikation HL7 Version 3 Seite Nullify Care Provision (REPC_IN004810UV) Strukturierte Bezeichnung: Care Record Event Nullify Diese Interaktion informiert den Empfänger darüber, dass Details zu einer vorherigen Care Provision nicht korrekt bzw. inadäquat waren und gelöscht wurden. Trigger Event Nullify Care Provision REPC_TE004810UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Record Status REPC_MT004009UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004010UV Receiver Care Transfer Tracker REPC_AR004020UV Replace Care Provision (REPC_IN004913UV) Strukturierte Bezeichnung: Care Record Event Obsolete Replace Diese Interaktion informiert den Empfänger darüber, dass Details zu einer vorherigen Care Provision korrigiert und ersetzt wurden. Trigger Event Replace Care Provision REPC_TE004913UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Record REPC_MT004000UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004010UV Receiver Care Transfer Tracker REPC_AR004020UV Report Care Provision (REPC_IN004014UV) Strukturierte Bezeichnung: Care Record Event Notification Report Diese Interaktion wird benutzt, um dem Empfänger eine Zusammenfassung zu einer Care Provision zum momentanen Zeitpunkt zu übermitteln.

36 Auftragskommunikation HL7 Version 3 Seite 36 Trigger Event Report Care Provision REPC_TE004014UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Master File / Reg. Notif MFMI_MT700702UV01 Control Act, Act Subject Message Type Care Record REPC_MT004000UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004014UV Receiver Care Transfer Tracker REPC_AR004024UV Suspend Care Provision (REPC_IN004310UV) Strukturierte Bezeichnung: Care Record Event Suspend Diese Interaktion informiert den Empfänger darüber, dass eine Care Provision vorübergehend ausgesetzt wurde. Trigger Event Suspend Care Provision REPC_TE004310UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Record Status REPC_MT004009UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004010UV Receiver Care Transfer Tracker REPC_AR004020UV Resume Care Provision (REPC_IN004510UV) Strukturierte Bezeichnung: Care Record Event Resume Diese Interaktion informiert den Empfänger darüber, dass eine vorübergehend ausgesetzte Care Provision wieder aufgenommen wurde. Trigger Event Resume Care Provision REPC_TE004510UV Transmission Wrapper Send Message Payload MCCI_MT000100UV01 Control Act Wrapper Trigger Event Control MCAI_MT700201UV01 Act Message Type Care Record Status REPC_MT004009UV Sending and Receiving Roles Sender Care Transfer Informer REPC_AR004010UV

37 Auftragskommunikation HL7 Version 3 Seite 37 Receiver Care Transfer Tracker REPC_AR004020UV 4.4. Use Cases und Storyboards Der häufigste Fall einer Auftragskommunikation ist die direkte Kommunikation zwischen Auftraggeber und Auftragnehmer. Hierbei wählt der Leistungsanforderer aus einem definierten Katalog von Leistungen eines Leistungserbringers eine oder mehrere Leistungen aus. Die angeforderten Einzelleistungen werden als Auftragspositionen eines Auftrags übermittelt. Der Leistungserbringer bestätigt sowohl den Empfang als auch die Auftragsbearbeitung des Gesamtauftrages. Bei mehreren Auftragspositionen wird die Verbuchung/Bearbeitung jeder Auftragsposition bestätigt (z.b. Terminübermittlung). In HL7 ist es vorgesehen Order- und Schedulingnachrichten getrennt zu kommunizieren. Konkret werden die Fälle für einen Auftrag an die Radiologie (bzw. radiologische Institution) und Reha beschrieben. Optional kann in einem Auftrag ausser einem Terminwunsch auch die gewünschte Resource (Gerätetyp / Modalität, Personal oder Örtlichkeit) mitgeteilt werden Anforderung Order Placer an Order Filler In der Anforderung wird unterschieden zwischen dem Auftrag ohne Terminwunsch mit Terminwunsch Technisch unterscheiden sich die beiden Fälle nicht. Es kommt jedoch vor, dass eine Anforderung ohne Terminwunsch gesendet wird, wenn der Patient bspw. keine Präferenz hat. Auftragsspezifische Angaben, wie Herzschrittmacher bei MR Untersuchung oder Punktwert bei AHB Fall, müssen generisch unterstützt werden. Patientenbezogene Informationen wie Risikofaktoren oder Kontraindikationen sollen ebenfalls unterstützt werden. Kontextbezogene Informationen können verpflichtend oder optional sein, z.b. ist keine Jod-Allergie Vorbedingung für eine Röntgen-Kontrastmittel-Untersuchung, ein Herzschrittmacher ein Ausschlusskriterium für eine MR-Untersuchung und der Hinweis auf eine bekannte Neigung zu Platzangst eine Zusatzinformation für eine MR-Untersuchung.

38 Auftragskommunikation HL7 Version 3 Seite Rückmeldung Order Filler an Order Placer Der Leistungserbringer reagiert auf die Anforderung mit einer Rückmeldung an den Auftraggeber (automatisch oder manuell). Eventuell enthält die Bestätigung des Auftrageingangs eine Terminangabe. Es ist erforderlich dass immer eine Rückmeldung erfolgt, da es sich hier um eine Übergabe von (Teil-)Verantwortlichkeit handelt. Die Rückmeldung kann die Bestätigung oder Ablehnung sein (wenn Patient z.b. anderweitig verplant). Zusatzinformation wie Mit Bitte um Kontaktaufnahme (zwecks Patientenaufklärung o.ä.) muss in beiden Szenarien unterstützt werden. Die Verantwortung zur Patientenaufklärung verändert sich aufgrund der technischen Lösung nicht. Sie obliegt weiterhin dem Order Filler. Die Unterstützung von mehreren Auftragspositionen muss unterstützt werden. Folgetermine wie bei der Strahlentherapie (Terminserie) werden als getrennte Nachrichten kommuniziert, müssen jedoch als zusammenhängend identifizierbar sein.der Anwendungsfall Anforderung einer Gruppentherapie z.b. bei psychologischen Prozeduren wird über einzelne patientenbezogene Anforderungen abgebildet. Die Zusammenführung der einzelnen Anforderungen ist Aufgabe des Leistungserbringers Übersicht Use Cases und Storyboards Use Case 1 Auftrag ohne Änderung oder Storno + Leistungserbringung wie gewünscht Storyboard 1-1: Radiologischer Auftrag und anschließende Leistungserbringung REPC_SN440001DE Storyboard 1-2: Antrag auf Anschluss-Heilbehandlung (AHB) REPC_SN440002DE Use Case 2 Ändern eines Auftrags durch Order Placer (bevor die Leistungserbringung begonnen hat) Storyboard 2-1: Terminänderung radiologischer Auftrag (nicht substantielle Änderung) REPC_SN440003DE Storyboard 2-2: Anschluss-Heilbehandlung: zusätzliche Daten werden dem ursprünglichen Auftrag hinzugefügt, z.b. Nachsenden von Dokumenten (nicht subtantielle Änderung) REPC_SN440004DE Use Case 3 Storno und Neuauftrag (ändern) eines Auftrags durch Order Placer (bevor die Leistungserbringung begonnen hat) Storyboard 3-1: substantielle Änderung: andere radiologische Untersuchung gewünscht (Fehler bei Eingabe oder geänderte Umstände) REPC_SN440005DE

39 Auftragskommunikation HL7 Version 3 Seite 39 Use Case 4 Ändern eines Auftrags durch Order Filler (bevor die Leistungserbringung begonnen hat) Storyboard 4-1: Terminänderung durch Order Filler REPC_SN440006DE Use Case 5 Ändern einer Auftragsausführung durch Order Filler (nachdem die Leistungserbringung begonnen hat) Storyboard 4-1: Ändern der Modalität von MR zu CT wegen Metallclips REPC_SN440007DE Use Case 6 Abbruch eines Auftrags durch Order Placer (bevor die Leistungserbringung begonnen hat) Storyboard 6-1: Storno radiologischer Auftrag weil deutliche Symptomverbesserung beim Patienten REPC_SN440008DE Storyboard 6-2: Storno eines Anschluss-Heilbehandlungs-Auftrags REPC_SN440009DE Use Case 7 Abbruch eines Auftrags durch Order Filler (bevor die Leistungserbringung begonnen hat) Storyboard 7-1: Modalität nicht verfügbar REPC_SN440010DE Use Case 8 Abbruch einer Auftragsausführung durch Order Placer (nachdem die Leistungserbringung begonnen hat) Storyboard 8-1: Storno durch Order Placer nach Beginn der Auftragsausführung REPC_SN440011DE Use Case 9 Abbruch einer Auftragsausführung durch Order Filler (nachdem die Leistungserbringung begonnen hat) Storyboard 9-1: Abbruch der Auftragsausführung wegen Schwangerschaft (noch keine Ergebnisse vorhanden) REPC_SN440012DE Storyboard 9-2: Kontrastmittel-Zwischenfall: Teile des Auftrags erfolgreich erledigt, aber Auftrag kann nicht vollständig beendet werden REPC_SN440013DE Use Case 10 Abbruch eines Auftrags durch Order Filler (nachdem die Leistungserbringung gestartet hat) und Wiederaufnahme Storyboard 10-1: Untersuchung wird wegen Unwohlsein des Patienten unterbrochen und am nächsten Tag weitergeführt REPC_SN440014DE Storyboard 10-2: Patient erscheint nicht zum Untersuchungstermin REPC_SN440015DE Use Case 11 Nachreichen von Ergebnissen (Prozedur durch Leistungserbringer abgeschlossen) Storyboard 11-1: Befund war nach Untersuchung/Therapie nur zum Teil oder noch nicht vorhanden REPC_SN440016DE

40 Auftragskommunikation HL7 Version 3 Seite Use Case 1 Auftrag ohne Änderung oder Storno + Leistungserbringung wie gewünscht Storyboard 1-1: Radiologischer Auftrag und anschliessende Leistungserbringung REPC_SN440001DE Frau Anna Huber, 39 Jahre, besucht ihren Hausarzt Dr. Greber. Sie klagt über Schmerzen im unteren Lumbalbereich, die seit mehreren Jahren immer wieder auftreten. Jetzt hat sie seit ein paar Tagen eine zusätzliche akute Schmerzausstrahlung in das linke Bein. Sie hat Sensibilitätsstörungen im Dermatom L5 li und eine leichte Fußheberparese li. Ausserdem stellt Dr. Greber deutliche Lasegue-Zeichen fest. Dr. Greber vermutet einen akuten lumbalen Bandscheibenvorfall mit Nervenwurzelkompression L5/S1 links. Zur schnellen Abklärung veranlasst er ein MR der LWS (Lendenwirbelsäule). Im Auftragsmodul seiner Praxissoftware wählt er die angeforderte Leistung MR untere LWS. Aufgrund der Dringlichkeit wählt er Notfall im Dialog aus und fordert bei Dr. Czeslik (Radiologe) diese MR-Untersuchung an. Fr. Huber hatte vor vielen Jahren einen Eingriff im Kopf wegen einem Hirnaneurysma, welches mit Clips therapiert wurde. Dies ist jedoch ihrem Hausarzt nicht bekannt. Bekannt ist dem Hasuarzt jedoch eine leichte chronische Niereninsuffizienz bei Z.n. rezidivierenden Harnwegsinfekten. Deswegen ist Fr. Huber labortechnisch auch unter ständiger Kontrolle bei Dr. Greber. Interaction 1: Care Transfer Request Auftrag: Auftragsnummer: Erstellungsdatum: Erstellungszeit: 14:30 Patient: Name: Huber Vorname: Anna Adresse: Vogelweg 12, Freiburg ID: Versicherung: BEK Versichtertenstatus: Mitglied Hausarzt: Dr. Greber, Karlstr. 5, Freiburg Kontaktperson: Werner Huber, Eheman Zuweiser: Zuweiserorganisation: Praxis Dr.Greber, o Adresse: Karlstr. 5, Freiburg o Telefon: o ID: Zuweiser: Hr. Greber o ID: Zuätzlicher Informationsempfänger: Patient (Gewünschter) Leistungserbringer: Organisation Leistungserbringer: Radiologische Praxis Czeslik