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
For basic documentation on FHIR, please refer to the official HL7 documentation. This is assumed to be known in the following.
The Current Version contains the current production data based on the FHIR profiling of the most recently published FHIR package (currently version 3.0). Access is currently available for DiGA and DiPA only via the API application portal.
The Test System contains the current production data and may additionally include further entries. It already applies the FHIR profiling of a future FHIR package (see Changelog). Not all changes listed in the changelog are necessarily published in the next FHIR package version; individual adjustments may also be rolled out across multiple releases.
The Sandbox contains test data for obtaining the information required for communication between DiGA and medical aid interfaces. Populating and using the sandbox is available to all manufacturers with at least one listed digital health application (DiGA) or to all manufacturers of medical aids and implants (HiMi) who use the HIIS reporting portal for medical aid and implant interfaces (HIIS).
https://diga.bfarm.de/api/fhir/v3.0/https://diga.bfarm.de/api/fhir/sandbox/https://diga.bfarm.de/api/fhir/test/Note: The Current Version does not yet provide any data.
https://dipa.bfarm.de/api/fhir/v3.0/https://dipa.bfarm.de/api/fhir/test/Note: The Current Version and Test System do not yet provide any data.
https://hiis.bfarm.de/api/fhir/v3.0/https://hiis.bfarm.de/api/fhir/sandbox/https://hiis.bfarm.de/api/fhir/test/If you use the base URL without a version segment instead of the explicit versioned URL (https://diga.bfarm.de/api/fhir/, https://dipa.bfarm.de/api/fhir/, https://hiis.bfarm.de/api/fhir/), the server responds with an HTTP redirect to the currently active API version. At present that is v3.0; when new major versions are introduced, the redirect target will change accordingly.
The API uses the API user’s individual Bearer token for authentication. You can view it in the electronic API application portal.
Keep the token strictly confidential and treat it as sensitively as you would your online banking credentials!
If you call only the base URL without specifying a resource or operation and send a valid Bearer token in the header, you will receive the following error message (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.
Only when you submit the desired FHIR resource and, if applicable, further parameters will the respective API return the corresponding data.
Note: The token must be sent as a Bearer token in the Authorization header (see also RFC 6750).
Example:
Authorization: Bearer 00000000-0000-0000-0000-000000000000
You can use the Accept header to control the MIME type in which data are returned by the API. The following values are supported:
application/fhir+jsonapplication/fhir+xmlFurther information can be found here: www.hl7.org/fhir/http.html#mime-type
id, versionId and lastUpdated have no semantic meaning. These purely technical properties of the data sets on the FHIR server may change at any time and must not be stored externally. The meta information is not part of the API data and cannot be changed manually.
The only unique identifier of a resource is the DiGA ID, DiPA ID or HIIS ID, which can be read from the identifier field. Semantic date and time information is found only in the profiled fields. For example, the validity period of a catalog entry is stored in CatalogEntry.validityPeriod, and for prescription units or application units in ChargeItemDefinition.effectivePeriod.
The Must-Support flag (S) indicates which elements can in principle be provided via the interface. However, this does not mean that these elements are populated in every data set; cardinality alone determines that.
All elements whose cardinality starts with 0 are always optional. Data sets do not need to contain this information to be valid.
This means:
0… is optional and may be populated.0… is inherited from the base profiles but will never be populated.The reason for this approach is that no fields need to be removed from the base profiles and no incompatibilities arise when the profiling is potentially extended.
GraphQL is not supported.