​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

FHIR® – Fundamentals

For basic documentation on FHIR®, please refer to the official HL7® documentation. This is assumed to be known in the following.

Base URLs

DiGA

• Current version: https://diga.bfarm.de/api/fhir/v3.0/
• Test system: https://diga.bfarm.de/api/fhir/test/

DiPA

• Current version: https://dipa.bfarm.de/api/fhir/v3.0/
• Test system: https://dipa.bfarm.de/api/fhir/test/

HIIS

• Current version: https://hiis.bfarm.de/api/fhir/v3.0/
• Test system: https://hiis.bfarm.de/api/fhir/test/

Authentication

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

Content Types

You can use the Accept header to control the MIME type in which data are returned by the API. The following values are supported:

• JSON: application/fhir+json
• XML: application/fhir+xml

Further information can be found here: www.hl7.org/fhir/http.html#mime-type

Meta Information

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.

Cardinality and Must-Support

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:

• A field with Must-Support and cardinality 0… is optional and may be populated.
• A field without Must-Support and cardinality 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

GraphQL is enabled on the server. Only GET requests are supported. The implementation is experimental. The BfArM does not provide any further support for it.

Further information can be found here: www.hl7.org/fhir/graphql.html