BfArM Digitale Anwendungen
3.1.0-TEST - draft
BfArM Digitale Anwendungen - Local Development build (v3.1.0-TEST) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Für eine grundlegende Dokumentation zu FHIR wird auf die offizielle Dokumentation von HL7 verwiesen. Diese wird hier als bekannt vorausgesetzt.
Die Aktuelle Version enthält die aktuellen Produktivdaten auf Basis der FHIR-Profilierung des zuletzt veröffentlichten FHIR-Pakets (derzeit Version 3.0). Der Zugriff darauf ist für DiGA und DiPA aktuell nur über das API-Antragsportal möglich.
Das Testsystem enthält die aktuellen Produktivdaten und kann zusätzlich weitere Einträge umfassen. Es wendet bereits die FHIR-Profilierung eines künftigen FHIR-Pakets an (siehe Changelog). Nicht alle im Changelog genannten Änderungen werden zwingend in der nächsten FHIR-Paketversion veröffentlicht; einzelne Anpassungen können auch über mehrere Releases verteilt erfolgen.
Die Sandbox enthält Testdaten zum Erhalt der für die Kommunikation zwischen DiGA und Hilfsmittelschnittstellen erforderlichen Informationen. Die Befüllung und Nutzung der Sandbox steht allen Herstellern mit mindestens einer gelisteten Digitalen Gesundheitsanwendung (DiGA) bzw. allen Herstellern von Hilfsmitteln und Implantaten (HiMi) offen, die das Meldeportal für Hilfsmittel- und Implantat-Schnittstellen (HIIS) nutzen.
https://diga.bfarm.de/api/fhir/v3.0/https://diga.bfarm.de/api/fhir/sandbox/https://diga.bfarm.de/api/fhir/test/Hinweis: In der Aktuellen Version werden derzeit noch keine Daten bereitgestellt.
https://dipa.bfarm.de/api/fhir/v3.0/https://dipa.bfarm.de/api/fhir/test/Hinweis: In der Aktuellen Version und im Testsystem werden derzeit noch keine Daten bereitgestellt.
https://hiis.bfarm.de/api/fhir/v3.0/https://hiis.bfarm.de/api/fhir/sandbox/https://hiis.bfarm.de/api/fhir/test/Wenn Sie statt der expliziten Versions-URL die Basis-URL ohne Versionssegment verwenden (https://diga.bfarm.de/api/fhir/, https://dipa.bfarm.de/api/fhir/, https://hiis.bfarm.de/api/fhir/), antwortet der Server mit einem HTTP-Redirect auf die jeweils aktuelle API-Version. Derzeit ist das v3.0; bei künftigen Hauptversionen ändert sich das Ziel des Redirects entsprechend.
Die API nutzt zur Authentifizierung des API-Nutzers dessen individuelles Bearer Token. Sie können dieses im elektronischen API-Antragsportal einsehen.
Schützen Sie das Token unbedingt vor dem Zugriff durch Dritte und behandeln Sie es so sensibel wie Ihre Zugangsdaten zum Onlinebanking!
Wenn Sie nur die Basis-URL ohne Angabe einer Ressource oder Operation aufrufen und im Header ein gültiges Bearer Token übermitteln, erhalten Sie folgende Fehlermeldung (400 Bad Request):
This is the base URL of FHIR server. Unable to handle this request, as it does not contain a resource type or operation name.
Erst durch Übermittlung der gewünschten FHIR-Ressource und ggf. weiterer Parameter liefert die jeweilige API entsprechende Daten zurück.
Hinweis: Das Token ist als Bearer Token im Authorization-Header (siehe auch RFC 6750) zu übergeben.
Beispiel:
Authorization: Bearer 00000000-0000-0000-0000-000000000000
Über das Headerfeld Accept können Sie steuern, in welchem MIME-Typ die Daten über die API ausgegeben werden sollen. Möglich sind folgende Werte:
application/fhir+jsonapplication/fhir+xmlWeitere Informationen finden Sie hier: www.hl7.org/fhir/http.html#mime-type
id, versionId und lastUpdated haben keine fachliche Aussagekraft. Diese rein technischen Eigenschaften der Datensätze auf dem FHIR-Server können sich jederzeit ändern und dürfen nicht extern gespeichert werden. Die Meta-Informationen sind nicht Bestandteil der API-Daten und können nicht manuell geändert werden.
Als eindeutiger Identifier einer Ressource gilt allein die DiGA-ID, DiPA-ID bzw. HIIS-ID, die im identifier-Feld ausgelesen werden kann. Fachliche Datums- und Zeitangaben sind allein in den profilierten Feldern zu finden. Beispielsweise sind die Gültigkeitsdaten eines Verzeichniseintrages in CatalogEntry.validityPeriod gespeichert, für die Verordnungseinheiten bzw. Anwendungseinheiten in ChargeItemDefinition.effectivePeriod.
Das Must-Support-Flag (S) gibt an, welche Elemente prinzipiell über die Schnittstelle bereitgestellt werden können. Allerdings bedeutet dies nicht, dass diese Elemente in jedem Datensatz befüllt sind; dafür ist allein die Kardinalität entscheidend.
Alle Elemente, deren Kardinalität mit 0 beginnt, sind immer optional. Datensätze müssen diese Angaben nicht enthalten, um korrekt zu sein.
Das bedeutet:
0… ist optional und kann befüllt sein.0… ist aus den Basisprofilen übernommen, wird aber nie befüllt.Hintergrund dieser Vorgehensweise ist, dass somit keine Felder aus den Basisprofilen gestrichen werden müssen und bei einer potentiellen Erweiterung der Profilierung keine Inkompatibilitäten entstehen.
GraphQL wird nicht unterstützt.