​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

DiPA – Use Cases

The returned id values of resources must not be stored on external systems, as they may change in new versions of the API. Instead, the identifier values stored in the resources must be used.

Depending on the software used, URL encoding of parameters may be required, for example DipaId%7C00123 instead of DipaId|00123.

The results returned by the API are paginated in accordance with FHIR. The total number of results across all pages is available in the meta.total element. The FHIR server uses a default page size of 20 elements. Further pages are linked via the link element. The number of results per page can be set using the _count parameter.

Retrieval of DiPA Data

Retrieval of All Digital Nursing Applications

Description

This use case describes the retrieval of all DiPA entries (profile HealthApp).

Standard Flow

1. Search request with the canonical of the profile as _profile parameter
2. DiPA API returns the found DiPA entries

API Request

GET https://dipa.bfarm.de/api/fhir/v3.0/DeviceDefinition?_profile=https://fhir.bfarm.de/StructureDefinition/HealthApp

Retrieval of All Resources

Retrieval of All Data of a Specific Digital Nursing Application

Description

This use case describes the retrieval of all data of a specific Digital Nursing Application (DiPA) from the DiPA directory. The data include the catalog entry (profile HealthAppCatalogEntry), the Digital Nursing Application (profile HealthApp), the DiPA manufacturer (profile HealthAppManufacturer), the DiPA modules (profile HealthAppModule), the application units (profile HealthAppPrescriptionUnit), and the DiPA questionnaire response dataset (profile HealthAppQuestionnaireResponse). It is assumed that the DiPA has already been determined by a previous search and the internal id is known.

Standard Flow

1. Call of the $everything operation with the internal id of the previously determined DiPA

API Request

GET https://dipa.bfarm.de/api/fhir/v3.0/DeviceDefinition/{id}/$everything

Example (internal id "1"):

GET https://dipa.bfarm.de/api/fhir/v3.0/DeviceDefinition/1/$everything

This operation returns a bundle of type searchset with all resources belonging to the DiPA. When called with the internal id of a DiPA module, all resources of the associated DiPA are also returned, not only those belonging to the DiPA module.

The operation does not use pagination.

Retrieval of All DiPA Data

Description

This use case describes the retrieval of all data stored in the DiPA directory. This is the most efficient method to retrieve all DiPA data centrally. Seven API requests are required, grouped by the respective FHIR profiles (see Information Model).

Standard Flow

1. Search requests with the canonical of the respective profiles as _profile parameter and a sufficiently high _count parameter
2. DiPA API returns the found entries

API Request

• All catalog entries (profile HealthAppCatalogEntry):

GET https://dipa.bfarm.de/api/fhir/v3.0/CatalogEntry?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppCatalogEntry

• All DiPA manufacturers (profile HealthAppManufacturer):

GET https://dipa.bfarm.de/api/fhir/v3.0/Organization?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppManufacturer

• All DiPA (profile HealthApp):

GET https://dipa.bfarm.de/api/fhir/v3.0/DeviceDefinition?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthApp

• All DiPA modules (profile HealthAppModule):

GET https://dipa.bfarm.de/api/fhir/v3.0/DeviceDefinition?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppModule

• All application units (profile HealthAppPrescriptionUnit):

GET https://dipa.bfarm.de/api/fhir/v3.0/ChargeItemDefinition?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppPrescriptionUnit

• All DiPA questionnaire response datasets (profile HealthAppQuestionnaireResponse):

GET https://dipa.bfarm.de/api/fhir/v3.0/QuestionnaireResponse?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppQuestionnaireResponse

• All DiPA questionnaires (profile HealthAppQuestionnaire):

GET https://dipa.bfarm.de/api/fhir/v3.0/Questionnaire?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppQuestionnaire

Retrieval of Change Status

Retrieval of the Change Status of the DiPA Directory

Description

This use case describes the retrieval of the timestamp of the last change in the entire DiPA directory. The operation returns a Parameters resource with the output parameters lastModified (last change across all resources in the directory) and lastModifiedHealthApp (last change of a HealthApp resource).

Standard Flow

1. Call of the $status operation at system level

API Request

GET https://dipa.bfarm.de/api/fhir/v3.0/$status

Retrieval of the Change Status of a DiPA Directory Entry

Description

This use case describes the retrieval of the timestamp of the last change for a single DiPA directory entry. The operation returns a Parameters resource with the output parameters lastModified (last change across all resources belonging to the entry) and lastModifiedHealthApp (last change of the associated HealthApp resource). It is assumed that the DiPA has already been determined by a previous search and the internal id is known. When called with the internal id of a DiPA module, the change status of the entire associated directory entry is returned.

Standard Flow

1. Call of the $status operation with the internal id of the previously determined DiPA

API Request

GET https://dipa.bfarm.de/api/fhir/v3.0/DeviceDefinition/{id}/$status

Example (internal id "1"):

GET https://dipa.bfarm.de/api/fhir/v3.0/DeviceDefinition/1/$status