BfArM Digitale Anwendungen
3.0.2-RC1 - draft
BfArM Digitale Anwendungen - Local Development build (v3.0.2-RC1) 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.
https://diga.bfarm.de/api/fhir/v3.0/https://diga.bfarm.de/api/fhir/test/https://dipa.bfarm.de/api/fhir/v3.0/https://dipa.bfarm.de/api/fhir/test/https://hiis.bfarm.de/api/fhir/v3.0/https://hiis.bfarm.de/api/fhir/test/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 ist auf dem Server aktiviert. Es werden nur GET-Requests unterstützt. Die Implementierung ist experimentell. Es wird keine weitere Unterstützung durch das BfArM dafür angeboten.
Weitere Informationen finden Sie hier: www.hl7.org/fhir/graphql.html