Harald Kornfeil (ÖGAM / ÖÄK)
Alexander Mense (HL7 Austria),
Stefan Sabutsch (HL7 Austria, ELGA GmbH),
<sup>1</sup> Personen sind ohne Titel angegeben
=Technischer Hintergrund=
==ELGA==
{{BeginILFBox}}
Der technische Hintergrund soll im [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Technischer_Hintergrund| allgemeinen Leitfaden]] nachgelesen werden.{{EndILFBox}}
==Rahmenrichtlinie für die IT-Infrastruktur bei der Anwendung von Telemonitoring: Messdatenerfassung==
{{BeginYellowBox}}
Inhaltlich beschreibt die Rahmenrichtlinie den idealtypischen Ablauf einer zusätzlichen Betreuung mit Telemonitoring, stellt die IT-Architektur für Telemonitoring und die Systemanforderungen hinsichtlich der Interoperabilität dar. Skizziert werden weiters die Ziele und auch die Nicht-Ziele, die Adressatinnen und Adressaten, die Anbindung an ELGA, die rechtlichen Grundlagen und die technischen Begleitmaßnahmen.{{EndYellowBox}}
Folgender Auszug gibt eine Einführung in die Rahmenrichtlinie. Es ist zu empfehlen das Dokument im Zuge der Vorbereitung für die Implementierung eines Telemonitoring Episodenberichts zu lesen.
:''Vorarbeiten für vorliegende Rahmenrichtlinie des BMGF waren die Ergebnisse und Empfehlungen der Telegesundheitsdienste Kommission und der Projektgruppe Telegesundheitsdienste im Auftrag der Zielsteuerung und unter Mitwirkung von Bund (Leitung), Ländern und Sozialversicherung. Im Rahmen dieser Arbeiten wurde festgestellt, dass eine grundlegende technische "Guideline" in Form dieser Rahmenrichtlinie benötigt wird, die ein sinnvolles und hilfreiches Hilfsmittel für die in weiterer Folge genannten AdressatInnen bei der Umsetzung von Telemonitoring sein soll. Die hier vorliegende IT Architektur kann im Sinne der Machbarkeit derzeit keine vollständige Umsetzung abdecken und beschränkt sich daher auf die Messdatenerfassung im Rahmen des Telemonitorings. Diese Rahmenrichtlinie betrifft das Telemonitoring für Patientinnen und Patienten, die zur Behandlung/Überwachung ihrer Erkrankung ein zusätzliches Telemonitoring in Anspruch nehmen wollen. Es ist vorgesehen, dass die vorliegende Rahmenrichtlinie für sämtliche öffentlich finanzierte Telemonitoring Anwendungen angewendet werden muss. Diese Rahmenrichtlinie bezieht sich ausschließlich auf den Unterpunkt Überwachung/Monitoring/Messdatenerfassung der PatientInnen und nicht auf die umfassende Kommunikation, welche jedoch weiter entwickelt werden kann – auch im Sinne einer "feedback Funktion" GDA an Patient, bzw. im Führen z.B. eines Therapietagebuches durch die Patienten.''<ref name="telemonitoring Rahmenrichtlinie">Rahmenrichtlinie für die IT-Infrastruktur bei der Anwendung von Telemonitoring: Messdatenerfassung [https://www.sozialministerium.at/Themen/Gesundheit/eHealth/Telemedizin/Rahmenrichtlinie-f%C3%BCr-die-IT-Infrastruktur-bei-der-Anwendung-von-Telemonitoring--Messdatenerfassung-.html]</ref>
Aktuell (2020-07) gültiger, direkter Download der Rahmenrichtlinie: https://www.sozialministerium.at/dam/jcr:c6f54325-0c71-4614-93ff-3358d1cfea27/telemonitoring_rahmenrichtlinie_.pdf
==Allgemeine Richtlinien für ELGA CDA-Implementierungsleitfäden==
{{BeginILFBox}}
Die [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Allgemeine_Richtlinien_f.C3.BCr_CDA-Implementierungsleitf.C3.A4den|allgemeinen Richtlinien für ELGA CDA-Implementierungsleitfäden]] sollen beachtet werden.
{{EndILFBox}}
=Funktionale Anforderungen= Patienten können mit Telehealth-Systemen (medizinische Telemonitoring-Systeme) ihre Selbstmesswerte (z.B. Körpergewicht, Blutzucker, Blutdruck, Herzfrequenz, Wohlbefinden, Schritte) und zusätzlich auch Medikationsdaten, die verwendeten Medizingeräte, das Feedback aufgrund von Selbstmesswerten der GDAs (Gesundheitsdiensteanbieter) und weitere medizinische Daten in einer Datenzentrale speichern. Alle diese Daten gemeinsam werden als Telehealth-Daten bezeichnet. Ein spezieller Anwendungszweck sind Disease Management Programme (DMP), welche mit Telehealth-Daten unterstützt werden. GDAs interagieren und kommunizieren mit den Patienten auf eine regelmäßige, koordinierte Weise, um eine Erkrankung über eine definierte Zeitspanne zu behandeln. Bei diesen Erkrankungen ist die Selbstpflege der Patienten für einen positiven Krankheitsverlauf unumgänglich. Ein DMP kann durch Selbstmesswert-Geräte und Webservices unterstützt werden, um eine aus der Ferne mit Telehealth-Daten unterstützte Behandlung zu ermöglichen. Mit einer automatischen, standardisierten Erstellung und Meldung dieses neuen Dokuments in ELGA bietet man den Patienten volle Einsicht in die erhobenen Telehealth-Daten über das ELGA-Portal, in welchem auch weitere Dokumente von verschiedensten GDAs zur Verfügung stehen. Auch anderen und zukünftig behandelnden GDAs erleichtert man damit den Zugriff auf die erhobenen Telehealth-Daten und die dazugehörigen Behandlungen. Zusätzlich haben die von den GDAs eingesetzten Informationssysteme die Möglichkeit, diese Informationen in diesem Dokument automatisiert einzulesen und abzurufen. ==Voraussetzungen für den Zugriff auf e-Befunde Medikation in ELGA==
Der ELGA GDA ist in ELGA angemeldet, berechtigt und besitzt eine gültige Kontaktbestätigung für den Patienten.
Der Patient ist ELGA-Teilnehmer und hat keinen generellen, partiellen oder situativen Widerspruch hinsichtlich ELGA oder der e-Medikation eingelegt.
==Anwendungsfälle des Dokumentenmanagements==
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Filtern_und_Suchen_von_Dokumenten|Filtern und Suchen von Dokumenten]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Lesen_von_ELGA_Dokumenten|Lesen von Dokumenten]]
<div class="landscape">
===Dokument-Metadaten (XDS-Metadaten)===
{| class="wikitable"
! colspan="2"|XDS-Element mit Link zum XDS-Leitfaden
! Optionalität im XDS-Leitfaden
! CDA-Element in /ClinicalDocument
! Werte ''mit Beispielen''
! Erklärung
|-
| rowspan="2" colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#uniqueId_2|uniqueId]]
| rowspan="2"|M
| rowspan="2"|./id
|
*@root="''1.2.40.0.34.3.1.1058.1337.999021.1''"
| rowspan="2"| Das uniqueId Element beschreibt den global eindeutigen Identifier des Dokuments und kann mit oder ohne Extension angegeben werden.
|-
|
*@root="''1.2.40.0.34.3.1.1058.1337''"
*@extension="''999021.1''"
|-
| rowspan="2" colspan="2"| [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
| rowspan="2"| R
| rowspan="2"| ./code
|
*@code="75497-8"
*@displayName="Telehealth Progress note"
*@codeSystem="2.16.840.1.113883.6.1"
| Zur Unterscheidung des Dokumenttyps erhält das Element code des '''"Telemonitoring Zwischen-Episodenbericht"''' ein vorgegebenes "code"-Element.
|-
|
*@code="75498-6"
*@displayName="Telehealth Summary note"
*@codeSystem="2.16.840.1.113883.6.1"
| Zur Unterscheidung des Dokumenttyps erhält das Element code des '''"Telemonitoring Entlassungs-Episodenbericht"''' ein vorgegebenes "code"-Element.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#classCode_.28und_classCodeDisplayName.29_2|classCode]]
| R
| ./code/translation
|
*@code="75496-0"
*@displayName="Telehealth note"
*@codeSystem="2.16.840.1.113883.6.1"
| Bezeichnet die "Dokumentklasse" in dem untergeordneten "translation"-Element. Einzig zulässige Wert für den telemonitoring Episodenbericht ist Telehealth note (75496-0).
|-
| rowspan="2" colspan="2"| [[ILF:XDS_Metadaten_(Version_3)#title_2|title]]
| rowspan="2"| R
| rowspan="2"| ./title
|
*"Zwischenbericht Herz-Mobil Steiermark (23.3.2020-30.4.2020)"
| Für den Telemonitoring Episodenbericht mit dem LOINC Code 75497-8 (Telehealth Progress note) muss der Titel mit "Zwischenbericht" beginnen. Danach soll das Telegesundheitsdienste-System angegeben werden und mit dem Zeitraum der in dem Dokument vorhandenen Daten enden.
|-
|
*"Entlassungsbericht Herz-Mobil Tirol (5.2020)"
| Für den Telemonitoring Episodenbericht mit dem LOINC Code 75498-6 (Telehealth Summary note) muss der Titel mit "Entlassungsbericht" beginnen. Danach soll das Telegesundheitsdienste-System angegeben werden und mit dem Zeitraum der in dem Dokument vorhandenen Daten enden.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#formatCode_.28und_formatCodeDisplayName.29_2|formatCode]]
| M
| ./hl7at:formatCode
|
*@code="urn:hl7-at:telemon-epi:1.2.0+20210304"
*@codeSystem="1.2.40.0.34.5.37"
*@displayName="HL7 Austria Telemonitoring Episodenbericht 1.2.0+20210304"
| Version des vom CDA erfüllten Telemonitoring Episodenbericht Implementierungsleitfades.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#practiceSettingCode_.28und_practiceSettingCodeDisplayName.29_2|practiceSettingCode]]
| M
| ./hl7at:practiceSettingCode
|
*@code="''F019''"
*@codeSystem="1.2.40.0.34.5.12"
*@displayName="''Innere Medizin''"
| Fachliche Zuordnung des Dokuments.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#creationTime_2|creationTime]]
| M
| ./effectiveTime
|
*@value="''20181213095800+0200''"
| Das letzte medizinisch relevante Datum, an welchem das Dokument medizinische Inhalte hinzugefügt worden sind.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#confidentialityCode_2|confidentialityCode]]
| M
| ./confidentialityCode
|
*@code="''N''"
*@displayName="''normal''"
*@codeSystem="2.16.840.1.113883.5.25"
*@codeSystemName="HL7:Confidentiality"
| Vertraulichkeitscode des Dokuments. Für ELGA-Dokumente ist ausschließlich "N" erlaubt!
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#languageCode_2|languageCode]]
| M
| ./languageCode
|
*@code="de-AT"
| Für ELGA ist in @code für CDA und Ableitungen in die XDSDocumentEntry-Metadaten derzeit ausschließlich der Wert "de-AT" zulässig. Für eHealth können in zukünftigen Versionen des Leitfadens weitere Sprachcodes erlaubt werden.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#referenceIdList_2|referenceIdList]]
| M
| ./setId
|
*@root="''1.2.40.0.34.3.1.1058.1337''"
*@extension="''999021''"
| Eindeutige Id des Dokumentensets. Diese bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten). Die setId SOLL unterschiedlich zu /ClinicalDocument/id sein.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#sourcePatientId_2|sourcePatientId]]
| M
| ./recordTarget/patientRole/id[1]
|
*@root="''1.2.40.0.34.99.111.1.2''"
*@extension="''123''"
| Patienten ID im Informationssystem des GDA, z.B.: im KIS eines Krankenhauses.
|-
|rowspan="6"| [[ILF:XDS_Metadaten_(Version_3)#author_2|author]]
|rowspan="2"|authorInstitution
|rowspan="2"| M
|rowspan="2"| ./author[1]/assignedAuthor/
representedOrganization/id[1]
|
*@root="''1.2.40.0.34.99.4.1234''"
|rowspan="2"| ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|-
|
*@root="''1.2.40.0.34.99.4''"
*@extension="''1234''"
|-
|rowspan="2"|authorPerson
|rowspan="2"| M
|rowspan="2"| ./author[1]/assignedAuthor
|
* ./id/@root="''1.2.40.0.34.99.111.1.2''"
* ./id/@extension="''999021''"
* ./assignedPerson/name/family="''Holzer''"
* ./assignedPerson/name/given[1]="''Daniela''"
* ./assignedPerson/name/given[2]="''Chiara''"
* ./assignedPerson/name/suffix="''BSc''"
* ./assignedPerson/name/prefix[@qualifier="AC"]="''Dr.''"
|rowspan="2"| Daten der Person/des Geräts (Name, ID, etc.)
|-
|
* ./assignedAuthoringDevice/softwareName="''TelehealthSoftware''"
* ./assignedAuthoringDevice/manufacturerModelName="''TelehealthSolutions''"
|-
|authorRole
| M
| ./author[1]/functionCode
|
*@displayName="''Diensthabender Oberarzt''"
| Rolle der Person.
|-
|authorSpeciality
| M
| ./author[1]/assignedAuthor/code
|
*@displayName="''Fachärztin/Facharzt für Innere Medizin''"
| Fachrichtung des Verfassers des Dokuments aus ELGA_AuthorSpeciality.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#legalAuthenticator_2|LegalAuthenticator]]
| M
| ./legalAuthenticator[1]/assignedEntity
|
* ./id/@root="''1.2.40.0.34.99.111.1.2''"
* ./id/@extension="''999021''"
* ./assignedPerson/name/family="''Holzer''"
* ./assignedPerson/name/given[1]="''Daniela''"
* ./assignedPerson/name/given[2]="''Chiara''"
* ./assignedPerson/name/suffix="''BSc''"
* ./assignedPerson/name/prefix[@qualifier="AC"]="''Dr.''"
| Rechtlicher Unterzeichner des Dokuments.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#eventCodeList_.28und_eventCodeListDisplayName.29_2|eventCodeList]]
| R
| ./documentationOf[1]/serviceEvent/code
|
*@code="''719858009''"
*@displayName="''Telehealth monitoring (regime/therapy)''"
*@codeSystem="2.16.840.1.113883.6.96"
*@codeSystemName="SNOMED CT"
| Code der Gesundheitsdienstleistung.
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#serviceStartTime_.2F_serviceStopTime_2|serviceStartTime]]
|R
|./documentationOf[1]/serviceEvent/
effectiveTime/low
|
*@value="''20181001082015+0200''"
| Zeitpunkt des Behandlungsbeginns (erster medizinisch relevanter Behandlungstag dieser dokumentierter Gesundheitsdienstleistung)
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#serviceStartTime_.2F_serviceStopTime_2|serviceStopTime]]
|R
|./documentationOf[1]/serviceEvent/
effectiveTime/high
|
*@value="''20181213105900+0200''"
| Zeitpunkt des Behandlungsendes (letzter medizinisch relevanter Behandlungstag dieser dokumentierter Gesundheitsdienstleistung, muss sich von Behandlungsbeginn unterscheiden)
|-
| colspan="2"|[[ILF:XDS_Metadaten_(Version_3)#healthcareFacilityTypeCode_.28und_healthcareFacilityTypeCodeDisplayName.29_2|healthcareFacilityTypeCode]]
|R
|./componentOf/encompassingEncounter/
location/healthCareFacility/code
|
*@code="''300''"
*@displayName="''Allgemeine Krankenanstalt''"
*@codeSystem="1.2.40.0.34.5.2"
| Klassifizierung des GDA.
|}
</div>
=Konformitätsprüfung=
Ein zu diesem Implementierungsleitfaden konformes CDA-Dokument ist zunächst ein valides CDA Release 2.0 XML-Dokument mit [[ILF:Allgemeiner_Implementierungsleitfaden_2020#CDA_Header|Header]] und [[ILF:Allgemeiner_Implementierungsleitfaden_2020#CDA_Body|Body]]. Darüber hinaus erfüllt es alle in diesem Leitfaden festgelegten "Geschäftsregeln".
Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten wieder: die Validierung in zwei Schritten. Im ersten Schritt stellt dies die Validierung gegen zugehörige '''W3C Schemas''' dar. Das verwendete Schema ist das geringfügig erweiterte offizielle CDA Release 2.0 Schema (siehe [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schema-Pr.C3.BCfung|Schema-Prüfung]]). Darüber hinaus existieren eine Reihe von '''Schematron''' Regeln, die für einen zweiten Validierungsschritt genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben, sowie die Einhaltung der Geschäftsregeln (Optionalität, Kardinalität/Multiplizität, Datentypen, Wertebereiche, Abhängigkeiten) sicherstellen (siehe [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schematron-Pr.C3.BCfung|Schematron-Prüfung]]). Geschäftsregeln für Abschnitte oder Elemente werden auch technisch zu '''"Templates"''' zusammengefasst. Eine XML-Instanz, die kein valides CDA-Dokument ist oder sich nicht gegen das XSD-Schema validieren lässt oder im Widerspruch zu den angegebenen Geschäftsregeln steht, ist kein gültiges CDA-Dokument im Sinne dieses Implementierungsleitfadens.
{{BeginYellowBox}}
Hinweis: Nicht alle Geschäftsregeln können mit Schema oder Schematron geprüft werden (etwa Inhalte von Multimedia-Attachments, Dokumentengröße). Zusätzliche Validierungsschritte sind gegebenenfalls notwendig, um alle Regeln zu überprüfen zu können.
{{EndYellowBox}}
{{BeginILFBox}}
Die Kapitel zu den technischen Konformitätsprüfungen von CDA-Dokumenten, gemäß diesem Dokumentleitfadens mittels Schema und Schematron, sind im allgemeinen Leitfaden unter den folgenden Links zu finden:
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schema-Pr.C3.BCfung|Schema-Prüfung]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schematron-Pr.C3.BCfung|Schematron-Prüfung]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Online-Validation_von_CDA-Dokumenten|Online-Validation von CDA-Dokumenten]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Hinweise_zur_Konformit.C3.A4tspr.C3.BCfung|Hinweise zur Konformitätsprüfung]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Abnahmepr.C3.BCfung_f.C3.BCr_ELGA_e-Befunde|Abnahmeprüfung für ELGA e-Befunde]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Zertifizierung|Zertifizierung]]
{{EndILFBox}}
=Datentypen=
{{BeginILFBox}}
Im [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Datentypen|Kapitel Datentypen im allgemeinen Leitfaden]] werden nur die Datentypen beschrieben, die in ELGA CDA-Dokumenten wie diesem zur Anwendung kommen. Für weiterführende Informationen wird auf den zugrundeliegenden Standard Health Level Seven Version 3 (V3), Normative Edition verwiesen.
{{EndILFBox}}
=Anwendungsfälle zur Nutzung der e-Medikation=
Zum besseren Verständnis des Implementierungsleitfaden e-Medikation sowie dem Zusammenspiel der CDA-Dokumente werden im Folgenden die Anwendungsfälle für die e-Medikation kurz dargestellt.
==Allgemein== ===Akteure===Folgende '''Akteure ''' werden in der ELGA-Anwendung e-Medikation (eMEDAT) definiert:
* Akteure im niedergelassenen Bereich
** Arzt
*** etc.
===Dokumententypen===Der gegenständliche Implementierungsleitfaden „e-Medikation“ definiert die folgenden '''CDA- Dokumente''': Rezept, Abgabe, Korrekturmeldung (Pharmazeutische Empfehlung) und Medikationsliste. Um den Medikationsprozess und die folgend beschriebenen Anwendungsfälle abbilden zu können, werden diese Dokumente mit den folgenden Status in der e-Medikation abgebildet:
* Rezept (PRESCRIPTION; Ein Rezept wird durch ein Prescription Dokument abgebildet und kann eine oder mehrere Verordnungen enthalten. Bezüglich der möglichen Statuswerte unterscheiden sich das Prescription Dokument und die einzelnen Verordnungen.)
** OFFEN
Das Rezept wird durch eine Rezeptart gekennzeichnet, um die Gültigkeitsdauer prüfen zu können. In e-Medikation werden folgende Rezeptarten berücksichtigt:
* Kassenrezept – 1 Monat gültig und entspricht dem Zeitraum vom Ausstellungszeitpunkt bis zum gleichen Tag im Folgemonat 23:59 Uhr; eine Einlösung möglich; im Zuge des „Besorgerprozesses“ wird bei einer gespeicherten Teilabgabe die gesamte Gültigkeitsdauer auf 3 Monate verlängert; Es ist nicht möglich, zusätzliche Einlösungen anzugeben.
** Beispiel: Wenn ein Kassenrezept am 1.4., 16:45 Uhr ausgestellt wird, dann ist es bis 2.5., 00:01 Uhr gültig. Möglicherweise führt das erwähnte „add_month“ dazu, dass die die Gültigkeit in dem Fall auf die Uhrzeit genau, also auf 2.5., 16:45 Uhr gesetzt wird, was dann zu dem Fehler führt.
* Privatrezept - 12 Monate gültig, sofern die erste Einlösung innerhalb von 1 Monat ab Erstelldatum erfolgt ist** Die maximale Gültigkeitsdauer beträgt 365 Tage bzw. sind bis zu 6 Einlösungen möglich, wobei Gültigkeitsdauer und Anzahl der möglichen Einlösungen vom Arzt definiert werden können. Dabei muss das Privatrezept innerhalb des ersten Monats erstmalig eingelöst werden (§ 4 Abs. 1 RezeptpflichtG).* Substitutionsrezept – Maximale Gültigkeitsdauer von 12 Monaten. Das GültigVon Datum darf maximal einen Monat in der Zukunft liegen.
Es ist nicht möglich, zusätzliche Einlösungen anzugeben.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
Es können die folgenden Fehlerfälle aus der Schnittstelle zur e-Medikation heraus auftreten:
* Speichern der Verordnung in e-Medikation nicht möglich* eMED-ID nicht ermittelbar
Hinweis: Die Ausstellung eines e-Rezepts bzw. eines Papierrezepts darf durch eine etwaiges „Nicht-funktionieren“ der e-Medikation nicht verhindert werden.
===Ablauf===
Der Akteur kann die Verordnungen des ELGA-Teilnehmers abfragen. Es stehen grundsätzlich zwei Suchvarianten zur Verfügung
* Alle Verordnungen von noch nicht eingelösten und noch nicht abgelaufenen Rezepten. (findPrescriptionsForDispense)
* Alle Verordnungen in einem bestimmten Zeitraum (findPrescriptions)
Für diese beiden Abfragen gibt es zwei mögliche „Startpunkte“:
* Startpunkt 1: Suche mit eMED-ID Assertion
** Suche ohne einem Patientenkontakt im ELGA BeS, auf Basis der eMED-ID Assertion, welche aufgrund der Angabe einer eMED-ID ausgestellt wurde. Mit dieser Assertion können ausschließlich Dokumente gefunden werden, die mit der betreffenden eMED-ID zusammenhängen (Rezept und zugehörige Abgaben, bzw. Pharmaceutical Advices).
* Startpunkt 2: Suche mit Patientenkontakt
** Bei der Suche nach Rezepten mit einem Patientenkontakt im ELGA BeS (z.B. auf Basis der gesteckten e-card), können alle Rezepte des ELGA-Teilnehmers gesucht werden.
Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. ausstellender GDA darf angezeigt werden). Es werden über die Schnittstelle alle verfügbaren Datenfelder zu einer Verordnung/Rezept geliefert (lt. Datenmodell).
===Ablauf===
* Einzelne Verordnung stornieren:
** Eine Verordnung kann mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) storniert werden. Der Akteur bestimmt die Verordnung (oder mehrere), welche storniert werden soll/sollen. Die Auswahl erfolgt über die VerordnungsID. Die Verordnung erhält den Status „STORNIERT“. Eine Stornierung ist nur zulässig, falls die referenzierte Verordnung bereits in e-Medikation vorhanden ist und den Status„OFFEN“ besitzt. Bereits abgegebene Verordnungen können nicht mehr verändert werden.
* Ganzes Rezept stornieren:
** Ein Rezept gilt als storniert, wenn einer der folgenden beiden Methoden angewandt wird:
*** Der Akteur bestimmt alle Verordnung des Rezepts und storniert jede einzelne Verordnung des Rezepts. Das Rezept erhält den Status = STORNIERT, wenn alle zugeordneten Verordnungen den Status = STORNIERT aufweisen.*** Der Akteur bestimmt das Rezept mit den Verordnungen (über eMED-ID). Es wird ein Update der Metadaten des Rezepts ausgeführt. Dies kann nur vom Ersteller des Rezepts durchgeführt werden.
====Ergebnis im Gutfall====
===Ablauf===
* Rezept mit Verordnungen abrufen ** Üblicherweise wird in einem e-Rezept-Datensatz die korrespondierende eMED-ID gespeichert und liegt daher beim Abruf des e-Rezepts elektronisch als Zusatzinformation vor. Alternativ kann die eMED-ID durch Scan des Matrix-Codes auf dem e-Rezept-Ausdruck oder durch manuelle Eingabe erfolgen. In diesem Fall ist keine ELGA-Kontaktbestätigung erforderlich. Allerdings ist hierdurch ausschließlich der Zugriff auf die Daten des durch die eMED-ID referenzierten Rezepts möglich und nicht auf andere in der e-Medikation gespeicherte Daten (z.B. komplette e-Medikationsliste des Patienten). *** Abfrage der Verordnungsdaten auf Basis einer bestehenden ELGA-Kontaktbestätigung Sämtliche zu einem ELGA-Teilnehmer in der e-Medikation gespeicherten Verordnungsdaten können auf Basis einer bestehenden ELGA-Kontaktbestätigung (z.B. ausgelöst durch Einlesen der e-card) abgerufen werden. * Abgabe in der e-Medikation speichern ** Die Daten aus der Verordnung sind in der Regel vollständig für die Abgabe zu übernehmen. In Sonderfällen (z.B. Austausch eines Medikaments nach Rücksprache mit dem Arzt) können die aus der Verordnung übernommenen Daten geändert werden. ** Für den Fall, dass bereits erfolgte Abgaben nacherfasst werden sollen (z.B. technische Probleme zum Zeitpunkt der eigentlichen Abgabe), wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das in der Vergangenheit liegende Datum der tatsächlichen Abgabe eingetragen wird
In der Fachlogik gelten folgende Prüfregeln:
Dies hat den Vorteil, dass man auch die Historie der Änderungen sehen kann, welche in der Implementierung der Medikationsliste bereits eingearbeitet sind.
=Dataset des Telemonitoring EpisodenberichtsKonformitätsprüfung=Das Dataset (auch "Datenarten" oder Ein zu diesem Implementierungsleitfaden konformes CDA-Dokument ist zunächst ein valides CDA Release 2.0 XML-Dokument mit [[ILF:Allgemeiner_Implementierungsleitfaden_2020#CDA_Header|Header]] und [[ILF:Allgemeiner_Implementierungsleitfaden_2020#CDA_Body|Body]]. Darüber hinaus erfüllt es alle in diesem Leitfaden festgelegten "KonzepteGeschäftsregeln") listet alle mit der Arbeitsgruppe abgestimmten Inhalte des Leitfadens auf. Es enthält Beschreibungen der Elemente mit Synonymen.
DatasetDies spiegelt ein generelles Konzept im Umgang mit Dokumenten wieder: die Validierung in zwei Schritten. Im ersten Schritt stellt dies die Validierung gegen zugehörige '''W3C Schemas''' dar. Das verwendete Schema ist das geringfügig erweiterte offizielle CDA Release 2.0 Schema (siehe [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schema-Pr.C3.BCfung|Schema-Prüfung]]). Darüber hinaus existieren eine Reihe von '''Schematron''' Regeln, die für einen zweiten Validierungsschritt genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben, sowie die Einhaltung der Geschäftsregeln (Optionalität, Kardinalität/Multiplizität, Datentypen, Wertebereiche, Abhängigkeiten) sicherstellen (siehe [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schematron-Pr.C3.BCfung|Schematron-Prüfung]]). Geschäftsregeln für Abschnitte oder Elemente können auf werden auch technisch zu '''"Templates"''' zusammengefasst. Eine XML-Instanz, die kein valides CDA-Dokument ist oder sich nicht gegen das XSD-Schema validieren lässt oder im Widerspruch zu den angegebenen Geschäftsregeln steht, ist kein gültiges CDA Datenmodell gemappt -Dokument im Sinne dieses Implementierungsleitfadens.{{BeginYellowBox}}Hinweis: Nicht alle Geschäftsregeln können mit Schema oder Schematron geprüft werden(etwa Inhalte von Multimedia-Attachments, Dokumentengröße). In Zusätzliche Validierungsschritte sind gegebenenfalls notwendig, um alle Regeln zu überprüfen zu können. {{EndYellowBox}}{{BeginILFBox}}Die Kapitel zu den Metadaten eines Templates technischen Konformitätsprüfungen von CDA-Dokumenten, gemäß diesem Dokumentleitfadens mittels Schema und Schematron, sind alle assoziierten Konzepte auf einen Blick ersichtlichim allgemeinen Leitfaden unter den folgenden Links zu finden: *[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schema-Pr.C3.BCfung|Schema-Prüfung]]*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schematron-Pr.C3. Im TemplateBCfung|Schematron-Prüfung]]*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Online-Validation_von_CDA-Dokumenten|Online-Validation von CDA-Body wird das assoziierte Konzept beim entsprechenden Datenelement angezeigtDokumenten]]*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Hinweise_zur_Konformit.C3.A4tspr.C3.BCfung|Hinweise zur Konformitätsprüfung]]*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Abnahmepr.C3.BCfung_f.C3.BCr_ELGA_e-Befunde|Abnahmeprüfung für ELGA e-Befunde]]*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Zertifizierung|Zertifizierung]]{{EndILFBox}}
Die Live-Version des Datasets in Art-Decor kann unter folgendem =Datentypen={{BeginILFBox}}Im [[httpsILF://artAllgemeiner_Implementierungsleitfaden_2020#Datentypen|Kapitel Datentypen im allgemeinen Leitfaden]] werden nur die Datentypen beschrieben, die in ELGA CDA-decorDokumenten wie diesem zur Anwendung kommen.org/art-decor/decor-datasets--elgatgd- Link] betrachtet werdenFür weiterführende Informationen wird auf den zugrundeliegenden Standard Health Level Seven Version 3 (V3), Normative Edition verwiesen.<div class="landscape">{{EndILFBox}}
=Technische Spezifikation=
