• Projektziele
  • NICHT-Projektziele
  • Was der Validator nicht prüft
• Verwendung
  • Fat-Jar
  • Einbindung in Maven oder Gradle Builds
• Contribution
  • Build
    • Releasen
      • Ablauf eines offiziellen Release
• Packages & Profile & Versionen
  • unterstütze Profile und Versionen
  • eingebundene Packages (R4)
    • Anpassungen der Packages

• Der Referenzvalidator dient als "Schiedsrichter", mit dem ohne weitere Voraussetzungen FHIR Dateien auf Ihre Validität (valid oder nicht valid) getestet werden können. Die einzig relevante Ausgabe ist 'Validation result: true' oder 'Validation result: false'. Zusätzlich ausgegebene Warnings sind ausschließlich informell und haben keinen Einfluss auf das Ergebnis. Das positive Testergebnis ist eine Voraussetzung für die Annahme von Datenlieferungen zwischen Apothekenrechenzentren und Krankenkassen(-Annahmestellen). Alle weiteren Akzeptanzkriterien werden in der TA7 Spezifikation festgelegt.
• Es werden ausschließlich in den entsprechenden FHIR-Profilen enthaltene Constraints geprüft.
• Es wird immer nur genau eine FHIR-XML-Datei geprüft. Als Base64-eingebettete weitere FHIR-Daten müssen durch separate Schritte/Aufrufe extrahiert und geprüft werden.
• Kontrolle ob die Profilversion (nach TA7 Anhang 2) einer Instance zum Zeitpunkt dessen Erstellung gültig war

  Vor einer Validierung wird die korrekte Profilversion der Instanz geprüft.

  • Verordnung, Datum der Ausstellung (KBV_PR_ERP_Prescription: MedicationRequest.authoredOn bzw. KBV_PR_ERP_PracticeSupply: SupplyRequest.authoredOn)
  • MedicationDispense, Abgabedatum (GEM_ERP_PR_MedicationDispense bzw. Gem_erxMedicationDispense: MedicationDispense.whenHandedOver)
  • Quittung, Ausstellungsdatum (GEM_ERP_PR_Composition bzw. Gem_erxComposition: Composition.date)
  • Abgabedaten, Abgabedatum (DAV_PR_ERP_Abgabeinformationen: MedicationDispense.whenHandedOver)
  • Abrechnungsdaten, Abrechnungsmonat (GKVSV_PR_TA7_Rechnung_Composition bzw. GKVSV_PR_TA7_Sammelrechnung_Composition: Composition.date)
  • PKV Abgabedaten, Abgabedatum (DAV-PKV-PR-ERP-AbgabedatenComposition: MedicationDispense.whenHandedOver)
  • PKV Patientenrechnung, Abrechnungsdatum (GEM_ERPCHRG_PR_ChargeItem: ChargeItem.enteredDate)
  • PKV Patientenrechnung, Einwilligungsdatum (GEM_ERPCHRG_PR_Consent: Consent.dateTime)

• Falsche oder fehlende Constraints in den FHIR-Profilen werden nicht mit dem Validator nachkorrigiert sondern durch versionierte Änderung der Profile.
• Der Referenzvalidator kann in produktiven Umgebungen eingesetzt werden, der gibt aber derzeit keine Garantie für Stabilität oder Optimierungen im Bezug auf Performance, Speicherverbrauch und Laufzeit.
• Eine Signaturvalidierung oder Zertifikatsprüfung findet nicht statt.
• Das Ergebnis des Validators ist keine Garantie für ein retaxierungsfreies E-Rezept.

Die Projektziele können sich zukünftig ändern. Fehler werden über Issues gemeldet und nach den Projektzielen priorisiert bzw. akzeptiert oder abgelehnt.

• Referenzen [type]/[id]

  relative URL "[type]/[id]" when resource has fullUrl "urn:uuid:[id]"

• fehlerhafte UUIDs
  • UUIDs werden momentan nicht auf Konformität nach RFC4122 geprüft.
• UTF-8-BOM

  Das Format für alle E-Rezept-Dateien ist XML im UTF8 ohne BOM-Zeichensatz. Dieser Zeichensatz ist von der gematik für alle E-Rezept-Daten vorgegeben.

Der Referenzvalidator wird auf zwei Arten bereitgestellt: Als Fat-Jar (inklusive CLI) und als Artefakt (CORE) auf Maven Central

Das Fat-Jar enthält alle Abhängigkeiten und kann daher standalone ohne das Nachladen von Ressourcen verwendet werden. Es dient als "Schiedsrichter", mit dem ohne weitere Voraussetzungen FHIR Dateien auf Ihre Validität getestet werden können. Zum Starten ist lediglich (mindestens) ein Java 8 JRE (Java Runtime Environment) notwendig.

java -jar reference-validator-cli.jar myFhirResource.xml [--noInstanceValidityCheck] [--profile [ProfileCanonical] ] 

myFhirResource.xml    Angabe der zu validierenden FHIR-Instanz

optionale Parameter (Reihenfolge egal):
--noInstanceValidityCheck           deaktiviert die standardmäßige Gültigkeitskontrolle einer Instanz

--profile [ProfileCanonical]        optionale zusätzliche Möglichkeit die Instanze einzuschränken
                                    ProfileCanonicals können auch mehrfach angegeben werden
                                    
   Liste der unterstützten Profile: 
   --profile https://fhir.kbv.de/StructureDefinition/KBV_PR_ERP_Bundle
   --profile https://gematik.de/fhir/StructureDefinition/ErxMedicationDispense
   --profile https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_MedicationDispense
   --profile https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_CloseOperationInputBundle
   --profile https://gematik.de/fhir/StructureDefinition/ErxReceipt
   --profile https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Bundle
   --profile https://fhir.abda.de/eRezeptAbgabedaten/StructureDefinition/DAV-PR-ERP-AbgabedatenBundle
   --profile https://fhir.gkvsv.de/StructureDefinition/GKVSV_PR_TA7_Sammelrechnung_Bundle
   --profile https://fhir.gkvsv.de/StructureDefinition/GKVSV_PR_TA7_Rechnung_Bundle
   --profile https://fhir.abda.de/eRezeptAbgabedaten/StructureDefinition/DAV-PKV-PR-ERP-AbgabedatenBundle
   --profile https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_ChargeItem
   --profile https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Consent    

Die Bereitstellung des Validators als Artefakte auf Maven Central dient dazu, den Validator in andere Systeme einbindbar zu machen und so die Validierung als Funktionalität zu integrieren, z.B. in Abrechnungssysteme oder Warenwirtschaftssysteme.

Die Artefakte werden unter der GroupId de.abda bereitgestellt. Es gibt zwei Artefakte mit den ArtefactIds:

• fhir-validator-core: Die einbindbaren Klassen
• fhir-validator-packages: Die notwendigen FHIR Profile für den Validator.

Achtung: Der Validator benutzt die FHIR Basisfunktionalitäten von ca.uhn.hapi.fhir. Die zugesicherte Korrektheit der Validierung ist nur gegeben, wenn zur Laufzeit auch exakt die angegebenen Versionen verwendet werden. Bitte stellen Sie sicher, dass Ihr Maven oder Gradle Build entsprechend konfiguriert ist. Bitte beachten Sie das die Sprach-Locale, für ein ordnungsgemäßes Validierungsergebnis, ENGLISH sein muss.

Dafür können Sie die ebenfalls veröffentlichte BOM (Bill of Materials) verwenden, ArtefaktId ist fhir-validator-bom. Bitte lesen Sie in der Maven bzw. Gradle Dokumentation nach, wie man diese BOM so einbindet, dass immer die korrekten Versionen verwendet werden.

Die Klasse ReferenceValidator stellt das API dar und sollte in Applikationen verwendet werden:

//An existing FhirContext can optionally be passed to the constructor for performance reasons
ReferenceValidator validator = new ReferenceValidator(); 

//path can be a String or a Path object
Map<ResultSeverityEnum, List<SingleValidationMessage>> errors = validator.validateFile(path);
List<SingleValidationMessage> errors = validator.validateFile2ValidationMessageList(path);
boolean errors = validator.validateFile2Boolean(path);
//or (with parameter: noInstanceValidityCheck (default false) and profileValidateAgainst (default null or empty))
Map<ResultSeverityEnum, List<SingleValidationMessage>> errors = validator.validateFile(String validatorInputAsString, boolean noInstanceValidityCheck, List<String> profileValidateAgainst)
List<SingleValidationMessage> errors = validator.validateFile2ValidationMessageList(String validatorInputAsString, boolean noInstanceValidityCheck, List<String> profileValidateAgainst)
boolean errors = validator.validateFile2Boolean(String validatorInputAsString, boolean noInstanceValidityCheck, List<String> profileValidateAgainst)

//If the file content is already read to a String, you can use validateString
Map<ResultSeverityEnum, List<SingleValidationMessage>> errors = validator.validateString(stringContent);
List<SingleValidationMessage> errors = validator.validateString2ValidationMessageList(stringContent);
boolean errors = validator.validateString2Boolean(stringContent);
//or (with parameter: noInstanceValidityCheck (default false) and profileValidateAgainst (default null or empty))
Map<ResultSeverityEnum, List<SingleValidationMessage>> errors = validator.validateString(String validatorInputAsString, boolean noInstanceValidityCheck, List<String> profileValidateAgainst)
List<SingleValidationMessage> errors = validator.validateString2ValidationMessageList(String validatorInputAsString, boolean noInstanceValidityCheck, List<String> profileValidateAgainst)
boolean errors = validator.validateString2Boolean(String validatorInputAsString, boolean noInstanceValidityCheck, List<String> profileValidateAgainst)

//convert MessagesResult to ValidationResult (boolean)
boolean errorResult = validate2Boolean(validationResultMessages);

In diesem Kapitel finden sich Informationen für alle, die den Validator entweder selbst bauen oder zum Projekt beitragen möchten.

Es gibt drei Submodule:

• core enthält die eigentliche Validator Implementierung. Diese wird im CLI verwendet, kann aber auch direkt in Java Projekten als Bibliothek verwendet werden. Zur Laufzeit besteht eine Abhängigkeit zum packages Modul
• packages enthält die zu ladenden Profile
• cli enthält eine Kommandozeilen Implementierung

Das Projekt arbeitet mit einem Gradle Build. Das Projekt kann mittels des Gradle-Wrappers gebaut werden, ohne vorher ein Gradle selbst installieren zu müssen:

gradlew build

Es gibt folgende Gradle Tasks, die zum Releasen verwendet werden können. Für diese Tasks sind die notwendigen Zugangsdaten für Sonatype und die Daten zum Signieren notwendig, diese sind nicht eingecheckt und werden von der ABDA nicht veröffentlicht.

• snapshot: Erzeugt ein Snaphot Release. Dieses kennzeichnet sich durch ein -SNAPSHOT als Suffix der Versionsnummer. Snapshot Releases werden auch als solche zu Maven Central hochgeladen und können dort abgerufen werden, wenn die korrekte Repository URL im Gradle oder Maven Build verwendet wird. Bei Snapshot Releases wird der Sourcecode NICHT getaggt.
• final: Erzeugt ein offizielles Release. Dazu wird auf Basis des letzten Versionstags im Git standardmäßig die Minor Nummer hochgezählt (es wird das Nummernschema von sematik Versioning verwendet: major.minor.patch). Das Release wird zu Maven Central ins Staging System hochgeladen, und der SourceCode Stand wird mit der Versionsnummer getaggt.
  • Sollte nicht die Minor Number, sondern die Patch Number erhöht werden, dann bitte folgenden Parameter setzen: gradlew final -Prelease.scope=patch
  • Sollte nicht die Minor Number, sondern die Majir Number erhöht werden, dann bitte folgenden Parameter setzen: gradlew final -Prelease.scope=major
  • Soll exakt eine bestimmte Versionsnummer gesetzt werden, dann bitte folgenden Parameter setzen: gradlew final -Prelease.version=0.1.1, wobei sie 0.1.1 durch die exakte neue Versionsnummer ersetzen

• Sie befinden sich auf dem main Branch, alle lokalen Änderungen wurden committed und gepushed.
• Es wird gradlew clean final aufgerufen und damit die Artefakte gebaut und hochgeladen (das cli Subprojekt wird NICHT zu Maven Central hochgeladen)
• Freigeben des Release für Maven Central:
  • In einem Browser wird https://s01.oss.sonatype.org geöffnet und sich dort mit dem ABDA-FHIR-Team User eingelogged.
  • Wenn man links im Menü auf "Staging Repositories" klickt, dann sieht man in der Mitte in der Liste ein Repository mit Namen deabda-1234 wobei 1234 eine laufende Nummer ist.
  • Wenn man das Repository anklickt kann man unten im Tab "Content" sich die hochgeladenen Daten ansehen.
  • Zur Freigabe wird in horizontalen Menüleiste in der Mitte oben auf "Close" geklickt. Dann läuft eine interne, asynchrone Prüfung der hochgeladenen Artefakte an. Diese Prüfung dauert einige Sekunden, evtl. muss man mehrmals "Refresh" klicken, bis man entweder den Status "Closed" oder die Prüfung mit "Failed" geendet ist
  • Ist die Prüfung fehlgeschlagen kann das Repository mit dem Punkt "Drop" aus der mittleren oberen Menüleiste gelöscht werden, und es nochmal versucht werden.
  • Ist die Prüfung erfolgreich, dann kann das Repository mit dem Punkt "Release" aus der mitteleren oberen Menüleiste das Release freigegeben werden. Erst danach können andere Benutzer dieses Release über Maven Central abrufen!
• In GitHub unter "Releases" "Create a new Release" anklicken. In der Maske unter "Choose a tag" das erzeugte Versionstag auswählen, im Feld "Release title" die Versionsnummer nochmal eingeben und im Feld "Describe this release" die Release Notes eintragen. Darunter kann man Dateien hochladen, das unter cli/build/libs erzeugte Fat-Jar damit hochladen und "Publish release" anklicken.

• https://fhir.kbv.de/StructureDefinition/KBV_PR_ERP_Bundle
  • 1.0.1
  • 1.0.2
  • 1.1.0
• https://gematik.de/fhir/StructureDefinition/ErxMedicationDispense
  • 1.0.3
  • 1.0.3-1 (Instanzen ohne Versionsangaben werden gegen die Version 1.0.3-1 validiert)
  • 1.1.1
• https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_MedicationDispense
  • 1.2
• https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_CloseOperationInputBundle (for multiple MedicationDispenses)
  • 1.2
• https://gematik.de/fhir/StructureDefinition/ErxReceipt
  • 1.0.3
  • 1.0.3-1 (Instanzen ohne Versionsangaben werden gegen die Version 1.0.3-1 validiert)
  • 1.1.1
• https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Bundle
  • 1.2
• https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_ChargeItem
  • 1.0
• https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Consent
  • 1.0
• https://fhir.abda.de/eRezeptAbgabedaten/StructureDefinition/DAV-PKV-PR-ERP-AbgabedatenBundle
  • 1.2
• https://fhir.abda.de/eRezeptAbgabedaten/StructureDefinition/DAV-PR-ERP-AbgabedatenBundle
  • 1.0.3
  • 1.1.0
  • 1.2
  • 1.3
• https://fhir.gkvsv.de/StructureDefinition/GKVSV_PR_TA7_Sammelrechnung_Bundle
  • 1.0.4
  • 1.0.5
  • 1.0.6
  • 1.1.0
  • 1.2
• https://fhir.gkvsv.de/StructureDefinition/GKVSV_PR_TA7_Rechnung_Bundle
  • 1.3

• de.basisprofil.r4-0.9.13.tgz
• de.basisprofil.r4-1.3.2.tgz
• kbv.basis-1.1.3.tgz
• kbv.basis-1.3.0.tgz (ACHTUNG! expansion SNOMED entfernt...)
• kbv.ita.for-1.0.3.tgz
• kbv.ita.for-1.1.0.tgz
• kbv.ita.erp-1.0.1.tgz
• kbv.ita.erp-1.0.2.tgz
• kbv.ita.erp-1.1.0.tgz (entfernt v1.0.2)
• kbv.ita.erp-1.1.1.tgz (KorrekturRelease für v1.1.0)
• de.gematik.erezept-workflow.r4-1.0.3.tgz (entfernt v0.9.8)
• de.gematik.erezept-workflow.r4-1.0.3-1.tgz
• de.gematik.erezept-workflow.r4-1.1.1.tgz
• de.gematik.erezept-workflow.r4-1.2.0.tgz (entfernt v1.0.2)
• de.gematik.erezept-workflow.r4-1.2.1.tgz (KorrekturRelease für v1.2.0) (entfernt v1.0.3)
• de.gematik.erezept-workflow.r4-1.2.2.tgz (KorrekturRelease für v1.2.1)
• de.gematik.erezept-patientenrechnung.r4-1.0.0.tgz (entfernt v1.0.2)
• de.gematik.erezept-patientenrechnung.r4-1.0.1.tgz (KorrekturRelease für v1.0.0)
• de.abda.erezeptabgabedaten-1.0.3.tgz
• de.abda.erezeptabgabedatenbasis-1.1.0.tgz (ACHTUNG! fix issue)
• de.abda.erezeptabgabedatenbasis-1.1.2.tgz (entfernt v0.9.8)
• de.abda.erezeptabgabedatenbasis-1.1.3.tgz (KorrekturRelease für v1.1.0)
• de.abda.erezeptabgabedatenbasis-1.2.0.tgz
• de.abda.erezeptabgabedatenbasis-1.3.0.tgz
• de.abda.erezeptabgabedatenbasis-1.3.1.tgz (KorrekturRelease für v1.3.0)
• de.abda.erezeptabgabedaten-1.1.0.tgz (entfernt v0.9.7)
• de.abda.erezeptabgabedaten-1.1.1.tgz (entfernt v0.9.8)
• de.abda.erezeptabgabedaten-1.1.2.tgz (KorrekturRelease für v1.1.0)
• de.abda.erezeptabgabedaten-1.2.0.tgz
• de.abda.erezeptabgabedaten-1.3.0.tgz (entfernt v1.0.1)
• de.abda.erezeptabgabedaten-1.3.1.tgz
• de.abda.erezeptabgabedatenpkv-1.1.0.tgz (entfernt v1.0.1)
• de.abda.erezeptabgabedatenpkv-1.2.0.tgz (KorrekturRelease für v1.1.0)
• de.gkvsv.erezeptabrechnungsdaten-1.0.4.tgz
• de.gkvsv.erezeptabrechnungsdaten-1.0.5.tgz
• de.gkvsv.erezeptabrechnungsdaten-1.0.6.tgz
• de.gkvsv.erezeptabrechnungsdaten-1.1.0.tgz
• de.gkvsv.erezeptabrechnungsdaten-1.2.0.tgz
• de.gkvsv.erezeptabrechnungsdaten-1.3.0.tgz

• Add Package dav.kbv.sfhir.cs.vs-1.0.2-json.tgz (KBV Schlüsseltabellen - externe CodeSytseme/ValueSets)

• Add Package dav.kbv.sfhir.cs.vs-1.0.3-json.tgz (KBV Schlüsseltabellen - externe CodeSytseme/ValueSets)

  • Edit DARREICHUNGSFORM v1.09 ab 01.04.2022

• Add Package dav.kbv.sfhir.cs.vs-1.0.4-json.tgz (KBV Schlüsseltabellen - externe CodeSytseme/ValueSets)

  • Edit DARREICHUNGSFORM v1.10 ab 01.07.2022

• Add Package dav.kbv.sfhir.cs.vs-1.0.5-json.tgz (KBV Schlüsseltabellen - externe CodeSytseme/ValueSets)

  • Add SFHIR_EAU_AU_ERROR_KASSE v1.00 ab 01.07.2023

• Add Package dav.kbv.sfhir.cs.vs-1.0.6-json.tgz (KBV Schlüsseltabellen - externe CodeSytseme/ValueSets)

  • Edit DARREICHUNGSFORM v1.11 ab 01.04.2023

• Add Package dav.kbv.sfhir.cs.vs-1.0.7-json.tgz (KBV Schlüsseltabellen - externe CodeSytseme/ValueSets)

  • Edit DARREICHUNGSFORM v1.12 ab 01.07.2023

• delete examples in Packages

• de.gematik.erezept-workflow.r4-1.0.3-1.tgz

  • Delete ProFile StructureDefinition-ChargeItem-erxChargeItem.json (keine Relevanz - future use)

• kbv.ita.erp-1.0.1.tgz

  • Change Profile KBV_PR_ERP_Prescription.json (MedicationRequest.insurance = "type":[{"code":"Reference","targetProfile":["https://fhir.kbv.de/StructureDefinition/KBV_PR_FOR_Coverage|1.0.3"]}])

• ACHTUNG! FIX Issue in de.abda.erezeptabgabedatenbasis-1.1.0.tgz -> siehe ChangeLog.md - Version 0.9.6

• kbv.basis-1.3.0.tgz (ACHTUNG! expansion SNOMED entfernt...)

  • KBV_VS_Base_Diagnosis_SNOMED_CT.json
  • KBV_VS_Base_Procedure_SNOMED_CT.json
  • KBV_VS_Base_Allergy_Substance_SNOMED_CT.json
  • KBV_VS_Base_Device_SNOMED_CT.json

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.