Dokumentation Fiyaware

Übersicht

Dieses Usermanual beschreibt die funktionalen Eigenschaften von Black Tusks FHIR Server. Fiyaware ermöglicht die schnelle und sichere Verarbeitung, Validierung und Verwaltung von großen Mengen an gesundheitsbezogenen beziehungsweise medizinischen Daten gemäß der HL7 FHIR Version 4.0.1. Fiyaware ist eine performante Python-Implementierung mit einer austauschbaren Speichereinheit (derzeit PostgreSQL DB). Der Server ermöglicht mit seiner zentralen FHIR Schnittstelle (API) sowohl den semantisch interoperablen Austausch von strukturierten Gesundheitsdaten als auch deren langfristige, sichere und kostengünstige Archivierung. Als modulare Datenmanagement- und Kommunikationsplattform gewährleistet Fiyaware die einfache und sichere Anbindung beziehungsweise Vernetzung externer Applikationen und Services, um eine evidenzbasierte Versorgung im gesamten Gesundheitssektor zu ermöglichen.

Fiyaware Server entdecken

Eine Instanz von Fiyaware Server ist innerhalb weniger Minuten aufgesetzt und einsatzbereit. Fiyaware kann entweder lokal oder in Cloud-Umgebungen wie Azure deployed werden, Docker und Kubernetes werden unterstützt.

Personalisierung und deployment

Nachdem die Entscheidung für eine Deployment-Art getroffen worden ist, kann Fiyaware Server individuell an die eigenen Bedürfnisse angepasst werden. Hierzu können in den Einstellungen zahlreiche Parameter angepasst werden, siehe dazu den Abschnitt Konfigurationsvariablen. Auch eine Authentifizierung über SMART on FHIR ist möglich, siehe den Abschnitt SMART on FHIR.

Weitere Informationen und Fragen

Sofern weitere Informationen, spezielle Features oder Unterstützung bei der Einbindung von Fiyaware Server in die eigene Systemlandschaft benötigt werden, stehen wir jederzeit unter der E-Mail-Adresse info@blacktusk.eu zur Verfügung.

Getting started

Allgemeine Installation

Fiyaware Server kann entweder lokal oder in Cloud-Umgebungen wie Azure oder AWS deployed werden, eine Instanz wird als Docker-Container zur Verfügung gestellt. Für weitere Informationen hierzu siehe Security and Tools - SMART on FHIR

Verwenden von Fiyaware Server mit HTTP-Clients

Fiyaware Server ist mit allen gängigen HTTP-Clients kompatibel, umfangreichere Kompatibilitätstests wurden bislang für Postman, Insomnia und Bruno durchgeführt.

Setting up Fiyaware Server

Deployment

Je nach Anwendungsfall kann Fiyaware Server auf mehrere verschiedene Arten konfiguriert und deployed werden. Dazu zählen das lokale Deployment oder das Deployment über einen Docker-Container, entweder ebenfalls lokal oder in die Cloud.

Lokales Deployment

Das lokale Deployment eignet sich insbesiondere für Entwicklungs- udn Testumgebungen, bei denen die schnelle Deployment-Zeit im Vordergrund steht. Es werden keine externe Infrastruktur und keine zusätzlichen Software-Tools benötigt, was das Deployment deutlich vereinfacht.

Deployment über Docker-Container

Das Deployment als Docker-Container eignet sich insbesondere für die einfache Integration mit minimalem Aufwand in bestehende CI/CD-Pipelines.

Einstellungen

Die Einstellungen von Fiyaware Server sind über eine Vielzahl an Variablen anpassbar, siehe hierzu das Kapitel Konfigurationsvariablen.

Logging

In den Einstellungen ist auch das Logging konfigurierbar. Eine Übersicht über die geloggten Daten und deren Beschreibung bietet das Kapitel Auditing und Logging.

Features

FHIR RESTful API

FHIR Versions

Zur Zeit unterstützt Fiyaware Server ausschließlich FHIR R4. EIne Unterstützung für FHIR R6 ist geplant, andere FHIR-Versionen können auf Kundenwunsch implementiert werden.

Unterstützte Datenformate

Fiyaware unterstützt die Datenformate JSON und XML. Es ist möglich, ein und dieselbe FHIR Ressource im JSON Format zum Server zu senden und im XML Format abzurufen (und umgekehrt).

Unterstützte FHIR Ressourcen

Fiyaware unterstützt alle FHIR Ressourcen der HL7 FHIR Version 4.0.1

Validierung von Ressourcen und Extensions

Fiyaware unterstützt die vollständige Validierung von Ressourcen inklusive Extension.

UUIDs

Der Server erlaubt die Verwendung von klein- und groß geschriebenen UUIDs.

FHIR CapabilityStatement

FHIR Funktionen, die von Fiyaware unterstützt werden, können über das CapabilityStatement des Servers abgerufen werden. Das CapabilityStatement enthält eine maschinen lesbare Beschreibung der implementierten FHIR Funktionalitäten wie CRUD (Create/Read/Update/Delete), individuelle und systemweite Suchparameter und Operatoren (auch kundenspezifische Operatoren) sowie eine Auflistung aller unterstützten FHIR Ressourcen.

GET \[baseUrl\]/metadata

Unterstützte Header

Fiyaware unterstützt die HTTP Header Parameter „content-type" und „accept".

Folgende MIME-types werden für "content-type"- und "accept"-Header unterstützt:

• JSON (per default)

  • JSON -- wird interpretiert als application/fhir+json

  • application/json -- wird interpretiert als application/fhir+json

  • text/json -- application/fhir+json

• XML

  • XML -- wird interpretiert als application/fhir+xml

  • application/xml -- wird interpretiert als application/fhir+xml

  • text/xml -- application/fhir+xml

Content-type

Mit dem content-type Parameter wird festgelegt, in welchem Eingangsformat die FHIR Ressource zum Server gesendet wird.

• Ist der content-type Parameter nicht angegeben, wird der default Wert JSON gesetzt.

• Ist der content-type Parameter angegeben aber unbekannt, wird ein 415 Unsupported Media Type Error Code zurückgegeben.

• Für FHIR Binary ist jeder content-type möglich, wird aber nicht auf Korrektheit geprüft.

Accept Header

Mit dem accept header wird das Format der vom Server zurückgegebenen HTTP-Request Antwort festgelegt.

• Ist der accept header nicht angegeben, wird der default Wert JSON gesetzt.

• Ist der accept header angegeben aber unbekannt, wird ein 406 http Status Code innerhalb eines OperationOutcome zurückgegeben.

• Für FHIR Binary ist jeder accept header möglich.

• Wird dem Request ein _format Parameter mitgegeben, dann überschreibt der _format Parameter den accept header.

Umgang mit internen und externen Referenzen

Fiyaware unterstützt für den Umgang mit Referenzen die beiden konfigurierbaren header Prefer: handling=strict und Prefer: handling=lenient.

Lenient

• Ist der default header

• Erlaubt die Verwendung folgender Referenzen:

  • [server url]/ResourceType/valid-uuid-that-can-point-to-nothing

  • Eine valide externe URL

Strict

• Erlaubt die Verwendung folgender Referenzen:

  • [server url]/ResourceType/valid-uuid-that-points-to-an-existing-resource

  • Eine valide externe URL

Return preference

Mit der return preference wird das Rückgabeformat der Ressourcen definiert.

Folgende return preferences sind erlaubt:

• return = minimal
• return = representation
• return = OperationOutome

Ist die return preference nicht angegeben wird der default Wert minimal gesetzt.

Ist die return preference fehlerhaft (= invalidValue) wird der default Wert minimal gesetzt.

Bei fehlerhaften Interaktionen wird immer ein OperationOutcome zurückgegeben.

Create

Eine FHIR-Ressource kann mit einem HTTP-POST Request erstellt werden:

POST [baseUrl]/resourceType

Beim Ausführen eines „create“ mit einer FHIR-Ressource muss der Request-Body befüllt sein und dem angegebenen „resourceType“ entsprechen. Beim Erstellen wird die Ressource auf Korrektheit validiert. Der Server „ignoriert” beim POST standardmäßig folgende Felder:

• id
• meta.versionId
• meta.lastUpdated

Die Felder „id“ und „versionId“ werden vom Server automatisch gesetzt oder aktualisiert. Das „lastUpdated“-Feld wird mit der aktuellen Serverzeit ersetzt. Mit Ausnahme der genannten Metadaten werden Ressourcen semantisch niemals verändert.

Conditional Create

Achtung: Das Conditional Create befindet sich momentan noch in einer „Trial Use“ Phase des FHIR-Standards. Der Status und die Funktionalität können in zukünftigen Versionen von FHIR noch Änderungen unterworfen sein. Die Verwendung erfolgt daher bis auf weiteres auf eigene Gefahr.

Fiyaware unterstützt Conditional Create, um eine Ressource neu erstellen, sofern sie noch nicht existiert.

Read

Eine FHIR-Ressource kann mit einem HTTP-GET Request gelesen werden:

GET [baseUrl]/resourceType/id

Die „read“-Methode gibt die geforderte FHIR-Ressource zurück.

Achtung: FHIR-Ressourcen werden vom Server beim Lesen niemals validiert.

Update

Eine am Server vorhandene FHIR-Ressource kann mit einem HTTP-PUT Request aktualisiert werden:

PUT [baseUrl]/resourceType/id

Beim Update einer Ressource via PUT müssen die Felder „resourceType“ als auch „id“ zwingend vorhanden sein. Zusätzlich muss der aktualisierte Ressourcen-Body mitübermittelt werden. Falls angegeben, ignoriert der Server folgende Felder:

• meta.versionId
• meta.lastUpdated

Das Feld „versionId“ wird vom Server selbst aktualisiert. Das Feld „lastUpdated“ wird durch die aktuelle Serverzeit ersetzt.

Conditional Update

Achtung: Das Conditional Update befindet sich momentan noch in einer „Trial Use“ Phase des FHIR-Standards. Der Status und die Funktionalität können in zukünftigen Versionen von FHIR noch Änderungen unterworfen sein. Die Verwendung erfolgt daher bis auf weiteres auf eigene Gefahr.

Fiyaware unterstützt Conditonal Update um eine Ressource auf Basis von Filter- bzw. Such- Kriterien (und nicht der id) aktualisieren zu können.

Update als Create

Fiyaware unterstützt die „update as create“-Funktion. Der Client sendet dabei einen PUT-Request inklusive FHIR-Ressource zum Server. Ist die angegebene Ressource bekannt, wird die am Server vorhandene Ressource aktualisiert. Ist die angegebene Ressource unbekannt, wird die Ressource erstellt und bekommt vom Server eine automatisch generierte id zugewiesen. Der Client kann die id der Ressource nicht selbst festlegen.

PUT [baseUrl]/resourceType/id

Delete

Das Löschen einer FHIR-Ressource kann mit dem http DELETE-Request durchgeführt werden:

DELETE [baseUrl]/resourceType/id

Die „delete“-Methode löscht die angegebene(n) Ressourcen. Die Ressource kann anschließend weder gelesen noch gesucht werden.

Achtung: Beim Löschen einer oder mehrere Ressourcen muss der Request-Body leer sein, andernfalls wird der http Statuscode „400 – Bad Request“ zurückgegeben.

Conditional Delete

Achtung: Das Conditional Delete befindet sich momentan noch in einer „Trial Use“ Phase des FHIR-Standards. Der Status und die Funktionalität können in zukünftigen Versionen von FHIR noch Änderungen unterworfen sein. Die Verwendung erfolgt daher bis auf weiteres auf eigene Gefahr.

Fiyaware unterstützt Conditonal Delete, um eine Ressource auf Basis von Filter- bzw. Suchkriterien löschen zu können.

Patch

Fiyaware unterstützt Patch für JSON. Im Vergleich zum regulären PUT werden hierbei ausschließlich die zu aktualisierenden Inhalte an den Server geschickt, nicht jedoch der gesamte Ressourcenkörper.

PATCH [baseUrl]/resourceType/id

Bei Patch muss der „content-type“-Header „application/json+patch+json“ gesetzt werden.

History

vread

Fiyaware unterstützt das versionsspezifische Lesen von Ressourcen. Die Version einer Ressource kann mit einem HTTP-GET Request abgefragt werden:

GET [baseUrl]/resourceType/id/_history/[vid]

Ressourcenebene

Liefert eine Liste aller historischen Versionen einer bestimmten Ressource:

GET [baseUrl]/resourceType/[id]/_history

Ressourcentypebene

Liefert eine Liste aller historischen Versionen eines bestimmten Ressourcentyps:

GET [baseUrl]/resourceType/_history

Globalebene

Liefert eine Liste aller historischen Versionen, die im System verfügbar sind

GET [baseUrl]/_history

Optionale Parameter

_since

Die historische Liste kann auf einen bestimmten Zeitraum beschränkt werden und nur Versionen von Ressourcen enthalten, die zu oder nach einem angegebenen Zeitpunkt erstellt wurden.

GET [baseUrl]/resourceType/_history?_since=2015-02-07T13:28:17.239+02:00

_count

Beschränkt und erweitert die Anzahl an Ergebnissen pro Seite.

GET [baseUrl]/_history?_count=3

Paging

Wenn mehr als 20 historische Ressourcen abgefragt werden, wird standardmäßig „Paging“ verwendet und 20 Ressourcen pro Seite angezeigt. Das Umblättern ist möglich.

Konfigurationsvariablen

Fiyaware Server ist individuell auf die eigenen Bedürfnisse anpassbar. Die folgende Liste gibt einen Überblick über die zu konfigurierenden Parameter:

Setting	Konfigurierbarer Default Wert	Beschreibung
FHIR_BASE_URL	http://fhir-engine:8000	Basis Server URL
LANGUAGE_CODE	en-us	Sprache
TIME_ZONE	Europe/Vienna	Zeitzone
ADMIN_URL	admin/	Kontrollpanel aufrufen
DATA_UPLOAD_MAX_SIZE_MB	10	Maximale Hochladegröße
DEFAULT_SUPERUSER_USERNAME	admin	OAuth2-Einstellung
DEFAULT_SUPERUSER_PASSWORT	fhir-engine	OAuth2-Einstellung
USE_AUTH	False	Authentifizierung aktivieren/deaktivieren
ACCESS_TOKEN_LIFETIME_MINUTES	5	Access Token-Einstellungen
REFRESH_TOKEN_LIFETIME_DAY	1	Access Token-Einstellungen
SLIDING_TOKEN_LIFETIME_MINUTES	5	Access Token-Einstellungen
SLIDING_TOKEN_REFRESH_LIFETIME_DAYS	1	Access Token-Einstellungen
CELERY_BROKER_URL	redis://redis:6379	Celery broker url
CELERY_TASKS_ALWAYS_EAGER	False	Für asynchrone Hintergrundaufgaben
USE_DB	postgresql	Datenbankeinstellungen
POSTGRES_USER	postgres	Datenbankeinstellungen
POSTGRES_PASSWORD	secure-postgres-password	Datenbankeinstellungen
DEFAULT_FHIR_MIMETYPE	application/fhir+json	FHIR API Einstellungen
DEFAULT_FHIR_VERSION	4.0.1	FHIR-Standardversion
DEFAULT_FHIR_PREFER	minimal	„prefer“-Standardeinstellung
MAX_RESOURCE_SIZE_MB	1	Maximale Ressourcengröße
MAX_BINARY_RESOURCE_SIZE_MB	5	Maximale Binarygröße
MAX_BUNDLE_RESOURCE_SIZE_MB	5	Maximale Bundlegröße
MAX_BUNDLE_RESOURCE_ENTRIES	100	Maximale Anzahl an Einträgen in Bundles
DEFAULT_PAGE_SIZE	20	„Paging Size“- Standardeinstellung
MAX_PAGE_SIZE	100	„Page Size“-Maximalwert definiert über „ _count“-Parameter
SUPPORT_HISTORY	True	Ein-/Ausschalten der „fhir history“
DEFAULT_HISTORY_PAGE_SIZE	20	„Paging Size“-Standardeinstellung bei Verwendung der „fhir history“
MAX_HISTORY_PAGE_SIZE	100	Maximale Anzahl an Entries im history Bundle
LOGSTASH_HOST	Localhost	Host
LOGSTASH_PORT	5000	Port
LOGSTASH_VERSION	1	Logstash für Logging
LOGSTASH_LEVEL	Info	Informationskonfiguration
LOGSTASH_MESSAGE_TYPE	logstash	Message Type

FHIR Bundle Handling

Fiyaware Server unterstützt FHIR Bundles mit den Typen "document", "message", "transaction", "transaction-response", "batch", "batch-response", "searchset" und "collection".

FHIR transaction bundle

Mit der Unterstützung der FHIR transactions bietet Fiyaware die Möglichkeit, mehrere Aktionen (CRUD + Search) innerhalb eines Bundles des Typs „transaction“ beziehungsweise innerhalb eines einzigen HTTP-Requests durchzuführen. Als Ergebnis einer erfolgreichen „transaction“ ist ein Bundle vom Typ „transaction-response“ zu erwarten (mit Paging). Transactions innerhalb von transactions sind nicht erlaubt.

POST [baseUrl]/

Achtung: Fiyaware gewährleistet die transaktionale Sicherheit. Schlägt eine Aktion innerhalb der transaction fehl, schlägt gleichzeitig auch die gesamte Menge an Aktionen fehl.

FHIR batch bundle

Mit der Unterstützung des Bundles des Typs „batch“ bietet Fiyaware die Möglichkeit, mehrere Aktionen (CRUD + Search) innerhalb eines Bundles des Typs „batch“ beziehungsweise innerhalb eines einzigen HTTP-Requests durchzuführen. Als Ergebnis einer erfolgreichen „transaction“ ist ein Bundle des Typs „batch-response“ zu erwarten (mit Paging).

POST [baseUrl]/

Achtung: Wenn eine Interaktion fehlschlägt, werden die übrigen Interaktionen im Bundle trotzdem ausgeführt.

FHIR document bundle (MIO = medizinisches Informationsobjekt)

Fiyaware unterstützt die Verarbeitung von medizinischen Informationsobjekten. Diese FHIR-Dokumente werden durch Standardisierungs-Einrichtungen definiert (z.B. KBV, gematik), mit dem Ziel, standardisierte und interoperable Informationsbausteine zur Verfügung zu stellen. Fiyaware bietet zur Verarbeitung der Dokumente sowohl den „[baseUrl]/“ als auch den „[baseUrl]/Bundle“ Endpunkt an.

Ressourcenvalidierung

Fiyaware unterstützt die vollständige Validierung von Ressourcen inklusive eventuell vorhandener Extensions.

FHIR Operations

Patient-level data export mit "$everything"

Mit der Operation „$everything“ kann ein Subset mit sämtlichen Patienteninformationen, die im Patient Compartment enthalten sind, abgefragt werden. Die Operation $everything ist nur auf dem individuellen Ressourcenlevel möglich.

GET [baseUrl]/Patient/id/$everything

Es wurden bislang noch keine zusätzlichen Parameter für diese Operation implementiert.

Sofern im Patient Compartment Ressourcen vorhanden sind, die auf Ressourcen referenzieren, welche nicht Teil des Patient Compartments laut FHIR-Standard sind und somit außerhalb des Compartments liegen, sind diese aus Datenschutzgründen nicht Teil des Return-Bundles der Operation.

Metadaten-Abfrage mit "$meta"

Mit der Operation „$meta“ kann eine Zusammenfassung der verwendeten Profile, Tags und Security Labels abgerufen werden.

Systemebene

GET [baseUrl]/$meta

Ressourcentypebene

GET [baseUrl]/[resourcetype]/$meta

Ressourcenebene

GET [baseUrl]/[resourcetype]/[id]/$meta

Historische Ressourcen

GET [baseUrl]/[resourcetype]/[id]/_history/[vid]/$

Custom Operations

Hard delete mit "$expunge"

Der proprietäre, nicht im FHIR-Standard enthaltene Operator „$expunge“ ermöglicht das endgültige („harte“) Löschen von FHIR-Ressourcen. Nach dem Löschvorgang sind die Ressourcen nicht mehr vorhanden und können auch nicht wiederhergestellt werden. Es können sowohl aktive als auch historische Daten komplett gelöscht werden.

Achtung: Das harte Löschen ist ein irreversibler Prozess. Sämtliche Daten können NICHT wiederhergestellt werden. Der Server bewahrt keine referenzielle Integrität beim Löschen von Ressourcen. Außerdem werden beim Löschen von historischen Einträgen auch alle älteren Versionen als die angegebene mitgelöscht, um die Nachvollziehbarkeit der „_history“ zu bewahren.

DELETE [baseUrl]/resourceType/id/$expunge

DELETE [baseUrl]/resourceType/id/_history/versionID/$expunge

Datenbank

Aus Performance- und Optimierungsgründen steht zur Zeit ausschließlich eine PostgreSQL-Datenbank zur Verfügung. Andere Datenbanken können auf Kundenwunsch ebenfalls implementiert werden.

Tools und Sicherheit

FHIR Clients

Fiyaware ist grundsätzlich mit allen FHIR R4-konformen Bibliotheken und Clients von Drittanbietern kompatibel. Mit den folgenden, am häufigsten verwendeten FHIR-Clients wurden zusätzlich umfassende Kompatibilitätstest durchgeführt, um ihre Kompatibilität mit Fiyaware Server sicherzustellen:

• HAPI FHIR Generic (Fluent) Client
• Firely .NET FHIR SDK

Zugriffskontrolle

SMART on FHIR

Der standalone Launchprozess von SMART on FHIR v2.2.0 zur Anbindung von Anwendungen und Apps wird derzeit implementiert, siehe die Spezifikation von SMART on FHIR v2.2.0. Dieser inkludiert eine OAuth 2.0-konforme Authorisierung des Benutzers und erfordert die Implementierung des Patient Compartments, siehe das nachfolgende Kapitel.

FHIR Compartments

Fiyaware unterstützt das Anlegen und Verwenden von FHIR Compartments, einer logischen Gruppierung von Ressourcen mit einer bestimmten Gemeinsamkeit -- hier die Zugehörigkeit zu einem bestimmten Patienten. FHIR Compartments bieten zwei wesentliche Vorteile:

• Zum einen können miteinander verbundene Ressourcen schnell und einfach durch das Aufrufen sämtlicher Ressourcen in einem Compartment gefunden werden

• Zum anderen kann eine feingranulare Zugriffskontrolle umgesetzt werden, die dem Benutzer ausschließlich Zugriff auf Ressourcen innerhalb eines spezifischen Compartments bietet und so zur Vermeidung unberechtigter Zugriffe beiträgt.

Die Definition von FHIR Compartments ist bisher ausschließlich für das FHIR Patient-Compartment möglich, welches sämtliche einem bestimmten Patienten zugeordnete Ressourcen enthält. Eine vollständige Auflistung aller Ressourcen, die in diesem Compartment enthalten sein können, ist in der FHIR-Dokumentation enthalten.

Für jede Ressource im Compartment können eigene Zugriffseinschränkungen definiert werden, etwa worauf ein Patient Zugriff hat oder welche Ressourcen dieser anlegen, speichern oder aktualisieren kann. Für das Durchsuchen von Compartments siehe Patient Compartment Search

Auditing und Logging

Zu Zwecken der Nachvollziehbarkeit, Fehlerbehebung und Statusüberprüfung können Informationen während des Betriebs aufgezeichnet werden - die Funktion muss dazu über die Einstellungen eingeschaltet werden. Dabei werden aktuell folgende Inhalte für jeden eingegangenen HTTP(S)-Request erfasst:

• Time of authentication
• Time of request income
• Alle Authentifizierungen (erfolgreich und nicht-erfolgreich, beispielsweise ein ungültiger access token)
• Actions: HTTP(S) GET, POST, PUT, DELETE, SEARCH
• Server Endpoint
• Content-Length & Content-Type
• Host
• User agent (Urheber des Requests, z.B.: der Browser oder eine Python request library)
• Alle Responses des Servers
• Header information
• Representation format
• Duration
• Status code
• Error message

Zusätzlich werden folgende Systeminformationen aufgezeichnet:

• Änderungen in den Systemzuständen und Exceptions, beispielsweise Datenbank-Exceptions
• Sobald Ressourcenlimits erreicht werden (beispielsweise eine volle Datenbank)
• Hochfahren, Herunterfahren und Neustarts

FHIR Facade

Fiyaware kann sowohl als standalone Server als auch als Facade für bestehende Datenbanken benutzt werden, um diese über eine FHIR-Schnittstelle zugänglich zu machen.

Facade setup

Die FHIR Facade wird analog zu Fiyaware Server als Docker-Container zum plattformunabhängigen Deployment zur Verfügung gestellt. Weiters können kundenspezifische Suchparameter und Operatoren auf Anfrage implementiert werden. Bei Bedarf kann Unterstützung bei der Integration der Facade in die kundeneigenen (Datenbank-)Systeme geleistet werden und das gesamte System auf Herz und Nieren getestet werden.

Datenbank-Mapping

Ein wesentlicher und einer der aufwändigsten Bestandteile bei der Integration der FHIR Facade in die kudeneigenen Systeme stellt das Datenbank-Mapping dar. Es sorgt dafür, dass die eigenen Daten optimal auf die entsprechenden Ressourcen und Elemente des FHIR-Standards gemappt werden. Wir unterstützen unsere Kunden bei diesem Schritt durch die Aufbereitung von Mapping-Schemen von den Daten der Kunden-Datenbank nach FHIR und umgekehrt.

FHIR search

Der Server unterstützt die Suche inklusive AND, OR und AND/OR Verknüpfung:

GET [base]/

GET [base]/resourceType

POST [base]/_search

POST [base]/resourceType/_search

Unterstütuzte Suchparameter

Fiyaware unterstützt alle ressourcenspezifischen Suchparameter inklusive chaining und reverse chaining. Weiters werden folgende Suchparameter aus "Parameters for all resources" unterstützt:

• _id
• _lastUpdated
• _tag
• _profile
• _security
• _has
• _type

Darüber hinaus werden folgende Parameter zur Sortierung und Strukturierung der Suchergebnisse unterstützt:

• _sort: Indicate which order to return the search results
• _count: Defines the amount of resources that should be returned in a single page
• _include: Return resources related to the search results
• _revinclude: Fetch a particular resource, and any resources that refer to it

Patient Compartment Search

Über die Patient Compartment Suche kann eine Menge an Ressourcen gefunden werden, die mit einem Patienten verknüpft sind. Dies erfolgt mit folgendem Request:

GET [baseUrl]/Compartment/id/type

Paging

Fiyaware unterstützt “Paging” für die Ergebnisse einer Suche. Wenn ein Bundle vom Typ „searchset“ zurückgeliefert wird, werden Links zum umblättern auf die erste, letzte, nächste und vorherige Seite bereitgestellt:

• Die Ergebnisse einer Seite werden beim Umblättern nicht verändert
• Standardmäßig enthält jede Seite maximal 20 Ressourcen.
• Standardmäßig können mit „_count“ maximal 100 Ressourcen pro Seite angegeben werden

Compliance and Certification

Supported Implementation Guides

Fiyaware Server unterstütuzt bislang ausgewählte Implementation Guides, die für bisherige Projekte und Kunden benötigt wurden und werden. Zusätzlich benötigte Implementation Guides können abhängig von Kundenwünschen jederzeit implementiert werden.

FHIR Base IG

Fiyaware unterstützt den FHIR-Standard vollumfänglich in der Version 4.0.1.

Informationstechnische Systeme in Krankenhäusern (ISiK) - DE

Fiyaware Server unterstützt das ISiK-Basismodul (Version 1).

HL7 Austria - AT

Fiyaware Server unterstützt den HL7 Austria FHIR Core IG R4..

Certifications

EN/ISO 13485

Die Entwicklung von Fiyaware Server wird durch ein EN ISO 13485-zertifiziertes Qualitätsmanagement durchgeführt und überwacht.

ISO 9001

Die Entwicklung von Fiyaware Server ist konform zu ISO 9001.

GDPR

Fiyaware ist durch die Implementierung des harten Löschens von Daten (siehe Kapitel hartes Löschen) mit der europäischen Datenschutzgrundverordnung (GDPR) kompatibel.

ISiK

Fiyaware Server ist mit ISiK Level 1 kompatibel, an Kompatibilität mit weiteren ISiK-Levels wird gearbeitet.

KBV

Fiyaware Server ist mit den von der kassenätzlichen Bundesvereinigung (KBV) herausgegebenen MIOs (Medizinische Informationsobjekte) kompatibel.

Contact us

Bei Fragen, Anregungen oder für technische Unterstützung stehen wir jederzeit unter der E-Mail Adresse info@blacktusk.eu zur Verfügung.