Innerhalb von TA7-Dateien - siehe GKVSV_PR_TA7_Sammelrechnung_Bundle für die ab Juli gültige Version - werden alle Bündeleinträge der obersten Ebene von anderen Bündeleinträgen referenziert. Einzige Ausnahme ist der Haupteintrag (a.k.a. Bundle.entry[0] bzw. Sammelrechnung_Composition), bei dem die Verarbeitung beginnt und der somit per definitionem implizit referenziert ist.
Aufgrund der Flexibilität von FHIR gibt es eine ganze Reihe von Möglichkeiten, diese Referenzen und die Identifizierung der Bündeleinträge zu handhaben.
Die Referenz auf die enthaltende TA7-Datei in der Liste der TA7-Sammelrechnungsbündel stellt dabei einen Sonderfall dar, da die TA7-Datei selbst im Gegensatz zu den enthaltenen Bündeleinträgen keine effektive Basis-URL hat. Daher ist es in diesem Fall nicht möglich, aus Basis-URL, Ressource-Typ und logischer Id eine absolute URL zu bilden, und standardisierte Möglichkeiten zum Angeben einer absoluten URL/URI gibt es hier auch nicht. Aus diesem Grund ist die Angabe einer relativen Pseudo-URL ('Bundle/{id}') momentan die einzige in Frage kommende Möglichkeit, und die Auflösung der Referenz erfolgt dann über die Notnagel-Regel.
Alle anderen Referenzen können im vorliegenden Szenario eine der folgenden Formen haben:
'List/1' (relative URL, bei gleicher Basis-URL für referenzierenden und referenzierten Bündeleintrag)
'List/1' (relative Pseudo-URL, bei Eindeutigkeit innerhalb der Datei ungeachtet der Basis-URLs möglich)
Referenzen über absolute URIs (wie in den zuerst genannten beiden Fällen) werden vom HAPI-Validator schneller aufgelöst als die relativen Formen. Bei großen Rezeptanzahlen - wo der Aufwand für das Auflösen der Referenzen alles andere dominiert - können die relativen Formen eine Verdoppelung der für das Validieren benötigten Zeit verursachen.
Bündeleinträge müssen im vorliegenden Szenario grundsätzlich mit einer absoluten URI (Bundle.entry.fullUrl) daherkommen, und die im Bündeleintrag enthaltene Ressource kann optional eine logische Id haben (Bundle.entry.resource.id). Der Standard fordert zwingend das Format {Basis-URL}/{Typ}/{Id}, wenn die URI das Format einer HTTP(S)-URL hat und die Ressource eine logische Id besitzt. Dabei steht {Typ} für den Typ der Ressource und {Id} für ihre logische Id.
Damit sind die folgenden drei Konstellationen möglich:
<entry>
<fullUrl value='urn:uuid:541a72a8-df75-4484-ac89-ac4923f03b81'>
<List>
... <!-- keine Id -->
Man beachte hier insbesondere den Umstand, daß bei Verwendung von UUID-URNs keinerlei Beziehung zwischen entry.fullUrl und entry.resource.id besteht, und daß die Einträge nicht einmal eine logische Id haben müssen.
Theoretisch gibt es auch noch eine vierte Variante, aber diese ist im FHIR-Standard nicht eindeutig/sauber durchdekliniert und sollte daher entweder auf das oben genannte Format für HTTP-URLs umgestellt oder ganz vermieden werden:
<entry>
<fullUrl value='http://rz009.de/datei-intern/unklar'>
<List>
... <!-- keine Id -->
Für das Durchspielen aller Varianten mit dem HAPI-Validator empfiehlt sich die Verwendung einer minimalen Bundle-Ressource vom Typ collection, mit Patient für die Bündeleinträge (hat keine Pflichtfelder und ist als Composition.author referenzierbar). Das XML-Beipiel in Issue #815 im HAPI-Repository kann hier als Vorlage dienen. Beim Durchspielen mit dem Referenzvalidator kommt man leider nicht drumherum, komplette TA7-Dateien zu bauen. Hier empfiehlt sich die Verwendung eines Skriptes zum Generieren der Varianten.
TA7-Konverter
Der TA7-Konverter versteht momentan keine einzige der vom FHIR-Standard vorgesehenen Möglichkeiten der Referenzierung. Das ist mir aufgefallen, als ich Testdaten für einen Lasttest generieren wollte und trotz Durchprobieren aller Referenzierungsvarianten ausschließlich Konverterabstürze erntete. Ergo habe ich das CLI-Jar in einem IntelliJ-Projekt referenziert und mich mit F7 zum Absturzort durchgehangelt.
Ich zeige hier nur den unmittelbar relevanten Teil des Quellcode-Knäuels; Horror-Liebhaber mögen sich selber mit IntelliJ und F7 auf den Weg machen. Der Tatort ist in der privaten Funktion de.systhemis.fhir.lib.FhirConverter::writeUNB:
private void writeUNB (List<EDIFACTRow> rows, List<Node> nodes)
...
HashMap<String, Invoice> invoiceHashMap = new HashMap();
Iterator var9 = this.invoices.iterator();
while(var9.hasNext()) {
...
Iterator var14 = invoiceNodeBundleReferences.iterator();
while(var14.hasNext()) {
Node node = (Node)var14.next();
String bundleId = this.fhirXPathReader.readString("@value", node).substring(9);
invoiceHashMap.put(bundleId, in);
}
...
for(Iterator var19 = this.bundlesSet.iterator(); var19.hasNext(); ++i) {
...
// ...SCHNIPP... ist im Original eine lange Liste von Profil-URL-Vergleichen
String bundleId = this.fhirXPathReader.readString(
"Bundle/meta/profile[...SCHNIPP...]/../../id/@value", bundleNodes);
Invoice in = (Invoice)invoiceHashMap.get(bundleId);
Man beachte, daß aus den Referenzen in der Liste der Rezeptbündelreferenzen blind ein Substring ab dem 10. Zeichen herausgegriffen wird. Für diesen Substring wird die Übereinstimmung mit der logischen Id eines Rezeptbündels erwartet.
Mit dieser abenteuerlichen Konstruktion kann natürlich keine einzige der Standard vorgesehenen Referenzierungs- bzw. Identifizierungsmöglichkeiten korrekt verarbeitet werden - geschweige denn alle, wie es die Funktion des Konverters eigentlich erfordert.
Die einzige Möglichkeit zum Erzeugen FHIR-konformer TA7-Dateien, die trotzdem vom FHIR-Konverter verarbeitet werden können, besteht in der Verwendung von UUID-URNs in Referenzen und Bündeleintrags-URLs (ohnehin die empfehlenswerteste Variante), gekoppelt mit Verwendung der jeweiligen UUID als logische Id der Ressource:
NB: obige Links sind für die aktuell gültige Version 4.0.1 des FHIR-Standards. Beim Einstieg von außen landet man schnell in der Entwurfsversion (R5, erkennbar am mit 'build.' beginnenden Domänennamen), die in einigen relevanten Details von R4 abweicht.
Hinweise auf weitere Textstellen im Standard mit Relevanz für das vorliegende Thema sind natürlich willkommen, genauso wie alle sachlichen Hinweise!
Innerhalb von TA7-Dateien - siehe GKVSV_PR_TA7_Sammelrechnung_Bundle für die ab Juli gültige Version - werden alle Bündeleinträge der obersten Ebene von anderen Bündeleinträgen referenziert. Einzige Ausnahme ist der Haupteintrag (a.k.a.
Bundle.entry[0]bzw. Sammelrechnung_Composition), bei dem die Verarbeitung beginnt und der somit per definitionem implizit referenziert ist.Aufgrund der Flexibilität von FHIR gibt es eine ganze Reihe von Möglichkeiten, diese Referenzen und die Identifizierung der Bündeleinträge zu handhaben.
Die Referenz auf die enthaltende TA7-Datei in der Liste der TA7-Sammelrechnungsbündel stellt dabei einen Sonderfall dar, da die TA7-Datei selbst im Gegensatz zu den enthaltenen Bündeleinträgen keine effektive Basis-URL hat. Daher ist es in diesem Fall nicht möglich, aus Basis-URL, Ressource-Typ und logischer Id eine absolute URL zu bilden, und standardisierte Möglichkeiten zum Angeben einer absoluten URL/URI gibt es hier auch nicht. Aus diesem Grund ist die Angabe einer relativen Pseudo-URL ('Bundle/{id}') momentan die einzige in Frage kommende Möglichkeit, und die Auflösung der Referenz erfolgt dann über die Notnagel-Regel.
Alle anderen Referenzen können im vorliegenden Szenario eine der folgenden Formen haben:
Referenzen über absolute URIs (wie in den zuerst genannten beiden Fällen) werden vom HAPI-Validator schneller aufgelöst als die relativen Formen. Bei großen Rezeptanzahlen - wo der Aufwand für das Auflösen der Referenzen alles andere dominiert - können die relativen Formen eine Verdoppelung der für das Validieren benötigten Zeit verursachen.
Bündeleinträge müssen im vorliegenden Szenario grundsätzlich mit einer absoluten URI (
Bundle.entry.fullUrl) daherkommen, und die im Bündeleintrag enthaltene Ressource kann optional eine logische Id haben (Bundle.entry.resource.id). Der Standard fordert zwingend das Format {Basis-URL}/{Typ}/{Id}, wenn die URI das Format einer HTTP(S)-URL hat und die Ressource eine logische Id besitzt. Dabei steht {Typ} für den Typ der Ressource und {Id} für ihre logische Id.Damit sind die folgenden drei Konstellationen möglich:
Man beachte hier insbesondere den Umstand, daß bei Verwendung von UUID-URNs keinerlei Beziehung zwischen
entry.fullUrlundentry.resource.idbesteht, und daß die Einträge nicht einmal eine logische Id haben müssen.Theoretisch gibt es auch noch eine vierte Variante, aber diese ist im FHIR-Standard nicht eindeutig/sauber durchdekliniert und sollte daher entweder auf das oben genannte Format für HTTP-URLs umgestellt oder ganz vermieden werden:
Für das Durchspielen aller Varianten mit dem HAPI-Validator empfiehlt sich die Verwendung einer minimalen Bundle-Ressource vom Typ
collection, mitPatientfür die Bündeleinträge (hat keine Pflichtfelder und ist alsComposition.authorreferenzierbar). Das XML-Beipiel in Issue #815 im HAPI-Repository kann hier als Vorlage dienen. Beim Durchspielen mit dem Referenzvalidator kommt man leider nicht drumherum, komplette TA7-Dateien zu bauen. Hier empfiehlt sich die Verwendung eines Skriptes zum Generieren der Varianten.TA7-Konverter
Der TA7-Konverter versteht momentan keine einzige der vom FHIR-Standard vorgesehenen Möglichkeiten der Referenzierung. Das ist mir aufgefallen, als ich Testdaten für einen Lasttest generieren wollte und trotz Durchprobieren aller Referenzierungsvarianten ausschließlich Konverterabstürze erntete. Ergo habe ich das CLI-Jar in einem IntelliJ-Projekt referenziert und mich mit F7 zum Absturzort durchgehangelt.
Ich zeige hier nur den unmittelbar relevanten Teil des Quellcode-Knäuels; Horror-Liebhaber mögen sich selber mit IntelliJ und F7 auf den Weg machen. Der Tatort ist in der privaten Funktion
de.systhemis.fhir.lib.FhirConverter::writeUNB:Man beachte, daß aus den Referenzen in der Liste der Rezeptbündelreferenzen blind ein Substring ab dem 10. Zeichen herausgegriffen wird. Für diesen Substring wird die Übereinstimmung mit der logischen Id eines Rezeptbündels erwartet.
Mit dieser abenteuerlichen Konstruktion kann natürlich keine einzige der Standard vorgesehenen Referenzierungs- bzw. Identifizierungsmöglichkeiten korrekt verarbeitet werden - geschweige denn alle, wie es die Funktion des Konverters eigentlich erfordert.
Die einzige Möglichkeit zum Erzeugen FHIR-konformer TA7-Dateien, die trotzdem vom FHIR-Konverter verarbeitet werden können, besteht in der Verwendung von UUID-URNs in Referenzen und Bündeleintrags-URLs (ohnehin die empfehlenswerteste Variante), gekoppelt mit Verwendung der jeweiligen UUID als logische Id der Ressource:
Links zu den wichtigsten relevanten Teilen des FHIR-Standards
NB: obige Links sind für die aktuell gültige Version 4.0.1 des FHIR-Standards. Beim Einstieg von außen landet man schnell in der Entwurfsversion (R5, erkennbar am mit 'build.' beginnenden Domänennamen), die in einigen relevanten Details von R4 abweicht.
Hinweise auf weitere Textstellen im Standard mit Relevanz für das vorliegende Thema sind natürlich willkommen, genauso wie alle sachlichen Hinweise!
P.S.: An example bundle that demonstrates various reference resolution paths @ hl7.org