G01: Abruf einer Liste mit allen DiGA des DiGA-Verzeichnisses

Beschreibung

Dieser grundlegende Anwendungsfall beschreibt den Abruf einer Liste mit allen digitalen Gesundheitsanwendungen (DiGA), die im DiGA-Verzeichnis gelistet sind.

Beteiligte Akteure

• Alle Nutzerinnen / Nutzer der DiGA-API

Auslöser

• Nutzerin / Nutzer der DiGA-API möchte eine Liste mit allen verfügbaren DiGA abrufen und darstellen

Standardablauf

1. Nutzerin / Nutzer der DiGA-API fragt eine Liste mit allen Einträgen des DiGA-Verzeichnisses an
2. DiGA-API liefert die angefragte DiGA-Liste zurück
3. Nutzerin / Nutzer stellt die DiGA-Liste im individuellen Nutzungskontext dar

API-Abfrage

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

Das zurückgelieferte Searchset ist FHIR-üblich paginiert. Im Element meta.total ist die Gesamtzahl der Ergebnisse über alle Seiten sichtbar. Der FHIR®-Server benutzt standardmäßig eine Seitengröße von 20 Elementen. Das bedeutet der Aufruf liefert nur die erste Seite der Ergebnisse (20 DiGA).

Die weiteren Seiten sind über das link-Element verlinkt. Durch Angabe des _count-Parameters lässt sich die Anzahl der Ergebnisse je Seite einstellen.

Auf externen System darf die zurückgelieferte id der DeviceDefinition-Ressource sowie aller weiterer Ressourcen nicht gespeichert werden. Stattdessen dürfen auf externen System nur die in den Ressourcen hinterlegten identifier gespeichert werden.

G02: Abruf aller Daten zu einer spezifischen DiGA

Beschreibung

Dieser Anwendungsfall beschreibt den Abruf aller Daten zu einer spezifischen digitalen Gesundheitsanwendung (DiGA) aus dem DiGA-Verzeichnis. Diese Daten umfassen auch Daten zu einzelnen DiGA-Modulen und zugehörigen Verordnungseinheiten.

Beteiligte Akteure

• Alle Nutzerinnen / Nutzer der DiGA-API

Auslöser

• Nutzerin / Nutzer der DiGA-API möchte Daten zu einer spezifischen DiGA abrufen und darstellen

Standardablauf

1. Nutzerin / Nutzer der DiGA-API fragt alle Daten zu einer spezifischen DiGA an
2. DiGA-API liefert die angefragten Daten zur DiGA zurück
3. Nutzerin / Nutzer verarbeitet die Daten zur DiGA im individuellen Nutzungskontext

API-Abfrage

Zunächst ist über den extern gespeicherten identifier der DiGA die interne id der Ressource in der FHIR®-API zu ermitteln.

In diesem Beispiel ist der gespeicherte identifier die DiGA-ID "00294":

https://diga.bfarm.de/api/fhir/v2.0/DeviceDefinition?identifier=https://fhir.bfarm.de/Identifier/DigaId|00294

Aus der zurückgelieferten Ressource ist dann die interne id für die folgende Operation zu verwenden. In diesem Beispiel die "1":

GET https://diga.bfarm.de/api/fhir/v2.0/DeviceDefinition/1/$everything

Diese Operation benutzt keine Paginierung.

Hinweis: Je nach verwendeter Software ist eine URL-Kodierung der Parameter notwendig: DigaId%7C00294.

G03: Abruf einer Verordnungseinheit zu einer PZN

Beschreibung

Dieser Anwendungsfall beschreibt den Abruf einer Verordnungseinheit zu einer gegebenen PZN.

Beteiligte Akteure

• Alle Nutzerinnen / Nutzer der DiGA-API

Auslöser

• Nutzerin / Nutzer der DiGA-API möchte Daten zu einer spezifischen PZN abrufen und darstellen

Standardablauf

1. Nutzerin / Nutzer der DiGA-API fragt Verordnungseinheit zur PZN an
2. DiGA-API liefert die entsprechende Verordnungseinheit zurück
3. Nutzerin / Nutzer verarbeitet die Daten zur Verordnungseinheit im individuellen Nutzungskontext

API-Abfrage

Mittels der PZN und des Suchparameters für code kann die Ressource der entsprechenden Verordnungseinheit ermittelt werden:

GET https://diga.bfarm.de/api/fhir/v2.0/ChargeItemDefinition?code=http://fhir.de/CodeSystem/ifa/pzn|19192829

Hinweis: Je nach verwendeter Software ist eine URL-Kodierung der Parameter notwendig: pzn%7C19192829.

G04: Abruf sämtlicher DiGA-Daten

Beschreibung

Dieser Anwendungsfall beschreibt den Abruf aller im DiGA-Verzeichnis gespeicherten Daten zu Digitalen Gesundheitsanwendungen (DiGA). Dies ist die effizienteste Methode, um sämtliche DiGA-Daten zentral abzurufen.

Beteiligte Akteure

• Alle Nutzerinnen und Nutzer der DiGA-API

Auslöser

• Eine Nutzerin oder ein Nutzer der DiGA-API möchte sämtliche DiGA-Daten abrufen, z. B. zur Weiterverarbeitung oder Darstellung in einem eigenen System.

Standardablauf

1. Die Nutzerin oder der Nutzer fragt alle Daten, gruppiert nach Profil, über die DiGA-API ab.
2. Die DiGA-API liefert die Daten entsprechend gruppiert zurück.
3. Die empfangenen Daten werden im jeweils vorgesehenen Nutzungskontext weiterverarbeitet.

API-Abfrage

Für den vollständigen Datenabruf sind insgesamt sieben API-Requests erforderlich. Die Daten werden dabei nach den jeweiligen FHIR-Profilen gruppiert abgerufen (siehe auch Logisches Datenmodell).

• Alle Verzeichniseinträge:

  https://diga.bfarm.de/api/fhir/v2.0/CatalogEntry?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppCatalogEntry

• Alle DiGA-Hersteller:

  https://diga.bfarm.de/api/fhir/v2.0/Organization?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppManufacturer

• Alle DiGA:

  https://diga.bfarm.de/api/fhir/v2.0/DeviceDefinition?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthApp

• Alle DiGA-Module:

  https://diga.bfarm.de/api/fhir/v2.0/DeviceDefinition?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppModule

• Alle Verordnungseinheiten:

  https://diga.bfarm.de/api/fhir/v2.0/ChargeItemDefinition?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppPrescriptionUnit

• Alle DiGA-Antwortdatensätze:

  https://diga.bfarm.de/api/fhir/v2.0/QuestionnaireResponse?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppQuestionnaireResponse

• Alle DiGA-Fragenkataloge:

  https://diga.bfarm.de/api/fhir/v2.0/Questionnaire?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppQuestionnaire

Hinweise

• Je nach eingesetzter Software müssen die URL-Parameter gegebenenfalls kodiert werden. Beispiel kodiert: ?_count=1000&_profile=https%3A%2F%2Ffhir.bfarm.de%2FStructureDefinition%2FHealthAppCatalogEntry.

• In externen Systemen dürfen die von der API gelieferten id-Werte der Ressourcen nicht gespeichert werden. Stattdessen dürfen nur die in den Ressourcen enthaltenen identifier verwendet und gespeichert werden.