Arztbrief Plus
| Zeile 38: | Zeile 38: | ||
=Dokumenteninformationen= | =Dokumenteninformationen= | ||
| − | + | [[Datei:Abplogo.png|ABP]] | |
| − | + | {{HL7transclude| cdaab3:Impressum}} | |
| − | + | {{HL7transclude| cdaab3:Ansprechpartner}} | |
| + | {{HL7transclude| cdaab3:Disclaimer}} | ||
| + | {{HL7transclude| cdaab3:Autoren}} | ||
| + | {{HL7transclude| cdaab3:Danksagung}} | ||
| + | {{HL7transclude| cdaab3:Einleitung}} | ||
| + | =Templates für den Arztbrief= | ||
| + | {{HL7transclude| cdaab3:Arztbriefstruktur}} | ||
<!-- | <!-- | ||
der Rest | der Rest | ||
--> | --> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Version vom 7. Juli 2017, 21:14 Uhr
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden Arztbrief Plus (3.10). Die Teilmaterialien gehören der Kategorie cdaab3 an. |
auf Basis der HL7 Clinical Document Architecture Release 2
für das deutsche Gesundheitswesen
HL7 Deutschland
| Version: | 3.10 |
| Datum: | 7. Juli 2017 |
| Status: | Bestätigt |
| Verfahren: | {{{Verfahren}}} |
| Realm: |  Deutschland
|
| Abstimmungsdokument | |||
|---|---|---|---|
| Version | Datum | Status | Realm |
| 3.00 | 11.04.2017 |  Abstimmung |
Deutschland
|
 |
[download] | ||
| 3.10 | 07.07.2017 | Bestätigt | Deutschland
|
|
[download] | ||
| Kontributoren | ||
|---|---|---|
|
Heitmann Consulting and Services GmbH, Gefyra GmbH | Hürth |
|
ZTG GmbH | Bochum |
|
Deutsche Telekom Healthcare and Security Solutions GmbH | Berlin |
Inhaltsverzeichnis
- 1 Dokumenteninformationen
- 2 Einleitung
- 3 Templates für den Arztbrief
- 3.1 Dokumentenstruktur Arztbrief
Dokumenteninformationen
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Impressum
Dieser Leitfaden wurde im Rahmen des Interoperabilitätsforums und der Technischen Komitees von HL7 Deutschland e. V. sowie der entsprechenden Projektgruppen erstellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums[1] und der Technischen Komitees von HL7 Deutschland e. V. [2]
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Ansprechpartner
- Dr. Kai U. Heitmann, HL7 Deutschland e.V., Heitmann Consulting and Services, Gefyra GmbH
- Dr. Frank Oemig, Deutsche Telekom Healthcare and Security Solutions GmbH, Bonn
- Mathias Aschhoff, RZV GmbH, Volmarstein
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Disclaimer
 |
Disclaimer
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Autoren
- Dr. Kai U. Heitmann, HL7 Deutschland e.V., Heitmann Consulting and Services, Gefyra GmbH
- Dr. Frank Oemig, Deutsche Telekom Healthcare and Security Solutions GmbH, Bonn
- Mathias Aschhoff, RZV GmbH, Wetter
Copyright-Hinweis, Nutzungshinweise
Die erste Version dieses Dokumentes wurde 2005 vom Verband der Hersteller von IT für das Gesundheitswesen (VHitG, heute bvitg) entwickelt und ist unter dem Namen "VhitG-Arztbrief" bekannt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.
Der Inhalt dieser Spezifikation ist öffentlich.
Der VHitG-Arztbrief basiert auf den Spezifikationen der Arbeitsgemeinschaft SCIPHOX GbR mbH und dem national adaptierten HL7-Standard der „Clinical Document Architecture (CDA)".
Die hier erarbeitete Fassung ist die Weiterentwicklung davon. Sie ist u.a. auch abgeglichen mit den ELGA-Spezifikationen (http://elga.gov.at) in Österreich.
Näheres unter http://www.hl7.de und http://www.hl7.org. Für alle veröffentlichten Dateien mit einem CDA-Bezug gilt ferner: Alle abgestimmten und veröffentlichten Spezifikationen wie Implementierungsleitfäden, Stylesheets und Beispieldateien sind frei verfügbar und unterliegen keinerlei Einschränkungen, da die Autoren auf alle Rechte, die sich aus der Urheberschaft der Dokumente ableiten lassen, verzichten.
Alle auf nationale Verhältnisse angepassten und veröffentlichten CDA-Schemas können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
Aus der Nutzung ergibt sich kein weiter gehender Anspruch gegenüber dem VHitG bzw. bvitg, zum Beispiel eine Haftung bei etwaigen Schäden, die aus dem Gebrauch der Spezifikationen bzw. der zur Verfügung gestellten Dateien entstehen.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Einleitung
Motivation
Dieser Leitfaden soll als generische Grundlage für Arztbriefe aller Art dienen und damit die Ablösung der papiergebundenen Arztbriefe ermöglichen. Entsprechende Anwendungsbeispiele finden sich im Anhang dieses Leitfadens und dienten als Grundlage für die Vollständigkeit der Analyse.
Im Rahmen der Kommunikation zwischen Akteuren im Gesundheitswesen ist der Arztbrief als „Kondensat ärztlichen Handelns" von überragender Bedeutung. Das Ziel dieses Dokuments ist die Beschreibung des elektronischen Arztbriefs. Ein derartiger Arztbrief enthält die medizinisch relevanten Teile der Geschichte eines Patienten über einen bestimmten Zeitraum und ist gedacht zur Übermittlung zwischen Gesundheitsdienstleistern (primär: „Leistungserbringer"). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA-Elementen.
Zielgruppe
Der Leserkreis dieses Dokuments sind Software-Entwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld des „Arztbriefs" betraut sind.
Diese Spezifikation definiert zusätzliche Festlegungen, Einschränkungen und Bedingungen für die CDA-Elemente in „Arztbrief"-Dokumenten, die als „stationärer Entlassbrief" von Kliniken im Bereich deutscher Gesetzgebung (SGB) an Niedergelassene (auch: REHA-Einrichtungen) oder als „(Fach-) Arztbrief" vom niedergelassenen (Fach-) Arzt an niedergelassene Kollegen oder Krankenhäuser versendet werden sollen.
Beispiele für konforme Dokumenten-Fragmente werden innerhalb dieses Leitfadens aufgeführt. Die Spezifikation von Infrastrukturen, Workflows, Nachrichten, Prozeduren oder Protokollen zur Übermittlung der Arztbriefe ist nicht im Fokus dieses Dokuments.
Ein elektronischer Arztbrief wird vom Gesetzgeber nach §291a ff. SGB V im Rahmen der Einführung der elektronischen Gesundheitskarte als freiwillige Anwendung betrachtet. Es ergeben sich mit Einführung einer nationalen Telematikinfrastruktur verschiedene Vorgaben für einen solchen Arztbrief, die in diesem Implementierleitfaden nicht umfänglich dokumentiert sein sollen. An den nötigen Stellen wird versucht, Hinweise auf relevante Implikationen und Überschneidungen zu geben.
Dokumente im Gesundheitswesen
Wir sind es in der medizinischen Welt gewohnt, eine Dokumentenansicht von medizinischen Beobachtungen zu verfassen, reich an Text, den Zusammenhang des Geschehens zusammenstellend und zusammenfassend. Dieser Kontext – z. B. das Ergebnis einer Laboruntersuchung im Lichte einer speziellen Medikamentenbehandlung – muss dauerhaft erhalten bleiben, da er wichtige medizinische Zusammenhänge zwischen Einzelinformationen darstellt. Die Krönung dieses „in den Kontext stellen" von Informationen über die Zeit stellt zum Beispiel der Arztbrief dar. Gleichzeitig muss der medizinische Inhalt leicht verfügbar sein und ohne große technische Barrieren sichtbar gemacht werden können. Dies ist unabdingbar für die Akzeptanz und das Vertrauen in Technologie bei den Benutzern, den Ärzten und Pflegekräften. Mit der heutigen Papierwelt wurde dies bis zu einem gewissen Grade erreicht, es muss aber für das Einführen des elektronischen Gegenstücks ebenso gelten. „Interoperabilität" ist unter anderem gekennzeichnet durch gemeinsam verstandene Definitionen, wie zum Beispiel die des Patienten und der zu ihm bekannten (klinischen/medizinischen) Informationen, sowie deren Wiederverwendbarkeit. Hierbei kann man zwei Gegenpole beobachten. Zum einen ist da die Facette der Mensch-zu-Mensch Kommunikation. Dies wird z. B. erreicht durch das Versenden von Papier und Formularen. Jeder weiter führende elektronische Ansatz muss auch diese Art der Interoperabilität gewährleisten. Die Möglichkeit zur Signatur muss auch in elektronischer Form bestehen bleiben. Darüber hinausgehend wäre das andere Ende die Anwendungs-Interoperabilität. Dies beinhaltet die Wiederverwendbarkeit von Informationen, Kontext-abhängige Analysemöglichkeiten und angemessenes Speichern und Verwalten von klinischen Dokumenten.
Im Rahmen der bvitg-Initiative „Intersektorale Kommunikation" wird der Arztbrief als generisches Dokument beschrieben. So wird beispielhaft die Entlassung nach durchgeführter Behandlung in einem Krankenhaus o. ä. zur Weiterbehandlung durch den Niedergelassenen (Dokument „stationärer Entlassungsbrief") definiert, wie auch der ambulante Arztbrief des Facharztes zur Weiterbehandlung über den Hausarzt oder im Krankenhaus.
Im Falle der Entlassung/Ende der Behandlung werden die Behandlungsdaten übermittelt. Der Kurzbericht bei Entlassung/Behandlungsende ist als sofortige Mitteilung an den einweisenden/überweisenden Arzt am Ende der Konsultation/Krankenhausaufenthaltes konzipiert und beinhaltet neben der Patientenidentifikation einen Kurzbericht zusammen mit Diagnosen und Therapien, Befunden sowie eine Zusammenfassung. Beispiel: Termine zur Wiedervorstellung oder Nachsorgetermine.
In einer späteren Ausbaustufe kann mit überwiegend den gleichen Teilen wie im Arztbrief auch die Einweisung/Überweisung definiert werden. Das dahinterliegende Szenario: Der Patient geht vom Niedergelassenen in ein Krankenhaus zur Mitbehandlung (Dokument „Einweisung") bzw. wird von einem Niedergelassenen zum anderen überwiesen (Dokument „Überweisung").
Diese Fälle werden allgemein teilweise von den Komponenten im „Arztbrief" abgedeckt, wie zum Beispiel: Aktuelle Medikation, die auch in Ein-/Überweisungen vorkommen kann. Beim Arztbrief handelt es sich dementsprechend um ein Dokument, das in Anlehnung an die realen Gegebenheiten zwischen den Akteuren und Systemen ausgetauscht wird und das dauerhaft existiert, d.h. es wird dauerhaft gespeichert. Dies steht im Gegensatz zum Austausch von Nachrichten, bei dem der Nachrichten-Inhalt vom Empfangssystem in der Regel extrahiert, in der eigenen Datenbank gespeichert und die Nachricht als solche danach gelöscht wird.
Abgrenzung
Dieser Leitfaden deckt eine Reihe von Themen nicht ab, die im folgenden erläutert werden.
- Dieser Leitfaden beschreibt den Arztbrief, genauer: einen ärztlichen Entlassbrief oder Besuchsbericht. Der zugehörige LOINC Code ist 11490-0 Discharge summarization note [physician]. Damit sind sowohl Arztbriefe nach stationärem Aufenthalt als auch ärztliche Berichte nach ambulantem Besuch etwa beim beim Hausarzt abgedeckt.
- Andere Dokumententypen wie z. B. Überweisungen, Überleitungsdoumente, OP-Berichte usw. sind hiermit zwar nicht beschrieben, können aber dem Prinzip nach gleich aufgebaut sein. Insbesondere die hier verwendeten Komponenten (Templates) können einfach wiederverwendet werden. Codes für andere Dokumententypen sind im IHE-Deutschland-Projekt "Value Sets für XDS" abgestimmt und beschrieben[3].
- Digitale Signaturen und andere Sicherheitsaspekte wie Verschlüsselung etc. sind in dieser Spezifikation nicht behandelt. Der geneigte Leser möge hierzu auch die Ausarbeitung zu XML-Signaturen für CDA (Elektronische Signatur von Arztbriefen)[4] konsultieren.
- Diese Spezifikation definiert nicht den Transport von CDA-Dokumenten. Hilfreich ist in diesem Zusammenhang das IHE-Cookbook[5].
- Diese Spezifikation erläutert nicht, wie XSL-Stylesheets zu verwenden sind.
Aufbau dieses Implementierungsleitfadens
Die Spezifikation Arztbrief Plus basiert auf dem Arztbrief 2014/2015[6] und dem VHitG-Arztbrief von 2006 (v1.5)[7] und berücksichtigt hierbei die neueren Entwicklungen und Methodiken zur Erstellung von Leitfäden, beispielsweise die Nutzung von Templates oder speziellen Ausprägungen von Datentypen.
Im Rahmen von "Arztbrief Plus" wird der vorherige Arztbrief 2014/2015 nochmals leicht verbessert und um die so genannten CDA-Entries, also maschinenauswertbare Komponenten erweitert. Die Veränderungen in der Übersicht sind wie folgt:
- Ergänzung noch fehlender Sections wie z. B. Allgemeine Diagnosen, Heil- und Hilfsmittel
- Ergänzung um Templates für CDA-Entries: Diagnosen/Probleme, Prozeduren, Medikation.
Der Arztbrief Plus basiert auch weiterhin auf der Nutzung von Templates (Definitionen wiederverwendbarer Informationsblöcke) wie in internationalem Kontext üblich und erhöht die Wiederverwendbarkeit der einzelnen Komponenten auch in anderen Zusammenhängen.
Dieser Leitfaden soll auch praktische Implementierungshilfen geben. Dies kann bis zu einem gewissen Detaillierungsgrad geschehen und ist in der Regel mit Beispielen in den jeweiligen Templates angereichert, so dass ein Programmierer einer Schnittstelle das nötige Wissen erlangen kann, wie die Schnittstelle aufzubauen ist.
Zudem sind in diesem Leitfaden einige Anhänge aufgenommen, die als Referenzmaterial dienen können und Hinweise geben für eine erfolgreiche Implementierung.
Zum Schluss sei darauf verwiesen, dass alle technischen Artefakte wie Templates und Value Sets auf ART-DECOR® als Spezifikations-Plattform einsehbar sind. Der direkte Link zur ART-DECOR® Live Version ist http://art-decor.org/art-decor/decor-project--abde-, die HTML-Dokumentation steht auf http://hl7de.art-decor.org/index.php?prefix=abde- zur Verfügung. Dort sind auch die ergänzenden Materialien wie Beispieldokumente und Schematrons herunterladbar.
Templates für den Arztbrief
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Dokumentenstruktur Arztbrief
Ein Arztbrief - wie andere Dokumente auch - setzt sich aus verschiedenen Teilen zusammen.
Dem Header mit
- Informationen zum CDA-Dokument wie Id, Datum etc.,
- Informationen über die verschiedenen Beteiligten an einem Dokument wie Patient, Autor, Unterzeichner etc.,
- Informationen über Aktivitäten, die in Zusammenhang mit dem Dokument stehen (Gesundheitsdienstleistung),
Sowie dem Body
- mit Abschnitten für den Text (Sections)
- und maschinenlesbaren, strukturierten Information (Entries).
Beispiel
Im folgenden ist ein Beispielfragment gezeigt. Vollständige Beispiele finden sich in den Begleitmaterialien.
<?xml version="1.0"? encoding="UTF-8">
<ClinicalDocument xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:pharm="urn:ihe:pharm:medication">
<realmCode code="DE"/>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="1.2.276.0.76.10.1020"/>
<id root="1.2.276.0.76.3645.239" extension="di-b02e97c1-3cea-4ed4-80cd-5d8a7386cee2"/>
<code code="11490-0" codeSystem="2.16.840.1.113883.6.1" displayName="Consultation note"/>
<title>eArztbrief vom 4. November 2015</title>
<effectiveTime value="20170401123415"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="de-DE"/>
<setId root="1.2.276.0.76.3645.239" extension="si-b8a7b265-4e20-4177-8cfb-149491b8003a"/>
<versionNumber value="1"/>
...
</ClinicalDocument>
Informationen über Beteiligte und Aktivitäten
Die folgende Tabelle zeigt die Informationen über die verschiedenen Beteiligten und Aktivitäten, die in Zusammenhang mit dem Dokument stehen. Aufgenommen in der Tabelle sind auch Referenzen zu den Definitionen der ELGA (Österreich).
Header
- Patient (recordTarget)
- Autor (Person) (author), Autoren eines Arztbriefs dürfen nur Personen sein, keine Informationssysteme oder medizin-technische Geräte
- Datentypist (dataEnterer)
- Informant (informant)
- Die das Dokument verwaltende Organisation (custodian)
- Empfänger (intendedRecipient)
- Vor dem Gesetz verantwortliche Unterzeichner (legalAuthenticator), hier darf es nur eine juristisch verantwortliche Person geben.
- Unterzeichner (authenticator), einen Arztbrief dürfen aber mehrere Personen unterzeichnen
- Einweisender Arzt (participant)
- Hausarzt (participant)
- Notfallkontakt (participant)
- Angehörige (participant)
- Kostenträger (participant)
- Fachlicher Ansprechpartner (participant)
- Betreuungsorganisation (participant)
- Weitere Beteiligte (participant)
- Patientenkontakt (encompassingEncounter)
Body Entweder
- Unstrukturierter Body, d.h. ohne Abschnitte (section)
Oder eine Auswahl der folgenden Abschnitte
- Anrede, ELGA: Brieftext
- Fragestellung, ELGA: Aufnahmegrund
- Anamnese, ELGA: Anamnese (ärztlich)
- Familienanamnese
- Frühere Erkrankungen, ELGA: Frühere Erkrankungen
- Medizinische Untersuchung, klinische (körperliche) oder apparative Untersuchung
- Befund, ELGA: Erhobene Befunde
- Laborwerte
- Diagnosen (Aufnahme/Entlassung) mit ICD Code, ELGA: Diagnose bei Entlassung
- Besondere Hinweise, zu beachtende wichtige Hinweise zum Patienten, ELGA: Allergien, Unverträglichkeiten, Risiken
- Prozeduren und Maßnahmen, ELGA: Weitere Maßnahmen und Durchgeführte Maßnahmen
- Medikation: Jetzige Medikation, ELGA: Letzte Medikation
- Medikation: Empfohlene Medikation, ELGA: Empfohlene Medikation
- Medikation: Medikation bei Aufnahme, ELGA: Medikation bei Einweisung
- Medikation: Medikation bei Entlassung, ELGA: Verabreichte Medikation während des Aufenthalts
- Impfungen
- Epikrise, hier: Zusammenfassung des Aufenthalts (auch bei ELGA)
- Empfehlung
- Schlusstext, ELGA: Abschließende Bemerkungen
- Anhänge, ELGA: Beilagen; das Entry-Level-Template für externe Referenzen ist dafür gedacht, einzelne Aktivitäten (beispielsweise Befunde oder Maßnahmen) mit Dokumenten zu belegen; Beilagen gemäß ELGA-*Spezifikation müssen in das Dokument eingebettet sein und dürfen nicht referenziert werden.
- Patientenverfügung nur bei ELGA (als Referenz auf die Patienteneinwilligung)
[Tabelle 1]Informationen über die verschiedenen Beteiligten und Aktivitäten
 |
Der Ersteller des Dokuments muss festlegen, ob er einen nicht XML-basierten Body (NonXMLBody) oder auf XML-basierende Abschnitte (section) benutzen möchte. |
Ein Arztbrief kann somit entweder in einem Binärformat als PDF o.ä. Dokument oder XML-formatiert übermittelt werden, und sich entweder ohne Strukturvorgabe oder aus strukturierten Abschnitten zusammensetzen.
Hierarchische Ansicht des Arztbriefs Plus
Die folgende hierarchische Zusammenstellung gibt eine Übersicht über die einzelnen Komponenten des Arztbriefs Plus.
|
Erläuterungen zu Kardinalität, Konformität, NullFlavor
Es wird auf die Erläuterungen andernorts zu den Themen
hingewiesen.
Besondere Hinweise zur Verwendung von Identifikationen (IDs)
In diversen Templates ist die Angabe von identifizierenden Merkmalen möglich. Dabei sind beispielsweise gemeint
- Patienten, identifiziert über die Krankenversichertennummer (KVNR),
- Gesundheitsdienstleister, typischerweise identifiziert über die Lebenslange Arztnummer (LANR),
- Betriebsstätten, typischerweise identifiziert über die Betriebsstättennummer (BSNR),
- Institutionskennzeichen (IKNR) z. B. für Abrechnungen und Qualitätssicherungsmaßnahmen im Bereich der deutschen Sozialversicherung.
Hinweise zu den Identifikationen und Best Practive finden sich im Wiki des Interoperabilitätsforums[8], [9].
Krankenversichertennummer (KVNR)
Die Krankenversichertennummer (KVNR) besteht im unveränderliche Teil aus insgesamt 10 Stellen, beginnend mit einem alphanumerischen Zeichen.
Die Krankenversichertennummer für einen Patienten wird im id-Element der Rolle (... etc.) in der @extension angegeben. Das Identifikationssystem hat die registrierte OID 1.2.276.0.76.4.8 (Versichertennummer, unveränderbarer Teil der Krankenversichertennummer zur Identifikation des Versicherten, gemaess §290 SGB V; für PKV Versicherte: gleich Versicherungsnummer) und wird im @root-Attribut gekennzeichnet.
<recordTarget typeCode="RCT" contextControlCode="OP">
<patientRole classCode="PAT">
<id extension="G995030566" root="1.2.276.0.76.4.8"/>
...
</patientRole>
</recordTarget>
Lebenslange Arztnummer (LANR)
Die LANR für den entsprechenden Arzt wird im id-Element seiner Rolle (assignedEntity, assignedAuthor etc.) in der @extension angegeben. Das Identifikationssystem LANR hat die registrierte OID 1.2.276.0.76.4.16 und wird im @root-Attribut gekennzeichnet.
<assignedAuthor>
<id root="1.2.276.0.76.4.16" extension="123456701"/>
...
</assignedAuthor >
Betriebsstättennummer (BSNR)
Die BSNR für die entsprechende Betriebsstätte wird im id-Element der Rolle (... etc.) in der @extension angegeben. Das Identifikationssystem BSNR hat die registrierte OID 1.2.276.0.76.4.17 und wird im @root-Attribut gekennzeichnet.
<representedOrganization>
<id root="1.2.276.0.76.4.17" extension="123456700"/>
<name>Beispiel Krankenhaus</name>
</representedOrganization>
Institutionskennzeichen (IKNR)
Für die Angabe eines Institutionskennzeichens enthält im id-Element das @extension Attribut das Institutionskennzeichen (IKNR) des Kostenträgers und @root = 1.2.276.0.76.4.5, die OID für IK-Nummern in Deutschland
<scopingOrganization>
<id root="1.2.276.0.76.4.5" extension="123456700"/>
<name>Beispiel Krankenhaus</name>
</scopingOrganization >
Hinweise zu den Darstellungen der Templates
Im folgenden Abschnitt dieser Spezifikation werden alle Templates aufgeführt. Die Darstellung der Definitionen erfolgt in Tabellenform. Weitere Hinweise, die möglicherweise für das Verständnis der Template-Definitionen nötig sein könnten, finden sich in englischer Sprache auf den Erläuterungsseiten von ART-DECOR[10].
- ↑ Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)
- ↑ HL7 Deutschland e. V. http://www.hl7.de
- ↑ IHE Deutschland: Value Sets für XDS http://wiki.hl7.de/index.php?title=IG:ValueSet
- ↑ Erstellung von XML-Signaturen für Dokumente nach Clinical Documents Architecture – R2 (Elektronische Signatur von Arztbriefen). Spezifikation der Bundesärztekammer, Ärztekammer Nordrhein, Ärztekammer Westfalen-Lippe. Version 1.4 vom 20. Mai 2008
- ↑ IHE Deutschland: Cookbook http://wiki.hl7.de/index.php?title=IHE_DE_Cookbook
- ↑ Arztbrief 2014/2015, http://download.hl7.de/documents/cdar2-arztbrief/Arztbrief2014-v100.pdf
- ↑ Arztbrief des VHitG (jetzt bvitg), http://www.bvitg.de/arztbrief.html
- ↑ Informationen zu LANR und BSNR http://wiki.hl7.de/index.php?title=LANR_und_BSNR
- ↑ Best Practice Leitseite des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Kategorie:Best_practice
- ↑ ART-DECOR: How to read ART-DECOR Definitions [3]
Referenzfehler: Es sind <ref>-Tags für die Gruppe „Tabelle“ vorhanden, jedoch wurde kein dazugehöriges <references group="Tabelle" />-Tag gefunden oder ein schließendes </ref> fehlt.
