FHIR-Konformitätserklärung

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

FHIR-Speicher in der Cloud Healthcare API unterstützen mehrere Versionen der von Health Level 7 International (HL7) veröffentlichten FHIR-Spezifikation.

Die v1 API unterstützt die folgenden Versionen:

Wenn Sie einen FHIR-Speicher erstellen, geben Sie die FHIR-Version als Parameter für die Methode fhirStores.create an. Sie können die FHIR-Version nicht mehr ändern, nachdem der Store erstellt wurde.

Die API-Schnittstelle zu jedem Speicher entspricht der FHIR-Version dieses Speichers. Beispielsweise unterscheidet sich die DSTU2 conformance-Interaktion von der STU3 capabilities-Interaktion, aber beide teilen sich den REST-Pfad /fhir/metadata, sodass dieser Pfad basierend auf der FHIR-Version des Speichers unterschiedliche Antworten zurückgibt.

Funktionen, die in späteren FHIR-Versionen hinzugefügt wurden, sind in Geschäften mit früheren FHIR-Versionen verfügbar, wenn sie nicht inkompatibel sind. Die Interaktion patch ist beispielsweise in einem DSTU2-Speicher verfügbar, obwohl diese Interaktion erst ab STU3 definiert ist.

Details zu den unterstützten Funktionen in der v1 API nach FHIR-Version

R4

Die Capability-Anweisung des Servers gibt an, welche Teile der Spezifikation unterstützt werden.

  • Speichern und Abrufen aller R4-Ressourcen, einschließlich Unterstützung für Erweiterungselemente. Die API akzeptiert, speichert und gibt Erweiterungen für jedes Datenelement zurück.
  • Es werden alle Methoden in der RESTful API unterstützt, die den JSON-Inhaltstyp verwenden, außer:
    • Die Verlaufsinteraktionen auf Typ- und Systemebene, die den Verlauf für mehrere Ressourcen abrufen, werden nicht unterstützt. Der Ressourcenverlauf kann jeweils nur für eine Ressource abgerufen werden.
    • Die Interaktion Batch/Transaktion unterstützt keine Such- oder Patchvorgänge innerhalb des Bundles.
  • Die Validierung und Erzwingung von Profilen ist in der v1beta1 API verfügbar.
  • Benutzerdefinierte Suchparameter, darunter auch Suchvorgänge mit Erweiterungselementen, werden in der v1beta1 API unterstützt.
  • Alle Suchfunktionen werden unterstützt, außer:

    • Die Suchparameter Group-characteristic-value, Location-near, Bundle-composition und Bundle-message werden nicht unterstützt.
    • Suchparameter, die einen Lautausgleich durchführen, werden nicht unterstützt.
    • Die Suchergebnisparameter _contained, _containedType, _summary=count und _summary=true werden nicht unterstützt.
    • Der spezielle Suchparameter _content durchsucht alle Felder der Ressource, auf die sich Suchparameter beziehen. Felder, die nicht durchsucht werden können, werden ausgeschlossen. Es unterstützt keine expliziten AND (Begriffe werden implizit mit AND kombiniert) oder Klammern.
    • Die speziellen Suchparameter _query, _filter und _list werden nicht unterstützt.
    • Der _sort-Parameter wird bei Feldern mit wiederkehrenden Elementen nach dem ersten Element sortiert. Dies unterscheidet sich von der Spezifikation. Alle unterstützten Suchparameter sind für _sort geeignet, mit Ausnahme des speziellen Suchparameters _content.
    • Der Modifikator für die Tokensuche :of-type und der Modifikator für die Referenzsuche :identifier werden nicht unterstützt.
    • Kanonische Referenzsuchen werden nicht unterstützt. Kanonische Referenzen werden wie normale Referenzen behandelt.
    • Wenn Sie den Parameter _type verwenden, können nur die üblichen Suchparameter (für alle Ressourcen) verwendet werden, und nicht die Schnittmenge der angegebenen Ressourcentypen.
    • Die folgende Teilmenge von zusammengesetzten Suchparametern wird unterstützt:

      • DocumentReference-relationship
      • Observation-code-value-concept
      • Observation-code-value-date
      • Observation-code-value-quantity
      • Observation-code-value-string
      • Observation-combo-code-value-concept
      • Observation-combo-code-value-quantity
      • Observation-component-code-value-concept
      • Observation-component-code-value-quantity

      Die übrigen zusammengesetzten Suchparameter werden nicht unterstützt.

    • Für die Suche mit der POST-Methode werden keine application/x-www-form-urlencoded-Parameter im Anfragetext akzeptiert.

Folgende Bereiche werden nicht unterstützt:

  • Die meisten erweiterten Vorgänge sind nicht implementiert.
  • Der XML-Inhaltstyp wird nicht unterstützt.
  • Der Patch-Vorgang unterstützt kein XML-Patch oder FHIRPath-Patch.
  • Die HTTP HEAD-Anfragen werden nicht unterstützt.
  • Der Endpunkt ExecuteBundle akzeptiert keine history-Sets.

STU3

Die Capability-Anweisung des Servers gibt an, welche Teile der Spezifikation unterstützt werden.

  • Das Speichern und Abrufen aller STU3-Ressourcen wird unterstützt, einschließlich der Unterstützung von Erweiterungselementen. Die API akzeptiert, speichert und gibt Erweiterungen für jedes Datenelement zurück.
  • Alle Methoden in der RESTful API, die den JSON-Inhaltstyp verwenden, werden unterstützt, außer:

    • Die Verlaufsinteraktionen auf Typ- und Systemebene, die den Verlauf für mehrere Ressourcen abrufen, werden nicht unterstützt. Der Ressourcenverlauf kann jeweils nur für eine Ressource abgerufen werden.
    • Die Interaktion Batch/Transaktion unterstützt keine Suchvorgänge innerhalb des Bundles.
  • Die Validierung und Erzwingung von Profilen ist in der v1beta1 API verfügbar.

  • Benutzerdefinierte Suchparameter, darunter auch Suchvorgänge mit Erweiterungselementen, werden in der v1beta1 API unterstützt.

  • Alle Suchfunktionen werden unterstützt, außer:

    • Die Suchparameter Group-characteristic-value, Sequence-coordinate, Location-near, Location-near-distance, Bundle-composition und Bundle-message werden nicht unterstützt.
    • Suchparameter, die einen Lautausgleich durchführen, werden nicht unterstützt.
    • Die Suchergebnisparameter _contained, _containedType, _summary=count und _summary=true werden nicht unterstützt.
    • Der spezielle Suchparameter _content durchsucht alle Felder der Ressource, auf die Suchparameter verweisen. Felder, die nicht durchsucht werden können, werden ausgeschlossen. Es unterstützt keine expliziten AND (Begriffe werden implizit mit AND kombiniert) oder Klammern.
    • Die speziellen Suchparameter _query, _filter und _list werden nicht unterstützt.
    • Der _sort-Parameter wird bei Feldern mit wiederkehrenden Elementen nach dem ersten Element sortiert. Dies unterscheidet sich von der Spezifikation. Alle unterstützten Suchparameter sind für _sort geeignet, mit Ausnahme des speziellen Suchparameters _content.
    • Für die Suche mit der POST-Methode werden keine application/x-www-form-urlencoded-Parameter im Anfragetext akzeptiert.

Folgende Bereiche werden nicht unterstützt:

  • Die meisten erweiterten Vorgänge sind nicht implementiert.
  • Der XML-Inhaltstyp wird nicht unterstützt.
  • Der Patch-Vorgang unterstützt kein XML-Patch oder FHIRPath-Patch.

DSTU2

Die Konformitätsanweisung des Servers gibt an, welche Teile der Spezifikation unterstützt werden.

  • Das Speichern und Abrufen aller DSTU2-Ressourcen wird unterstützt, einschließlich der Unterstützung von Erweiterungselementen. Die API akzeptiert, speichert und gibt Erweiterungen für jedes Datenelement zurück.
  • Es werden alle Methoden in der RESTful API unterstützt, die den JSON-Inhaltstyp verwenden, außer:
    • Die Verlaufsinteraktionen auf Typ- und Systemebene, die den Verlauf für mehrere Ressourcen abrufen, werden nicht unterstützt. Der Ressourcenverlauf kann jeweils nur für eine Ressource abgerufen werden.
    • Die Interaktion Batch/Transaktion unterstützt keine Suchvorgänge innerhalb des Bundles.
  • Die Validierung und Erzwingung von Profilen ist in der v1beta1 API verfügbar.
  • Alle Suchfunktionen werden unterstützt, außer:
    • Die Suchparameter Group-characteristic-value, Location-near, Location-near-distance, Bundle-composition, Bundle-message, Coverage-dependent und Coverage-sequence werden nicht unterstützt.
    • Für Erweiterungselemente definierte Suchparameter werden nicht unterstützt.
    • Suchparameter, die einen Lautausgleich durchführen, werden nicht unterstützt.
    • Die Suchergebnisparameter _contained, _containedType, _summary=count und _summary=true werden nicht unterstützt.
    • Der spezielle Suchparameter _content durchsucht alle Felder der Ressource, auf die Suchparameter verweisen. Felder, die nicht durchsucht werden können, werden ausgeschlossen. Es unterstützt keine expliziten AND (Begriffe werden implizit mit AND kombiniert) oder Klammern.
    • Die speziellen Suchparameter _query, _filter und _list werden nicht unterstützt.
    • Der _sort-Parameter wird bei Feldern mit wiederkehrenden Elementen nach dem ersten Element sortiert. Dies unterscheidet sich von der Spezifikation. Alle unterstützten Suchparameter sind für _sort geeignet, mit Ausnahme des speziellen Suchparameters _content.
    • Für die Suche mit der POST-Methode werden keine application/x-www-form-urlencoded-Parameter im Anfragetext akzeptiert.

Folgende Bereiche werden nicht unterstützt:

  • Die meisten erweiterten Vorgänge sind nicht implementiert.
  • Benutzerdefinierte Suchparameter werden für DSTU2 nicht unterstützt.
  • Der XML-Inhaltstyp wird nicht unterstützt.

Details zu Vorgängen außerhalb der veröffentlichten Spezifikation

  • Die FHIR gRPC API bietet eine RPC-Schnittstelle für FHIR mit dem gRPC-Framework. Es ist nicht standardisiert, befindet sich in der Entwicklung und unterstützt nicht alle FHIR-Methoden.
  • Die Konfiguration des FHIR-Speichers enthält eine Option, mit der ein benutzerdefiniertes Pub/Sub-Thema über alle Änderungen an Ressourcen im Speicher benachrichtigt wird. Dieser Benachrichtigungsmechanismus gilt für alle Cloud Healthcare API-Speicher und ist nicht dafür vorgesehen, die Funktionen des FHIR-Abos (DSTU2, STU3 und R4) zu ersetzen.
  • Der Exportvorgang des FHIR-Speichers in Cloud Storage-Ziele bietet nur einen Bulk-Export des gesamten Speichers. Es handelt sich nicht um eine Implementierung der Entwurfsspezifikation für FHIR-Bulk-Daten.
  • Der Importvorgang des FHIR-Speichers ist in der Spezifikation nicht definiert.
  • Der Vorgang Resource-purge, der historische Versionen von Ressourcen entfernt, ist in der Spezifikation nicht definiert. Diese API könnte sich in Zukunft ändern, wenn der Standardprozess oder andere FHIR-Implementierungen für diesen Anwendungsfall auf einer anderen API-Methode zusammenlaufen.