Generische Anwendungsfälle

Inhalt

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/v3.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/v3.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/v3.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/v3.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/v3.0/CatalogEntry?_count=1000&_profile=https://fhir.bfarm.de/StructureDefinition/HealthAppCatalogEntry

  • Alle DiGA-Hersteller:

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

  • Alle DiGA:

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

  • Alle DiGA-Module:

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

  • Alle Verordnungseinheiten:

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

  • Alle DiGA-Antwortdatensätze:

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

  • Alle DiGA-Fragenkataloge:

    https://diga.bfarm.de/api/fhir/v3.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.

G05: Abruf der Vertrauensattribute einer DiGA

Beschreibung

Dieser Anwendungsfall beschreibt den Abruf der Vertrauensattribute einer digitalen Gesundheitsanwendung (DiGA) für die Kommunikation mit Hilfsmittelschnittstellen (HIIS). Die Vertrauensattribute werden über die Extension HealthAppHiisTrustAttributes in der HealthApp-Ressource bereitgestellt und enthalten Informationen wie Client-Zertifikate, Client-ID und Redirect-URI.

Beteiligte Akteure

  • Alle Nutzerinnen / Nutzer der DiGA-API, die HIIS-Integrationen implementieren

Auslöser

  • Nutzerin / Nutzer der DiGA-API benötigt die Vertrauensattribute einer spezifischen DiGA für die HIIS-Integration

Standardablauf

  1. Nutzerin / Nutzer der DiGA-API fragt die HealthApp-Ressource zu einer spezifischen DiGA an
  2. DiGA-API liefert die HealthApp-Ressource mit den Vertrauensattributen zurück
  3. Nutzerin / Nutzer extrahiert die Vertrauensattribute aus der Extension HealthAppHiisTrustAttributes für die HIIS-Integration

API-Abfrage

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

GET https://diga.bfarm.de/api/fhir/v3.0/DeviceDefinition?identifier=https://fhir.bfarm.de/Identifier/DigaId|00294&_profile=https://fhir.bfarm.de/StructureDefinition/HealthApp

Die zurückgelieferte HealthApp-Ressource enthält die Vertrauensattribute direkt in der Extension HealthAppHiisTrustAttributes. Diese Extension kann folgende Elemente enthalten:

  • extension[clientCertificates]: Client-Zertifikate als Base64-kodierte Binärdaten (0..*)
  • extension[clientId]: Client-Identifikator für HIIS als URI (0..1)
  • extension[redirectUri]: Redirect-URI für HIIS als URI (0..1)

Hinweise

  • Je nach verwendeter Software ist eine URL-Kodierung der Parameter notwendig, beispielsweise DigaId%7C00294 statt DigaId|00294.
  • Auf externen Systemen darf die zurückgelieferte id der DeviceDefinition-Ressource nicht gespeichert werden. Stattdessen dürfen nur die in den Ressourcen hinterlegten identifier gespeichert werden.
  • Die Vertrauensattribute sind nur für DiGA verfügbar, nicht für DiPA.
  • Die Extension HealthAppHiisTrustAttributes ist optional und muss nicht in jeder DiGA vorhanden sein.