Ultrakurzformat Patientenbezogener Medikationsplan

Addendum zum Implementierungsleitfaden Patientenbezogener Medikationsplan: Ultrakurzformat (UKF) für kapazitätslimitierte Datenträger

Ultrakurzformat Patientenbezogener Medikationsplan

Implementierungsleitfaden

vorgelegt von:
HL7 Deutschland
Dr. Kai U. Heitmann

Entwurf

Version:	0.91
Datum:	22. Januar 2016
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2016: HL7 Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
0.91	22.01.2016	Entwurf	Deutschland
		noch kein download verfügbar

Einleitung

Vom 1. Oktober 2016 muss jedes Arztpraxissystem im Prinzip einen Medikationsplan in Papierform an die Patienten aushändigen können. Im Vorfeld sind die Vorgaben des Medikationsplans der Arzneimittelkommission der deutschen Ärzteschaft (AkdÄ) erstellt worden, die allerdings nicht nur die fachinhaltlichen Aspekte enthält („was muss der Medikationsplan enthalten“), sondern auch ein proprietäres Format, das eigens hierfür entworfen wurde. Dieses proprietäre Format soll in einem Barcode niedergelegt werden, der mit auf dem Papierausdruck aufgebracht wird.

Während die Definitionen zum Fachinhalt das Ergebnis eines langen Abstimmungs- und Konsensusprozesses ist und als eine zurzeit am breitesten getragene Angabe zu den Fachinhalten eines Mediaktionsplans gilt, ist das Barcode-Format proprietär.

Aus diesen Gründen wurde unter anderem im NRW-Projekt vom technischen Teil abgesehen und der Vorläufer des hier vorgestellten Ultrakurzformats in XML bzw. JSON entwickelt. Das hier vorgestellte Ultrakurzformat beruht auf Standards und stellt eine Alternative zum AkdÄ-Barcode-Format dar.

Patientenbezogener Medikationsplan

Der Patientenbezogene Medikationsplan (PMP) ist eine Spezifikation auf XML-Basis (siehe folgender Abschnitt) und kann sowohl die Fachinhalte des AkdÄ-Medikationsplans als auch anderer Medikationspläne wiedergeben. Er stellt eine umfassende Aufzeichnung der Medikamente des Patienten (Verordnungen, nicht verschreibungspflichtige Medikamente, Kräuterprodukte, Nahrungsergänzungsmittel und andere) für den Patienten dar. Der PMP soll für die Patienten eine Hilfestellung bei der Einnahme ihrer Medikation darstellen.

Spezifikation „Patientenbezogener Medikationsplan“ auf der Basis der Clinical Document Architecture

Zur vereinheitlichten elektronischen Wiedergabe und Speicherung derartiger Medikationspläne liegt die offizielle Fassung im HL7 Clinical Document Architecture Format (ISO/HL7 27932:2009) vor und wurde im Rahmen des Interoperabilitätsforums abgestimmt. Mit dem Leitfaden wird ein weiterer Beitrag zur Verbesserung der Arzneimitteltherapiesicherheit und der intersektoralen und interprofessionalen Kommunikation geleistet.

Die Vorgaben des Medikationsplans der Arzneimittelkommission der deutschen Ärzteschaft (AkdÄ) Version 2.0 sind dabei als ein führender Ausgangspunkt gewählt. Wie erwähnt, lassen sich mit der hier vorliegenden Spezifikation grundsätzlich darüber hinaus auch andere Medikationspläne abbilden, wie sie hierzulande beispielweise an verschiedenen Standorten in Erprobung oder Routine befindlich sind.

Auch andere Vorarbeiten sind in die Ausarbeitung mit eingeflossen, nationale wie zum Beispiel die Spezifikationen zum Elektronischen Arztbrief (VHitG, jetzt bvitg und Neuauflage 2014, Ergänzungen 2016) oder die der Deutschen Krankenhausgesellschaft e.V. (DKG), aber auch internationale Ausarbeitungen wie einschlägige IHE-Profile, Arbeiten aus dem österreichischen ELGA-Umfeld und dem epSOS-/EXPAND-Projekt. Der Leitfaden ist seinerzeit im Rahmen eines Projektes der Ärztekammern in Nordrhein-Westfalen initiiert worden.

Kurzformat und Ultrakurzformat

Aus den in der Einleitung genannten Ausführungen wurde und wird in NRW ein Ansatz auf Basis eines XML-Formats (Spezifikation „PMP“ auf der Basis der Clinical Document Architecture) verfolgt, der auf internationalen Standards basiert. Medikationspläne, die hierauf beruhen, können über eine Transformation in ein so genanntes Kurzformat bzw. Ultrakurzformat (beide jeweils auf XML oder JSON Basis) überführt werden (und umgekehrt). Beide sind wiederum für Datenträger mit geringer Kapazität wie zum Beispiel Barcode, aber auch die eGK oder im Umfeld Mobiler Apps (Bandbreitenproblematik) geeignet.

Die Vorarbeiten sind im NRW-Projekt in 2014 zusammen mit dem Ministerium für Gesundheit, Emanzipation, Pflege und Alter des Landes Nordrhein-Westfalen (MGEPA), den Ärztekammern Nordrhein und Westfalen-Lippe und HL7 beschritten und ausgeführt worden. Das Resultat ist für KIS und PVS Systeme und auch für Ansätze im Bereich der Mobile Apps geeignet und fußt auf internationalen IT-Standards.

Sowohl das CDA-Format als auch das Kurzformat bzw. Ultrakurzformat sollen im von EFRE geförderten NRW Projekt „Medikationplan 2.0plus“ im Echtbetrieb weiter getestet werden. Ein offizielles und transparentes Abstimmungsverfahren zum Kurzformat bzw. Ultrakurzformat ist – wie zuvor auch für das CDA-Format – in Planung.

Das Kurzformat ist auf dem FHIR-Standard basiert, der im folgenden Kapitel näher beschrieben wird. In Bezug auf den Medikationplan ist die hier beschriebene Zusammenstellung er Komponenten das Äquivalent zum CDA-Format und wird seine Anwendung vornehmlich im Bereich der Mobilen Apps finden.

Das Ultrakurzformat ist direkt davon abgeleitet und nicht nur für den Barcode, sondern auch für die eGK nutzbar. Damit ist es möglich bis zu 40 Arzneimittel auf der eGK zu speichern, womit auch die AMTS-Anwendungsfälle für zum Beispiel bisherige nicht mehr aktuell eingenommene bzw. abgesetzte Medikamente oder jedenfalls nicht einzunehmende Substanzen (zum Beispiel wegen Unverträglichkeiten oder Allergien) abgedeckt werden können. Gerade letztgenannter Aspekt ist auch vom Gesetzgeber rechtzeitig erkannt worden und eine Forderung des im Dezember 2015 verabschiedeten „eHealth-Gesetzes“.

Seit Veröffentlichung des „Bundesmedikationsplanes der AkdÄ“ sind diverse weitere, untereinander nicht kompatible Ansätze zur elektronischen Wiedergabe des Medikationsplans entstanden. Der Ansatz aus NRW basiert auf internationalen Standards, zielt auf den Einsatz im ambulanten und stationären Bereich inklusive neuerer und Mobiler Anwendungen ab und stellt das Thema „Medikation“ auch für andere Gesundheits-Anwendungen als den reinen Medikationsplan oder AMTS zur Verfügung. Die Abbildungen zum Thema „Medikation“ sind über Anwendungsgrenzen hinweg isomorph, von Struktur und Semantik gleich, ohne dabei starr zu sein. Damit ist die Kompatibilität mit dem Arztbrief, den Notfalldaten oder (später) einer Patientenakte gegeben, ebenso beispielsweise Anwendungen wie Notaufnahmeprotokoll der DIVI, Überweisungs- und Einweisungsdokumente, Überleitungsmanagement usw.

Technische Spezifikation zum Kurzformat und Ultrakurzformat

Basisstandard FHIR

Das Ultrakurzformat basiert auf „FHIR“® (Fast Healthcare Interoperability Resources, ausgesprochen wie englisch fire).

Der neue Standard „FHIR“® wurde von Health Level Seven International (HL7) ins Leben gerufen. FHIR unterstützt den Datenaustausch zwischen Softwaresystemen im Gesundheitswesen. Er vereinigt die Vorteile der etablierten HL7-Standard-Produktlinien Version 2, Version 3 und CDA mit jenen aktueller Web-Standards und legt einen starken Fokus auf eine einfache Implementierbarkeit.

Die Entwicklung von FHIR wurde auch getrieben von den Anforderungen, Daten auch einrichtungs- und sektorübergreifend kommunizieren zu können, sowie mobile und cloud-basierte Anwendungen zu unterstützen. Die Methoden und Werkzeuge bei FHIR erlauben Interoperabilität innerhalb von Tagen und Wochen statt Monaten und Jahren herstellen zu können.

FHIR ist agil, unterstützt mobile Architekturen und verbindet Patienten ortsunabhängig mit ihren Daten um so dem Trend von Desktop zu Tablet, Software zu App, Patienten- zu Gesundheitsakte und Server zu Cloud Rechnung zu tragen.

Der FHIR-Standard setzt sich aus den Bausteinen „Resources“, „Referenzen“ und „Profilen“ zusammen.

Resources sind kompakte, logisch diskrete Einheiten des Datenaustausches mit einem wohldefiniertem Verhalten und eindeutiger Semantik. Sie sind die kleinste Einheit der Übermittlung.

Resources können mit Hilfe von Links auf andere Resources verweisen (Referenzen). Dadurch verknüpfen sich die Informationseinheiten zu einem Netzwerk, das beispielsweise eine Medikamenten-Verordnung, einen Labor-Befund oder gar vollständige Patientenakte abbilden kann.

Die Kombination von Resources unterliegt keinen Beschränkungen. Wie einzelne Systeme Resources verwenden und kombinieren, wird in Profilen definiert. Profile sind das Regelwerk für die Definition eines Services. Sie erklären, welche Resources und Extensions ein System kommunizieren und speichern kann.

Bezug des Ultrakurzformats zum Basisstandard FHIR

Das Ultrakurzformat (UKF) basiert auf FHIR und den dort definierten Resources/Profilen wie zum Beispiel Patient, AllergyIntolerance und MedicationStatement. Dabei wurden die üblichen Aspekte und Freiheiten in den Resources für das Kurzformat eingeschränkt und vorab in den UKF-FHIR-Profilen festgelegt, dass die eigentlichen Instanzen („die Daten“) außerordentlich gehalten werden können.

Das Ultrakurzformat reduziert dann von den FHIR-Profil-Definitionen ausgehend schließlich auf sehr kurze XML-Elemente und -Attribute, die in einer eins-zu-eins Beziehung zum zugrundeliegenden FHIR-Profil stehen. Dadurch können FHIR-Instanzen, die nach den UKF-FHIR-Profilen erstellt sind und die Ultrakurzformat-Instanzen leicht ineinander überführt werden.

Als Beispiel sei hier genannt, dass man bei der Übermittlung von Codes immer mit angeben muss, aus welchem Codesystem der Code entnommen wurde. Anders ließe sich der Code nicht korrekt interpretieren. Wird nun vorab (im UKF-FHIR-Profil) festgelegt, dass an bestimmten Stellen nur Codes aus ganz bestimmten Codesystemen zur Anwendung kommen dürfen, erübrigt sich die Mitlieferung des Codesystems in der Instanz selbst (so genannte „kurze Terminologiebindung“).

Ähnliches gilt für bestimmte Dosierungsmuster die festliegen. Die Angabe „morgens“ bedeutet an sich „Medikament morgens einnehmen („wann“) und dies jeden Tag wiederholen („repeat, period 1 d). Diese Statements können sich auf das „Wann“ beschränken, denn dass sich dies (innerhalb ggf. vorgegebener Einnahmedauer-Grenzen) täglich wiederholt ist bei diesem Muster klar.

Das bedeutet auch, dass Instanzen im Ultrakurzformat aufgrund der Einheit von Instanz und UKF-FHIR-Profil nur durch die langen Strukturen und die im Profil definierten Festlegungen ergänzt werden müssen, um auch außerhalb der Spezifikation des Ultrakurzformats vollwertig gemäß dem allgemeinen FHIR-Profil für den Medikationsplan zu sein (vgl. auch folgende Tabelle).

Vollwertige und übliche FHIR Beispiele zum normalen Gebrauch in FHIR-Anwendungen	Beispiel Ultrakurzformat mit sehr kurzen XML-Elementen und -Attributen
<section> <title value="Allergien und Unverträglichkeiten"/> <code> <coding> <system value="http://loinc.org"/> <code value="48765-2"/> <display value="Allergies, adverse reactions, alerts"/> </coding> </code> ... </section>	<se c="48765-2"> ... </se>
<Observation> <meta> <profile value="http://fhir.hl7.de/.../observation"/> </meta> <status value="final"/> <code> <coding> <system value="http://loinc.org"/> <code value="3142-7"/> <display value="Body weight"/> </coding> </code> <valueQuantity> <value value="89"/> <unit value="kg"/> <system value="http://unitsofmeasure.org"/> <code value="kg"/> </valueQuantity> </Observation>	<O c="3142-7" v="89" u="kg"/>
<Patient> <meta> <profile value="http://fhir.hl7.de/.../patient"/> </meta> <identifier> <system value="http://kvnummer.gkvnet.de"/> <value value="1234567890"/> </identifier> <active value="true"/> <name> <text value="Michaela Mustermann"/> <family value="Mustermann"/> <given value="Michaela"/> </name> <gender value="female"/> <birthDate value="1936-12-13"/> </Patient>	<P egk="1234567890" f="Mustermann" g="Michaela" s="F" b="1936-12-13"/>
<MedicationStatement> ... <repeat> <frequency value="1"/> <period value="1"/> <periodUnits value="d"/> <when value="PCD"/> </repeat> ... </MedicationStatement>	<M ... d="1" .../>

Auf die Wiedergabe von Text-Elementen wie sie in FHIR definiert sind, um den lesbare Wiedergabe der maschinenlesbaren Informationen anzugeben, wird im Ultrakurzformat ebenfalls verzichtet. Das käme der Tatsache gleich, dass das Barcode oder eGK-Format neben dem maschinenlesbaren Teil das Ganze auch noch als Text mit Aufmachung (Layout, Tabellenform etc.) wiedergibt, was außerhalb der Zielsetzung dieses Formats liegt.

Textwiedergaben können aber sowieso jederzeit aus den maschinenlesbaren Informationen generiert werden. Auch hierfür finden sich Beispiele für solche Transformationen in den Materialien.

Bezug zur CDA-Spezifikation „Patientenbezogener Medikationsplan“

Die CDA-Fassung zur vereinheitlichten elektronischen Wiedergabe und Speicherung von Patientenbezogenen Medikationsplänen liegt als offizielle Fassung im HL7 Clinical Document Architecture Format (ISO/HL7 27932:2009) vor und wurde im Rahmen des Interoperabilitätsforums abgestimmt. Bereits 2014 gab es während des Vorläuferprojekts in NRW Untersuchungen zu deutlich verkürzten Formaten, die sich auch für den Barcode eigenen würden. Schon damals ließ sich das CDA-Format in das Ultrakurzformat mit simplen Tools (XSLT) transformieren und umgekehrt (bijektive Abbildung).

Das hier vorliegende Format ist eine Weiterentwicklung der Vorarbeiten. Auch hierfür existieren Transformationen zwischen CDA und dem Ultrakurzformat bzw. dem FHIR-Basisformat. Die folgende Skizze gibt einen Überblick über die verschiedenen Prozesse und verwandten Formate.

Übersicht über die verwandten Formate: Systeme die einen Medikationsplan für einen Patienten pflegen können zum Beispiel direkt einen Papierplan für den Patienten ausdrucken (1). Der Plan wird elektronisch als CDA-Format oder im FHIR-Format / Ultrakurzformat abgelegt (2). CDA und FHIR / Ultrakurzformat sind in beide Richtungen mit allgemein verfügbaren Tools einfach ineinander transformierbar (Bijektivität, A). Sowohl aus CDA (3) als auch aus dem FHIR/Ultrakurzformat lassen sich Papierversionen erzeugen (4). Das Kurzformat eignet sich auch für den Barcode (5) oder die eGK (6). Für Mobile Apps steht das vollwertige FHIR Basis-Format zur Verfügung (7).

Übersicht über die Komponenten (Ressourcen)

Das vollwertige FHIR-Basisformat ist eine Sammlung von FHIR-Profilen, die für den Zweck der Abbildung eines Patientenbezogenen Medikationsplans zusammengestellt sind und sich nach den fachinhaltlichen Vorgaben des AkdÄ-Medikationsplans und weiterer bekannter Pläne richtet.

Der „Container“ ist ein so genanntes Bundle. Das FHIR Bundle enthält eine Composition (Entry) in der Basisinformationen zum Medikationsplan und Referenzen zum Patienten, dem eigentlichen Medikamentenliste und anderes enthalten ist. Die Daten sind in weiteren Entries als Resources im Bundle enthalten.

Übersicht über die anzuwendenden Komponenten des Medikationsplan-Bundles

Bundle

Die FHIR-Ressource Bundle bündelt die entsprechende Komponenten als Dokument. Es enthält

• Den Typ des Bundles (hier fixiert auf „document“)
• Einen Entry zur Composition, dem eigentlichen Dokument, das verschiedene Resources referenziert (weitere Entry-Elemente im Bundle)
• Weitere Entry-Elemente zu Patient, Medikationsplan-Einträgen usw.

In einer Übersicht in XML sieht dies wie folgt aus.

Beispiel

<Bundle xmlns="http://hl7.org/fhir">
    <meta>
        <versionId value="201"/>
        <profile value="http://fhir.hl7.de/medikationsplan/bundle"/>
    </meta>
    <type value="document"/>
    <entry>
        <fullUrl value="http://mein.medikationsplan.de/composition/1433e0a7-ba2a-4f46-8cad-5280508da565"/>
        <resource>
            <Composition>
                ...(mit Referenzen zu Patient, Medikationsplan-Einträgen usw.)
            </Composition>
        </resource>
    </entry>
    <entry>
        <fullUrl value="urn:uuid:e3e65616-8fd4-427urnd-b560-d847c2ca0a3a"/>
        <resource>
            ... (Entry: in der Composition referenzierte Resourcen wie Patient, Medikationsplan-Einträgen usw.)
        </resource>
    </entry>
    (weitere Entry-Einträge)
</Bundle>

Die eigentlichen Daten sind ein einem nachfolgenden Entry (Resource Patient) faktisch aufgeführt.

Ein Entry-Eintrag beinhaltet immer ein fullUrl-Element. Dieses enthält eine absolute URL zur Resource (im Beispiel: die Composition) ...

Beispiel

<Bundle xmlns="http://hl7.org/fhir">
    <type value="document"/>
    <entry>
        <fullUrl value="http://mein.medikationsplan.de/Composition/ed73c0b0-5ff5-....-514f36ab7c13"/>
        <resource>
             <Composition>...

...oder eine relative URL in der Form zum Beispiel urn:uuid:e3e65616-8fd4-427urnd-b560-d847c2ca0a3a um auf Resources innerhalb des Bundles zu zeigen. Auf diese Weise sind die Verbindungen zwischen Referenzen (z. B. Patientenreferenz) und den tatsächlichen Daten in den Resources (z. B. Patientendaten) gelegt.

{{NoteBox|Im Ultrakurzformat wird das Bundle und die im Folgenden beschriebene Composition (das Dokument) "ineinandergeschoben" und in einem einzigen Element repräsentiert (siehe unten).

Composition

Die FHIR-Ressource Composition kommt dem Clinical Document gleich und weist entsprechende Komponenten auf:

• Profil-Andeutung (im meta-Element)
• Medikationsplan-Identifikation (diese Ausgabe des Medikationsplans, dieser Patient)
• Datum (der Erstellung)
• Type der Composition
• Titel, zum Beispiel „Medikationsplan“
• Status, fixiert auf „final“
• Vertraulichkeitsgrad (confidentiality, hier zunächst fixiert auf „N“, normal)
• Referenz zum Patienten (subject, reference), die eigentlichen Daten sind ein einem nachfolgenden Entry (Resource Patient) faktisch aufgeführt (siehe Bundle)
• Ersteller (author), ebenso als Referenz gehandhabt
• Verwaltende Organisation der Composition/des Dokuments (custodian)
• Abschnitte (section) mit den Daten über
  • Klinische Parameter
  • Allergien und Unverträglichkeiten
  • Gesundheitsbelangen
  • Aktuelle Medikation
  • Wichtige Angaben / Instruktionen

entsprechend den CDA-Sections (siehe ).

Übersicht über die Komponenten der Composition

In einem Übersichtsbeispiel in XML stellt sich dies wie folgt dar.

Beispiel

<Composition>
    <meta>
    	<versionId value="201"/>
        <profile value="http://http://fhir.hl7.de/medikationsplan/composition"/>
    </meta>
    <identifier>
        <system value="http://mein.medikationsplan.de/composition"/>
        <value value="1433e0a7-ba2a-4f46-8cad-5280508da565"/>
    </identifier>
    <date value="2016-01-21T14:00:03+01:00"/>
    <type>
        <coding>
            <system value="http://loinc.org"/>
            <code value="56445-0"/>
        </coding>
    </type>
    <title value="Patientenbezogener Medikationsplan (2016)"/>
    <status value="final"/>
    <confidentiality value="N"/>
    <subject>
        <reference value="urn:uuid:e3e65616-8fd4-427urnd-b560-d847c2ca0a3a"/>
        <display value="Michaela Mustermann"/>
    </subject>
    <author>
        <reference value="urn:uuid:f262b3d9-d969-4759-a957-c1df5addfc86"/>
    </author>
    <custodian>
        <reference value="urn:uuid:1a910d80-ee7b-485d-a97e-644bd275d459"/>
    </custodian>
    <section>
        ...
    </section>
</Composition>

Als erstes Element wird im meta-Element der Hinweis auf das entsprechende UKF-FHIR-Profil inklusive Profil-Versions-Id in der Instanz angegeben.

Beispiel

<meta>
    <versionId value="201"/>
    <profile value="http://fhir.hl7.de/medikationsplan/composition"/>
</meta>

Es folgt die eindeutige Identifikation der Instanz dieser Composition (Medikationsplan-Identifikation), d.h. die Identifikation dieses Medikationsplans für diesen Patienten in der vorliegenden Fassung. Neue Pläne für diesen oder andere Patienten haben entsprechende eine andere Id.

Beispiel

<identifier>
     <system value="http://mein.medikationsplan.de/composition"/>
     <value value="1433e0a7-ba2a-4f46-8cad-5280508da565"/>
</identifier>

Es folgen das Datum der Erstellung, der Typ des Dokuments (Composition) ist fixiert und so anzugeben wie im obigen Gesamtbeispiel. Das gleiche gilt für den Status (final) des Dokuments und den Vertraulichkeitsgrad (N).

Der Patient, der Ersteller (Autor) und die das Dokument verwaltende Organisation (custodian) werden in der Composition als Referenzen angegeben. Die eigentlichen Daten hierzu stehen jeweils in den zugehörigen Entry-Elementen des Bundles mit dem entsprechenden fullUrl-Element. Die Verknüpfung erfolgt über Referenz-Elemente, die auf das jeweilige Entry zeigen.

Beispiel: Patient-Referenz in der Composition, die Angabe des Patientennamens ist hier optional

<subject>
    <reference value="urn:uuid:e3e65616-8fd4-427d-b560-d847c2ca0a3a"/>
    <display value="Michaela Mustermann"/>
</subject>

Beispiel: Author- und Custodian-Referenz in der Composition

<author>
    <reference value="urn:uuid:f262b3d9-d969-4759-a957-c1df5addfc86"/>
</author>
<custodian>
    <reference value="urn:uuid:1a910d80-ee7b-485d-a97e-644bd275d459"/>
</custodian>

Schließlich folgen die vier Abschnitte (Sections, analog zu der CDA-Definition).

Section	LOINC-Code
Klinische Parameter (Körpergewicht, Kreatinin, …)	55752-0
Allergien und Unverträglichkeiten	48765-2
Gesundheitsbelange (schwanger, stillend)	75310-3
Aktuelle Medikation	19009-0
Wichtige Angaben / Instruktionen	69730-0

Im Folgenden ist ein Beispiel zu den klinischen Parametern (LOINC 55752-0) gezeigt, es wird auf zwei Entries verwiesen (Körpergewicht, Kreatinin).

Beispiel

<section>
    <title value="Klinische Parameter"/>
    <code>
        <coding>
            <system value="http://loinc.org"/>
            <code value="55752-0"/>
            <display value="Clinical information"/>
        </coding>
    </code>
    <entry>
        <reference value="urn:uuid:23f6114c-994f-4b77-b7a9-5fa402aa93b1"/>
    </entry>
    <entry>
        <reference value="urn:uuid:f8611c65-fd9c-4fda-ac05-3ae005eedd91"/>
    </entry>
</section>

Weitere Informationen finden sich in der Beschreibung der entsprechenden FHIR Resource https://www.hl7.org/fhir/composition.html und den Datentypen https://www.hl7.org/fhir/datatypes.html.

Ultrakurzformat

Im Ultrakurzformat wird das oben beschriebene Bundle und die hier beschriebene Composition (das Dokument) "ineinandergeschoben" und in einem einzigen Element repräsentiert:

<BC xmlns="http://fhir.hl7.de/ukfc" 
  U="http://mein.medikationsplan.de//Composition/fba0567c-25e6-41cc-b7b5-dd9c2605b97a"
  c="56445-0"
  t="2016-01-29T08:54:20+01:00">
  ...
</BC>

Dabei bedeuten:

Element/ Attribut	Beschreibung
BC	Root-Element (Bundle+Composition)
@xmlns	der Namespace, fix wie im Beispiel angegeben
@U	die absolute URL (wenn angegeben) zur Composition-Resource
@c	der LOINC Code für den Mediaktionsplan zur Typisierung des Inhalts dieser Instanz, fix wie im Beispiel angegeben
@t	der Zeitpunkt der Erstellung, Zeitstempel im ISO-Format

Anstatt die erforderlichen Daten über Referenzen in die Composition einzubinden, werden die Angaben zum Patienten, Autoren, den Sections usw. direkt an Ort und Stelle im Ultrakurzformat verwendet. Im folgenden Auszug ist gezeigt, wie der Patient (P), Autor (A) und eine Section (se) als Kind-Elemente innerhalb des eben beschriebenen Bundle+Composition-Elements (BC) eingebettet sind.

<BC xmlns="http://hl7.de/ukfc" ...>
    <P egk="1234567890" f="Mustermann" g="Michaela" s="F" b="1936-12-13"/>
    <A lanr="165746304" g="Dr. Xra" f="Überall">
        <ph v="tel:04562-12345" u="work"/>
        <em v="mailto:m.ueberall@mein-netz.de" u="work"/>
        <ad s="Hauptstraße 55" o="01234 Am Ort" u="work"/>
    </A>
    ...
    <se c="55752-0">
        <O c="3142-7" v="89" u="kg"/>
        <O c="2160-0" v="1.3" u="mg/dl"/>
    </se>
    ...
</BC>

Diese Kind-Elemente werden im Detail in den folgenden Abschnitten beschrieben.

Patient

Die Patienten-Resource für die hier beschriebenen Zwecke beginnt mit einer Identifikationsnummer, zum Beispiel der eGK-Nummer (wie im Beispiel).

Der Status ist fixiert auf den Wert „active“.

Der Name wird typischerweise in family- und given-Element verteilt.

Das Geschlecht ist nach der FHIR-Spezifikation anzugeben (https://www.hl7.org/fhir/valueset-administrative-gender.html), hier also entweder „female“, „male“ oder „other“. „unknown“ ist ebenso erlaubt.

Schließlich erfolgt das Geburtsdatum im ISO-Format YYYY-MM-DD.

Beispiel

<Patient>
    <meta>
        <versionId value="201"/>
        <profile value="http://http://fhir.hl7.de/medikationsplan/patient"/>
    </meta>
    <identifier>
        <system value="http://kvnummer.gkvnet.de"/>
        <value value="1234567890"/>
    </identifier>
    <active value="true"/>
    <name>
        <text value="Michaela Mustermann"/>
        <family value="Mustermann"/>
        <given value="Michaela"/>
    </name>
    <gender value="female"/>
    <birthDate value="1936-12-13"/>
</Patient>

Weitere Informationen finden sich in der Beschreibung der entsprechenden FHIR Resource https://www.hl7.org/fhir/patient.html und den Datentypen https://www.hl7.org/fhir/datatypes.html.

Ultrakurzformat

Im Ultrakurzformat wird das oben beschriebene Bundle und die hier beschriebene Composition (das Dokument) "ineinandergeschoben" und in einem einzigen Element repräsentiert:

<P egk="1234567890" f="Mustermann" g="Michaela" s="F" b="1936-12-13"/>

Dabei bedeuten:

Element/ Attribut	Beschreibung
P	Element (Patient)
@egk	eGK-Nummer
@f	Familienname(n) des Patienten
@g	Vorname(n) des Patienten
@s	Geschlecht, kodiert; die Codes sind kurz gebunden und kommen aus dem Value Set
@b	Geburtsdatum des des Patienten im ISO-Kurzformat YYYY-MM-DD