Änderungen

{{= Funktionale Anforderungen und Anwendungsfälle=== Funktionale Anforderungen==Ein Patient Summary soll alle relevanten Fakten zum Gesundheitszustand eines Patienten enthalten. Es kann daher Informationen aus einer oder mehreren Krankenakten enthalten und mehrere Behandlungsepisoden zusammenfassen. Es soll weitgehend unabhängig von technischen Infrastrukturen und Diensten eingesetzt werden können. Alle Informationen sollen auch maschinenlesbar (codiert) eingebettet werden können.  Dieser Leitfaden beschränkt sich auf das Endprodukt: das Dokument "Patient Summary" selbst mit seinen Inhalten. Die Frage der Erzeugung, wer oder was ein Patient Summary mit welchen Hilfsmitteln oder Algorithmen erstellt, wurde bewusst weitgehend ausgeklammert. === Darstellung===Dieser Leitfaden definiert ein CDA-Dokument, das mit den gängigen CDA-Stylesheets in HTML konvertiert und in einem Browser dargestellt werden kann. Eine optimierte Darstellung erfolgt - wie für alle CDA-Dokumente, die auf dem [[ILF:Allgemeiner_Implementierungsleitfaden|Allgemeinen Implementierungsleitfaden]] beruhen - mit dem [[ELGA Referenz-Stylesheet]]. Für den Ausdruck wird eine PDF-Konvertierung mit der [[ELGA CDA2PDF-Suite]] empfohlen.''Zukünftig kann ein alternatives Stylesheet notwendig werden, das speziell auf mehrsprachige und/oder durchgängig codierte Patient Summaries zugeschnitten ist.'' ===Verwendung in ELGA ===Das Patient Summary ist ein Dokument, das über ELGA verfügbar gemacht werden kann. Es ist möglich, Patient Summary Dokumente über ELGA abzurufen.====Versionierung====Es gibt immer immer nur ''eine'' gültige - aktuelle - Version eines Patient Summary. Durch die Erstellung einer neuen Version des Patient Summary wird die davor erstellte Version obsolet, unabhängig vom Ersteller der jeweiligen Versionen oder vom verwendeten Mechanismus der Erstellung (software-assembled oder human-curated). ''Die technische Abbildung dieser Vorgabe ist noch zu klären.'' === Mehrsprachigkeit und grenzüberschreitender Austausch ===Das österreichische Patient Summary wird grundsätzlich in deutscher Sprache erstellt. Es ist möglich, den Inhalt zusätzlich in weiteren Sprachen im Dokument anzugeben. Dokumente mit durchgängig maschinenlesbaren Inhalten können prinzipiell auch automatisiert übersetzt werden. Das Patient Summary soll auch für den grenzüberschreitenden Austausch von Gesundheitsdaten eingesetzt werden können. ==Anwendungsfälle==Da die Anwendungsfälle mit der technischen Umsetzung und der Erstellung eines Patient Summary Dokumentes zusammenhängen, sind die angegebenen Anwendungsfälle daher als Vorschlag zu sehen. ===Lesender Zugriff===Der Hauptanwendungsfall für das Patient Summary sind alle Situationen, in denen eine Statuserhebung des Gesundheitszustandes eines Patienten erforderlich ist. Das betrifft primär den Erstkontakt, grundsätzlich aber jede Konsultation eines GDA (stationär/ambulant, geplant und ungeplant, präoperativer Anästhesiecheck etc.), auch Notfallaufnahmen und das Notarztwesen; ebenso in der grenzüberschreitenden Gesundheitsversorgung.  Zugriff auf das Patient Summary sollen alle behandelnden Ärzte und Ärztinnen entsprechend ihrer Berechtigung in ELGA haben. Auch andere „gehobene Gesundheitsberufe“ (z.B. gehobener Dienst für Gesundheits- und Krankenpflege) sollten Zugriff erhalten. Es ist möglich, Inhalte des Patient Summaries zu extrahieren und in Krankenakten zu übernehmen. Teile des Patient Summaries können in EHR-S (elektronischen Krankenakten, z.B. Krankenhaus- oder Arztpraxis-Informationssysteme) integriert und dargestellt werden.  ===Erstellung (schreibender Zugriff)=== Ein Patient Summary kann jederzeit erstellt werden, unabhängig vom aktuellen Zustand der Person oder von einem eventuellen Behandlungsverlauf. Es kann von einer Person editiert und freigegeben oder von einer Software automatisch zusammengestellt werden. Für die Vertrauenswürdigkeit und Verlässlichkeit eines Patient Summary-Dokuments ist das ein substanzieller Unterschied. Damit diese wichtige Kontextinformation für den Empfänger transparent wird, wird wie folgt differenziert:  ====Erstellung durch einen GDA===="''human-curated''" Die Erstellung erfolgt durch einen GDA (Arzt), wobei die Inhalte bereits von einem System (Krankenhaus- oder Arztpraxis-Informationssystem) vorgeschlagen werden und vom Arzt nachbearbeitet und ergänzt werden können. Der Arzt scheint als rechtlicher Unterzeichner des Patient Summary auf. --> "''Patient Summary''". ====Erstellung durch eine Software===="''software-assembled''" Die Erstellung erfolgt vollautomatisch und regelbasiert anhand der in ELGA oder in einer oder mehreren anderen (lokalen) elektronischen Krankenakten verfügbaren Informationen. "''(Automatische) Patientenübersicht" / "(ELGA) Quick View''". Der Titel eines ausschließlich aus ELGA-Daten automatisiert durch Software erstellten Dokuments muss "''Automatische ELGA-Übersicht''" lauten.Die unterschiedlichen Erstellungsarten sollen bereits in den Metadaten des Dokuments und in der XDS-Registry klar erkennbar sein. Zuvor 'human-curated' erstellte Patient Summary Versionen können und sollen ebenfalls als Quelle für ein 'software-assembled' Patient Summary herangezogen werden. Idealerweise werden die Prämissen und Regeln für eine automatische Zusammenstellung transparent und nachvollziehbar gemacht.  Vorgeschlagener Hinweistext für eine "Automatische ELGA-Übersicht": :<small>Die ''Automatische ELGA-Übersicht'' ist eine Orientierungshilfe in ELGA und bietet einen Überblick über jene Gesundheitsdaten, die zum Zeitpunkt der Erstellung der Übersicht verfügbar waren. Für diese automatisch von einem Computerprogramm zusammengestellte Übersicht wurden bereits vorliegende Einzelinformationen (maschinenlesbare Elemente, codierte Daten) aus verschiedenen Quellen (eBefunde, eMedikation etc) übernommen. Es kann daher nicht garantiert werden, dass alle relevanten Gesundheitsinformationen enthalten sind. ::Die ELGA-Übersicht ist ''kein Medizinprodukt''. Die Verwendung erfolgt auf eigene Gefahr.::Die folgenden, beispielhaft aufgezählten diagnostischen oder therapeutischen Handlungen erfolgen in alleiniger Verantwortung der jeweiligen Behandler/innen: :* Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten,:* Erkennung, Überwachung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinderungen,:* Untersuchung, Veränderung von oder Verordnung von Behelfen zum Ersatz des anatomischen Aufbaus oder physiologischer Vorgänge :* Maßnahmen zur Empfängnisregelung</small> =Grundsätze und Regeln===Allgemeines== Dieses Dokument spezifiziert eine HL7 CDA R2 Implementierung, ist aber in den Grundzügen kompatibel mit dem in Entwicklung befindlichen FHIR-Standard. In einigen Fällen folgt es eher der FHIR Stilistik, um Konzepte zu repräsentieren und weicht daher von der in CDA bzw HL7 Version 3 üblichen Art ab. Das betrifft hauptsächlich die Mechanismen für Negation, unbekannte und fehlende Informationen (NullFlavors). Um grenzüberschreitend austauschbar und verständlich zu sein, muss das Patient Summary so weit wie möglich auf strukturierte Daten und mehrsprachige internationale Referenzterminologien stützen, die für das Patient Summary ohne Kosten für die globale Nutzung lizenziert werden. Im Falle von SNOMED CT wird erwartet, dass die IHTSDO (SNOMED International) und die Republik Österreich, vertreten durch das Bundesministerium für Gesundheit und Frauen, eine Vereinbarung treffen werden, um den Einsatz von SNOMED CT für den Einsatz in Österreich zu ermöglichen. In diesem Sinne wird SNOMED CT als bevorzugte Terminologie und für die Mehrheit der Wertmengen (Value Sets) verwendet.  Andere bevorzugte Terminologien, die in dieser Spezifikation verwendet werden, sind LOINC für Beobachtungen (z.B. Labortests) und Dokumentabschnitte (Sections), UCUM für Maßeinheiten und EDQM für Dosisformen und Einnahmearten.  Diese Spezifikation verwendet das HL7-Template-Austauschformat [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=377] <!-- HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 --> und ART-DECOR® [www.art-decor.org] als Spezifikationsplattform. Nutzer dieses Leitfadens können die IPS-Projektseite in ART-DECOR® besuchen, um die Template-Spezifikationen zu durchsuchen und Beispiele zu überprüfen. ==Annahmen==Dieser Implementierungsleitfaden wurde von der Arbeitsgruppe unter folgenden Annahmen erstellt: * Der Leitfaden spezifiziert das "Endprodukt", ein Patient Summary Dokument, das in Österreich allgemein und speziell in ELGA verwendet werden kann und alle Daten und Strukturen enthält, um es auch für den grenzüberschreitenden Austausch von Gesundheitsdaten zu nutzen. * Die Erstellung des Patient Summary Dokuments wurde bewusst weitgehend ausgeklammert.* Fragen der Finanzierung der Umsetzung wurden nicht betrachtet.* Das Patient Summary definiert eine Struktur, die notwendig ist, um Daten elektronisch und automatisch in anderen GDA-IT-Systemen weiterzuverarbeiten, zu aggregieren und zu übersetzen. Die Arbeitsgruppe hat die Vorgaben im Bewusstsein definiert, dass die notwendigen Quelldaten nicht immer vorliegen, und wenn sie vorliegen, nicht immer in der erforderlichen Struktur und Detailgenauigkeit. Das Patient Summary dient als "Leuchtturm", um künftige Dokumentationen entsprechend diesem Mindeststandard anzupassen.* Der Leitfaden bezieht sich auf die allgemeinen ELGA-Richtlinien für Dokumente (Allgemeiner CDA-Implementierungsleitfaden). Damit werden die Mechanismen für den Austausch, das Dokumentenmanagement und die Darstellung definiert. * Der Leitfaden nutzt soweit möglich bereits in anderen Leitfäden definierte strukturierte Inhaltselemente ("Templates")* Die in diesem Leitfaden definierten Templates sollen baugleich in anderen Dokumenten verwendet werden.* Die Templates werden in Art-Decor unter Nutzung des internationalen Template Standards modelliert, Prüfregeln ("Schematron") können direkt aus Art-Decor abgeleitet werden. ==Umgang mit codierten Informationen und Terminologien=====Codierte Information===Eine Prämisse des Patient Summary-Leitfadens ist eine durchgängige Maschinenlesbarkeit der einzelnen medizinischen Informationen. Dazu ist es notwendig, die Informationen mit codierten Konzepten auszudrücken ("Codierung"). Codierte Informationen erlauben eine Übersetzung in andere Sprachen ("Translation") und eine Überführung in andere Terminologien oder Codesysteme ("Transcodierung").Die Datentypen für codierte Informationen werden in [[elga-cdapscdaalf-2.06.2:Funktionale Anforderungen Datentypen#Codierungs-Elemente| Allgemeiner Leitfaden: Codierte Elemente]] beschrieben. Wenn die erwünschten Informationen nicht vorliegen oder nicht mit codierten Konzepten ausgedrückt werden können, kommen die im Folgenden vorgestellten Methoden zum Einsatz. ===Unbekannte und keine Information===Nicht immer können für bestimmte erwünschte Inhalte (Erkrankungen, Zustände, Eigenschaften, etc.) auch tatsächlich Angaben gemacht werden. Der Leitfaden unterscheidet dabei zwischen zwei Situationen: * Der erwünschte Inhalt ist unbekannt (z.B. wenn die Medikation eines Patienten unbekannt ist)* Der erwünschte Inhalt liegt bekanntlich nicht vor (z.B. wenn der Patient tatsächlich keine Medikamente einnimmt)Spezifischere Formen abwesender Information oder Negation wurden nicht als relevant erachtet, wie zum Beispiel die Abwesenheit einer Allergie auf ein bestimmtes Antigen, der Ausschluss einer bestimmten Krankheit oder die Tatsache, dass eine bestimmte Impfung nicht durchgeführt wurde. Für die semantische Repräsentation dieser Situationen werden SNOMED-CT-Codes verwendet; die sonst in CDA üblichen Mechanismen (nullFlavor, negationInd) werden hier weitgehend vermieden. So sollen die Inhalte unabhängig von einem bestimmten technischen Standard ausgedrückt werden, die Implementierungen robuster und einfacher gemacht sowie die Transformation in andere Standards wie z.B. FHIR erleichtert werden. In einigen Fällen fehlen zum Zeitpunkt der Erstellung des Leitfadens die benötigten SNOMED-CT-Konzepte, z. B. "Allergische Disposition nicht bekannt (Situation)". Diese Konzepte wurden bereits beantragt und harren der Aufnahme in eine zukünftige Version von SNOMED CT International Edition. Zwischenzeitlich werden diese Konzepte durch temporäre Platzhalter-Codes dargestellt, die alle mit 'X-' beginnen (z.B. X-AllergicDispositionNotKnown). ====Darstellung von unbekannter und bekannt fehlender Information im Text==== Unbekannte und fehlende Information soll auch im menschenlesbaren Text (section.text) einheitlich dargestellt werden. Folgende Textbausteine sind VERPFLICHTEND zu verwenden: * '''Es liegt keine Information über [X] vor''' (Bedeutung: die Informationen über [X] wurden nicht erhoben, können nicht erhoben werden oder sind nicht verfügbar)* '''Keine [X]''' (Bedeutung: Es gibt tatsächlich keine Informationen über [X] oder [X] liegt nachweislich nicht vor.) ======Anwendungsbeispiele======Es liegt keine Information über Allergien oder Intoleranzen vor:<br /> [[Datei:Textbaustein Es liegt keine Information vor.png|Es liegt keine Information über Allergien oder Intoleranzen vor]]<br />Es wurden keine Impfungen durchgeführt:<br />[[Datei:Textbaustein Keine.png|Es wurden keine Impfungen durchgeführt]] ======Codebeispiel für den lesbaren Text======Tabellarische Darstellung gilt auch für unbekannte und fehlende Informationen, zusätzlich soll die Nicht-Information optisch hervorgehoben werden (Stylecode). <pre class="orange"> <title>Allergien und Intoleranzen</title> <text> <table> <tbody> <tr ID="al-1"> <td> <content styleCode="xELGA_blue">Es liegt keine Information über Allergien oder Intoleranzen vor</content> </td> </tr> </tbody> </table> </text></pre> ===Uncodierte Information===Bei der Erstellung des Dokumentes können möglicherweise bestimmte Informationen vorliegen, die nicht codiert werden können, weil# die Information nicht mit den im Leitfaden zugelassenen Terminologien (Value Sets) dargestellt werden kann oder# die Information in keiner bekannten Terminologie enthalten ist, beziehungsweise der Inhalt nicht codiert wurde. Diese erste Situation wird mit dem folgenden Beispiel verdeutlicht.  <pre class="orange"><code codeSystem="1.2.40.0.34.5.174" nullFlavor="OTH"> <originalText> <reference value="#ref1"/> </originalText></code></pre>Für die Information ist kein geeigneter Code im vorgegebenen Codesystem vorhanden (im Beispiel ICD-10 BMGF 2018). Der konkrete Inhalt wird im Section-Text angegeben und vom Code-Element nur referenziert (value im reference-Element). Diese Variante kann für ''coding strength'' CNE (coded no extensions) eingesetzt werden. Der Elementname kann auch anders sein, zB Value. Hinweis: Mit den zugrunde liegenden Datentypen (HL7 V3 Data Types R1) kann nicht angegeben werden, dass Codes zwar im Codesystem, aber nicht im referenzierten Value Set verfügbar sind. Spätere Versionen dieses Leitfadens können gegebenenfalls auf Data Types R2 aufbauen, um diese Angabe zu unterstützen.  Das folgende Beispiel bezieht sich auf die zweite Situation: <pre class="orange"><value xsi:type="CD" nullFlavor="NI"> <originalText> <reference value="#ref1"/> </originalText></value></pre> Im zweiten Beispiel wird der allgemeinste NullFlavor "NI" (No Information) verwendet; es gilt sowohl für ''coding strength'' CNE (coded no extensions) and CWE (coded with extensions). Wie im ersten Beispiel wird der konkrete Inhalt im Section-Text angegeben und vom Code-Element nur referenziert (value im reference-Element).  Die zweite Variante ist die häufiger eingesetzte Variante. Hinweis: Der geeignetste NullFlavor wäre eigentlich "UNC" (Uncoded), aber dieser NullFlavor ist in der RIM-Version, auf der HL7 CDA Rel.2 aufbaut, nicht verfügbar. Daher muss der allgemeinere NullFlavor "NI" (No Information) verwendet werden. ===Nicht zugeordnete codierte Information===Bei der Erstellung des Dokumentes können möglicherweise bestimmte Informationen codiert in der Quelldokumentation vorliegen, aber die Codes sind nicht in den im Leitfaden zugelassenen Terminologien (Value Sets) verfügbar. Wenn das codierte Element mit de ''coding strength'' CNE (coded no extensions) angegeben ist, wird der nullFlavor "OTH" verwendet; bei ''coding strength'' CWE (coded with extensions) der nullFlavor "NI".   <pre class="orange"><value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor="OTH"> [ <originalText> <reference value="#ref1"/> </originalText> ] <translation code="A02.9" codeSystem="1.2.40.0.34.5.174" displayName="Salmonelleninfektion, nicht näher bezeichnet"/></value></pre>Die eckigen Klammern deuten an, dass Elemente optional sind.Hinweis: Mit den zugrunde liegenden Datentpyen (HL7 V3 Data Types R1) kann nicht angegeben werden, dass Codes zwar im Codesystem, aber nicht im referenzierten Value Set verfügbar sind. Spätere Versionen dieses Leitfadens können gegebenenfalls auf Data Types R2 aufbauen, um diese Angabe zu unterstützen. Im Falle der ''coding strength'' CWE (coded with extensions) wird der nullFlavor "NI" vorgeschlagen und ebenso die Angabe des korrekten Codes im <translation>-Teilelement. Dies ermöglicht die Angabe, dass eine Zuordnung zu dem Referenz-Value Set versucht wurde, aber keine geeigneten Zielcodes identifiziert wurden. <pre class="orange"><value xsi:type="CD" codeSystem="2.16.840.1.113883.6.96" nullFlavor="NI"> [ <originalText> <reference value="#ref1"/> </originalText> ] <translation code="A02.9" codeSystem="1.2.40.0.34.5.174" displayName="Salmonelleninfektion, nicht näher bezeichnet"/></value></pre>Die eckigen Klammern deuten an, dass Elemente optional sind. ===Zugeordnete codierte Information (Übersetzung)===Es kann vorkommen, dass bestimmte Informationen codiert in der Quelldokumentation vorliegen, aber in einer anderen Terminologie als vom Leitfaden zugelassen. Wenn die codierten Konzepte korrekt von der einen in die andere Terminologie zugeordnet werden können (also "übersetzt" oder "gemappt"), ist es erlaubt, auch die originalen Codes zusätzlich anzugeben.  1. Fall: Ein einzelner lokaler Code wird auf einen Code im Referenz-Value Set gemappt <pre class="orange"><value xsi:type="CD" code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella gastroenteritis"> [ <originalText> <reference value="#ref1"/> </originalText> ] <translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/></value></pre> Die eckigen Klammern deuten an, dass Elemente optional sind.  2. Fall: Mehrere lokale Codes werden auf das Referenz-Value Set gemappt <pre class="orange"><value xsi:type="CD" code="C50.9" codeSystem="1.2.40.0.34.5.171" codeSystemName="ICD-10 BMGF" displayName="Bösartige Neubildung: Brustdrüse, nicht näher bezeichnet"> [ <originalText> <reference value="#problem4name"/> </originalText> ] <translation code="code-example" codeSystem="1.999.999" codeSystemName="this is only an example" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2"> <translation code="174.9" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" displayName="Malignant neoplasm of breast (female), unspecified"/> <translation code="C50.919" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM" displayName="Malignant neoplasm of unspecified site of unspecified female breast"/> </translation> <translation code="422479008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="FEMALE BREAST INFILTRATING DUCTAL CARCINOMA, STAGE 2"/> </translation></value></pre>Die eckigen Klammern deuten an, dass Elemente optional sind.  3. Fall: Ein lokaler Code entstammt derselben Terminologie wie das Referenz-Value Set, besitzt aber eine unterschiedliche Granularität. <pre class="orange"><code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary"> <translation code="60592-3" codeSystem="2.16.840.1.113883.6.1" displayName="Patient summary unexpected contact"/></code></pre> Hinweis: Die R1 Datentyp-Definition versteht die <translation> nur als Mapping zwischen unterschiedlichen Codesystemen ("a set of other concept descriptors that translate this concept descriptor into other code systems"). Es hat sich aber die Interpretation durchgesetzt, dass auch dasselbe Konzept in mehreren Repräsentationen ausgedrückt werden kann, wie es einige Codesysteme (z.B. SNOMED CT erlauben). ==Mehrsprachigkeit==Codierte Informationen können einfach in unterschiedlichen Sprachen ausgedrückt werden. Für einen zuverlässigen und sicheren grenzüberschreitenden Datenaustausch ([http://ec.europa.eu/health/ehealth/policy/network_en EU eHealth Network]) ist dies eine funktionelle Notwendigkeit.  Der zugrunde liegende Standard HL7 CDA Rel. 2 hat mit Bordmitteln keine Möglichkeit, um einen Anzeigetext zu einem codierten Konzept in mehreren Sprachen anzugeben. Dieser Leitfaden übernimmt daher als optionales Element die Erweiterung (extension) 'ips:designation', die im HL7 IPS Leitfaden dafür vorgeschlagen wird.  Beispiel 1: Ohne Code-Mapping <pre class="orange"><code code="60591-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Patient Summary"> <ips:designation lang="it-IT" value="Profilo Sanitario Sintetico"/> <ips:designation lang="fr-FR" value="Patient Summary"/> <ips:designation lang="en" value="Patient Summary"/></code></pre> Beispiel 1: Mit Code-Mapping<pre class="orange"><value xsi:type="CD" code="42338000" codeSystem="2.16.840.1.113883.6.96" displayName="Salmonella-gastroenteritis"> <ips:designation lang="da-DK" value=" Salmonella-gastroenteritis"/> <ips:designation lang="en" value="Salmonella gastroenteritis (disorder)" type="FSN"/> [ <originalText> <reference value="#ref1"/> </originalText> ] <translation code="003.0" codeSystem="2.16.840.1.113883.6.103" displayName="Gastroenterite da Salmonella"/></value></pre>Die eckigen Klammern deuten an, dass Elemente optional sind. ====Übersetzung des narrativen Textes====Bei einer Übersetzung eines Dokuments muss vor allem der lesbare Text in anderen Sprachen dargestellt werden können. Die Übersetzung muss dazu bereits im Dokument vorhanden sein, wobei die Übersetzung von einer Person durchgeführt werden kann oder aber automatisch aus den maschinenlesbaren Elementen abgeleitet werden kann. Bei der Darstellung muss (a) die Sprache der Ausgabe identifiziert werden und (b) angegeben werden, ob es sich um das Original handelt oder die Übersetzung. Außerdem sollte die Quelle (Freitext, maschinenlesbare Elemente) und Art der Übersetzung (Übersetzer, automatisch, etc.) angegeben werden.  Die hier verwendete Methode enthält das Original im <text>-Element der Section und die optionalen Übersetzungen in einem <text>-Element einer Subsection, wobei pro Übersetzung eine Subsection angegeben wird. (specified in template 2.16.840.1.113883.10.22.3.15) Beispiel:<pre class="orange"><section> <templateId root="2.16.840.1.113883.3.1937.777.13.10.5"/> <id root="..." extension="..."/> <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/> <title>Allergies and Intolerances</title> <text>No known Allergies</text> <!-- omissions --> <component> <section> <!-- subordinate section carrying a translation of the parent section --> <title>Allergie ed Intolleranze</title> <text>Nessuna Allergia Nota</text> <languageCode code="it-IT"/> </section> </component></section></pre> ==Herkunft der Information==Die Angabe der Quelle einer Information kann für die klinische Bewertung dieser Information maßgeblich sein, besonders wenn ein Dokument aus mehreren Quellen (automatisch) zusammengestellt wurde. Daher erlaubt dieser Leitfaden eine systematische und durchgängige Angabe der Herkunft der elektronischen Daten.  ===Herkunftsangabe auf Dokument-Ebene===Der '''Autor''' des Patient Summary-Dokuments MUSS verpflichtend im Header angegeben werden. Dabei kann es sich um eine Person ("human curated") oder um eine Software ("software assembled") handeln. ===Herkunftsangabe auf Section-Ebene===Für jeden Dokumentationsabschnitt (Section) können jeweils mehrere Autoren und Informanten angegeben werden. Da die Zuordnung der Einzelinformation bei Angabe mehrerer Autoren und Informanten uneindeutig ist, wird empfohlen, die Herkunft auf Entry-Ebene anzugeben. * Autor (Gesundheits-Fachperson, die die Information erstellt hat mit Name und Organisation). * Informant (Person, auf deren Angabe die Information beruht: der Patient selbst oder eine dem Patienten verwandte oder bekannte Person)===Herkunftsangabe auf Entry-Ebene===* Autor (Gesundheits-Fachperson, die die Information erstellt hat mit Name und Anwendungsfälle}}Organisation)* Informant (Person, auf deren Angabe die Information beruht: der Patient selbst oder eine dem Patienten verwandte oder bekannte Person)* Dokumentverweis (externalDocument): für jedes Entry kann eine ID angegeben werden, die auf ein externes Dokument verweist, aus dem die Information stammt. ==Zeitangaben== {{Gemäß [[elga-cdapscdaalf-2.06.2:Grundsätze_und_Regeln}}Datentypen#Zeit-Elemente|Allgemeinem CDA-Leitfaden]] dürfen Zeitpunkte nur auf zweierlei Arten angegeben werden: * '''Datum''' im Format '''YYYYMMDD'''* '''Datum und Uhrzeit mit Zeitzone''' im Format '''YYYYMMDDhhmmss[+/-]HHMM''' Ist nur eine eine weniger genaue Zeitangabe verfügbar, sind die fehlenden Stellen mit der Ziffer Null aufzufüllen. Also zum Beispiel ist für "September 2017" die Zeichenfolge 20170900 anzugeben. Die HL7 V3 Datentypen interpretieren Datumswerte so, als ob alle möglichen, aber nicht angegebenen Stellen mit 0 befüllt wären.  Achtung bei Zeitintervallen: Ein Datum, das mit yyyymmdd angegeben wurde, wird standardgemäß interpretiert als yyyymmdd000000 – also der Tag um 0:00:00 Uhr. Wenn also als Zeitraum z.B.: der ganze 1. Dezember 2017 angegeben werden soll, MUSS das so erfolgen:  <pre class="orange"> <low value="20171201"/> <high value="20171202"/></pre> Für mehr Klarheit empfiehlt sich daher die zusätzliche Angabe der Zeit mit Zeitzone:<pre class="orange"> <low value="20171201000000+0100"/> <high value="20171201235959+0100"/></pre>