FHIR/IHE-Profiles

Aus eCG-Wiki
Wechseln zu: Navigation, Suche

Audit Trail and Node Authentication

Das Audit Trail and Node Authentication (ATNA) Profil legt Sicherheitsmaßnahmen fest, welche die Vertraulichkeit von Patienteninformationen gewährleisten. Das Profil trägt zur Kontrolle von Netzwerkzugriffen zwischen den Knoten bei. Sichere Knoten beschränken den Zugriff auf autorisierte Benutzer gemäß den lokalen Authentifizierungs- und Zugriffssteuerungsrichtlinien.

Benutzerauthentifizierung

Das Integrationsprofil für die Audit Trail and Node Authentication erfordert nur die lokale Benutzerauthentifizierung. Das Profil ermöglicht es jedem sicheren Knoten, die Zugangskontrolltechnologie seiner Wahl zu verwenden, um Benutzer zu authentifizieren.

Verbindungsauthentifizierung

Das Audit Trail and Node-Authentifizierung-Integrationsprofil erfordert die bidirektionale zertifikatbasierte Knotenauthentifizierung für Verbindungen zu und von jedem Knoten. Bei den Protokollen DICOM, HL7 und HTML sind alle zertifikatbasierten Authentifizierungsmechanismen definiert.

Audit Trails

Die Benutzer-Accountability wird über Audit Trail bereitgestellt. Der Audit Trail muss es einem Sicherheitsbeauftragten in einer Institution ermöglichen, Aktivitäten zu überwachen, die Einhaltung der Richtlinien einer sicheren Domäne zu bewerten und Fälle von nicht konformem Verhalten zu erkennen.

Akteure und Transaktionen:

FHIR-Resources

Die zugrundeliegenden FHIR-Resources für dieses Profil sind:

  • OperationOutcome
  • Bundle
  • AuditEvent

RESTful-Abfragen zu ATNA

Das ATNA Profil definiert eine standardisierte Möglichkeit zum Erstellen und Versenden von Protokollen. Es gibt jedoch keinen standardisierten Weg um Audit-Datensätze abzurufen, die von einem Audit Record Repository gesammelt wurden. Deshalb definiert dieses Profil einen neuen Akteur (Audit Consumer) und zwei neue Transaktionen:

1. Retrieve ATNA Audit Event [ITI-81]. Diese Transaktion basiert auf einer FHIR RESTful-Suchoperation für AuditEvent-Ressourcen.

2. Die ITI-82-Transaktion zum Abrufen des Syslog-Ereignisses ermöglicht es einem Audit Consumer, Syslog-Nachrichten zu durchsuchen, die in einem Repository gespeichert sind. Diese Transaktion ist als eine REST-konforme Operation definiert. Die Suchparameter basieren auf Syslog-Metadaten.


Akteure und Transaktionen:

FHIR-Resources

Die zugrundeliegenden FHIR-Resources für dieses Profil sind:

  • Bundle
  • AuditEvent

Clinical Mapping

Das IHE Clinical Mapping Profile unterstützt Systeme, Codes von einer Terminologie zu einer anderen zu übersetzen, um den Austausch von Informationen zwischen verschiedenen Systemen zu gewährleisten. In diesem Profil werden Informationen zu den Konzepten bereitgestellt, die sich sowohl auf die eingehende als auch auf die ausgehende Seite von der Übersetzung des Codes auswirken. Darüber hinaus unterstützt CMAP den Zugriff auf einzelne Transaktionen, sodass Implementierer Funktionen wie das Caching und das Aktualisieren von Terminologie-Mappings, die von externen Services bereitgestellt werden, nutzen können.

Akteure und Transaktionen:

Dynamic Care Planning

Das IHE Dynamic Care Planning (DCP) -Profil stellt die Strukturen und Transaktionen für die Pflegeplanung bereit und teilt Pflegepläne, welche die Bedürfnisse von z. B. Anbietern, Patienten und Kostenträgern erfüllen. Pflegepläne können dynamisch aktualisiert werden, wenn der Patient oder die Patientin mit dem Gesundheitssystem interagiert. In diesem Profil werden FHIR®-Ressourcen und -Transaktionen (u.a. aus dem Clinical Modul) verwendet.


Akteure und Transaktionen:

Dynamic Care Team Management

Das DCTM-Profil stellt die Strukturen und Transaktionen für den dynamischen Austausch von Care Team-Informationen bereit, wenn der Patient mit dem Gesundheitssystem interagiert. In diesem Profil werden Ressourcen und Transaktionen von FHIR (u.a. aus dem Clinical Modul) verwendet.


Mobile access to Health Documents (MHD)

Das mobile access to Health Documents (MHD) – Profil definiert eine einfache HTTP-Schnittstelle für die Dokumentfreigabe. Das MHD-Profil ist für jedes System gedacht, das die vereinfachte HTTP RESTful-Technologie und nicht die robustere Technologie von XDS vorzieht. Transaktionen werden wie folgt definiert: • Versenden einer Reihe von Dokumenten und Metadaten vom mobilen Gerät an einen Dokumentenempfänger;

• Finden von Metadaten des Dokuments basierend auf Abfrageparametern;

• Suchen nach Dokumenteneinträgen, die auf Abfrageparametern basierende Metadaten enthalten;

• eine Kopie eines bestimmten Dokuments abrufen

Diese Transaktionen nutzen den Dokumenteninhalt und formulieren agnostische Metadatenkonzepte von XDS, vereinfachen sie jedoch für den Zugriff durch eingeschränkte Umgebungen wie mobile Geräte oder andere ressourcenbeschränkte Systeme. Ein Bereitstellungsmodell besteht darin, den MHD als eine FHIR-basierte API für XDS zu verwenden. Dieser Vorgang ist als "XDS on FHIR" definiert.



FHIR-Resources

Die zugrundeliegenden FHIR-Resources für dieses Profil sind:

  • DocumentReference
  • DocumentManifest
  • List
  • Patient
  • Practitioner
  • OperationOutcome
  • Bundle

Mobile Care Services Discovery (mCSD)

Das Mobile Care Services Discovery-Profil (mCSD) unterstützt REST-Abfragen für die folgenden zugehörigen Care-Services-Ressourcen:

  • Organisation - Organisationen sind Entitäten; Eine Organisation hat eine eindeutige Kennung und kann zusätzliche administrative Attribute wie Kontaktperson, Postanschrift usw. haben.
  • Standort - Standorte sind Standorte für die physische Versorgung, z. B. Krankenhäuser, Kliniken, Gesundheitsämter, Arztpraxen, Labore, Apotheken.
  • Practitioner - Ein Practitioner ist ein Gesundheitsdienstleister wie von der WHO definiert.
  • Gesundheitsdienstleistung - Jede Gesundheitsdienstsleistung verfügt über eine eindeutige Kennung. Beispiele hierfür sind: chirurgische Dienste, Schwangerschaftsvorsorge oder Grundversorgung.


FHIR-Resources

Die zugrundeliegenden FHIR-Resources für dieses Profil sind:

  • Organization
  • Location
  • Practitioner
  • PractitionerRole
  • HealthcareService
  • OperationOutcome
  • Bundle

Query for Existing Data for Mobile

Das QEDm Profil unterstützt Abfragen für klinische Datenelemente, einschließlich Beobachtungen, Allergien und Intoleranzen, Bedingungen, Diagnoseergebnisse, Medikamente, Impfungen, Verfahren, indem die Informationen für andere Systeme innerhalb und außerhalb der Einrichtung des Quellsystems verfügbar gemacht werden. Es definiert eine Transaktion, welche zur Abfrage bestimmter Datenelemente genutzt wird und als FHIR-Ressourcen zur Verfügung stehen. Im Gegensatz zum QED-Profil ist dieses Profil für die Implementierung in Anwendungen konzipiert, welche von mobilen Endgeräten unterstützt werden. Das QEDm-Profil wurde für die Verwendung in Verbindung mit dem IHE-mXDE Profil entwickelt. Durch die Kombination dieser beiden Profile kann auf Datenelemente zugegriffen werden, die aus gemeinsam genutzten strukturierten Dokumenten extrahiert wurden. Sie ermöglichen den Austausch von Gesundheitsdaten und den darin enthaltenen feingranularen Datenelementen.


Alle Anfragen an die Clinical Data Source, sowie den Clinical Data Consumer basieren auf FHIR.

FHIR-Resources

Die zugrundeliegenden FHIR-Ressources für dieses Profil sind:

  • Observation
  • AllergyIntolerance
  • Condition
  • DiagnosticReport
  • Medication
  • MedicationStatement
  • MedicationRequest
  • Immunization
  • Procedure
  • Encounter
  • Provenance
  • OperationOutcome
  • Bundle

Point-of-Care Medical Device Tracking

Das PMDT-Profil umfasst die Messdatenerfassung am Point-of-Care zur Unterstützung der Meldung von Daten über Implantate (z. B. Herzschrittmacher, Titanplatten) und medizinische Geräte (z. B. Pulsoximeter, Blutzuckermessgeräte) während eines Verfahrens. Das Erfassen der medizinischen Geräteinformationen am Point-of-Care ermöglicht es, diese zu einem späteren Zeitpunkt abzurufen und wiederzuverwenden. Durch die Möglichkeit der Rückverfolgung der Produkte können diese bezüglich ihrer Qualität gesichert werden. Zudem werden menschliche Fehler bei der manuellen Eingabe medizinischer Daten minimiert, indem der Unique Device Identifier (UDI) vom Hersteller bereitgestellt wird. Die Verwendung der HL7 FHIR-Ressourcen zum Aufzeichnen von Informationen über medizinische Geräte (einschließlich Implantate), liefert einen zuverlässigen und standardbasierten Weg zum Ausführen einer Such- und Abfragefunktion durch Verwendung der HL7 FHIR RESTful-Services (HTTP/HTTPS) zum Erstellen/Aktualisieren und Abfragen vorhandener Datensätze.

Quelle: https://wiki.ihe.net/index.php/Point-of-Care_Medical_Device_Tracking




Patient Identifier Cross-Reference for Mobile (PIXm)

Dieses Profil stellt eine Transaktion für mobile- und browserbasierte Anwendungen bereit, um bei einem Patient Identifier Cross- Reference Manager nach einer Liste von Patientenbezeichnern, basierend auf der Patientenkennung in einer anderen Domäne, anzufragen und diese Domänenübergreifenden Informationen eines Patienten in der Anwendung abzurufen.

FHIR-Resources

Die zugrundeliegenden FHIR-Ressources für dieses Profil sind:

  • Patient
  • Operation
  • Parameter
  • OperationOutcome
  • Bundle

Patient Demographics Query for Mobile (PDQm)

Das PDQm-Profil stellt die Funktionalitäten eines Anbieters von Patientendaten für Mobile- und Browseranwendungen zur Verfügung. PDQm kann in verschiedenen Szenarien verwendet werden: - Wenn medizinische Geräte auf Patientendaten zugreifen müssen. - Wenn webbasierte EHR-/ EMR-Anwendungen dynamische Aktualisierungen von Patientendaten bereitstellen wollen. - Wenn Anwendungen das MHD-Profil verwenden, um auf Dokumente zuzugreifen, kann PDQm genutzt werden um eine geeignete Patientenkennung zu finden.

FHIR-Resources

Die zugrundeliegenden FHIR-Resources für dieses Profil sind:

  • Patient
  • OperationOutcome
  • Bundle

Quelle: https://wiki.ihe.net/index.php/Patient_Demographics_Query_for_Mobile_(PDQm)

Mobile Medication Administration

Das Mobile Medication Administration Profil von IHE stellt einen nahtlosen Integrationsmechanismus für die gesamten Medikations-Workflows unter der Verwendung von RESTful-Diensten bereit. Das MMA-Profil beinhaltet zwei Mechanismen für Anwendungen, die sich mit mobiler Verwaltung befassen:

  • Einpflegen einer Liste von geplanten Medikationen aus dem EHR in die mobile Anwendung
  • Senden des administrativen Berichts an die EHR oder ein beliebiges anderes System

Das MMA-Profil bietet funktionale Anleitungen zur Verwendung unterschiedlicher Ressourcen für verschiedene Szenarien, um eine konsistente Interoperabilität sicherzustellen.

FHIR-Resources

Die zugrundeliegenden FHIR-Ressources für dieses Profil sind:

  • Patient
  • Medication
  • MedicationRequest
  • MedicationAdministration

Quelle: https://wiki.ihe.net/index.php/Mobile_Medication_Administration

Mobile Retrieve Form for Data Capture

Das mRFD-Profil stellt eine Methode zur Erfassung von Daten in der Anwendung eines Benutzers bereit, um die Anforderungen eines externen Systems zu erfüllen. mRFD unterstützt das REST-konforme Abrufen von Formularen aus einer Quelle, das Anzeigen und Vervollständigen eines Formulars und das Zurückgeben von Daten aus Anwendung an die Quellanwendung. Das Profil wurde in Verbindung mit HL7 erstellt und verwendet die SMART on FHIR EHR Launch capacity als Framework für den Zugriff auf externe Webanwendungen.

Mobile Cross-Enterprise Document Data Element Extraction

Das mXDE-Profil bietet die Möglichkeit, auf Datenelemente zuzugreifen, die aus gemeinsam genutzten strukturierten Dokumenten extrahiert wurden. Dieses Profil definiert Regeln, um die Konsistenz und Rückverfolgbarkeit von Informationen für klinische Entscheidungen zu gewährleisten. Beim Zugriff auf ein Datenelement durch einen Benutzer können Identifikatoren aus diesem Datenelement verwendet werden, um auf ein oder mehrere Dokumente zuzugreifen, in denen dieses Datenelement ursprünglich aufgezeichnet wurde. Dies liefert einen wertvollen allgemeineren klinischen Kontext. Die Informationsflüsse innerhalb des Profils:

  • 1) Spezifische Datenelemente werden aus den strukturierten Dokumenten extrahiert.
  • 2) Datenelemente (z. B. Allergien), die unter Verwendung des FHIR-basierten QEDm-Profils (Query_for_Existing_Data_for_Mobile) abgefragt werden.
  • 3) Jedes Datenelement ist mit den Dokumenten verknüpft, aus denen es per mXDE-Profil extrahiert wurde.
  • 4) Der Arzt greift auf den Kontext aller Datenelemente zu, indem er Quelldokumente (XDS, MHD-Profile) verwendet, die den klinischen Kontext liefern.

Quelle:https://wiki.ihe.net/index.php/Mobile_Cross-Enterprise_Document_Data_Element_Extraction

Non-Patient File Sharing (NPFSm)

Dieses Profil zeigt, wie die Freigabe von Nicht-Patientendateien ermöglicht wird. Solche Dateien können von vielen verschiedenen Systemen erstellt und in eine Vielzahl von Workflows zur gemeinsamen Nutzung von Daten eingebunden werden. Hervorzuheben sind drei Akteure: Dateimanager, Dateiverbraucher und Dateiquelle. Dieses Profil definiert drei neue Transaktionen (Datei übergeben, Datei durchsuchen und Dokument aktualisieren) und verwendet eine bereits bestehende MHD-Transaktion: Dokument abrufen.

Non-Patient File Sharing (NPFSm)


FHIR-Resources

Die zugrundeliegenden FHIR-Ressources für dieses Profil sind:

  • DocumentReference
  • OperationOutcome
  • Bundle
  • Binary

Uniform Barcode Processing

Das UBP-Profil beschreibt den Prozess zur Verarbeitung eines Barcodes, der beispielsweise in einem Krankenhaus eingescannt wird. Barcodes sind nicht menschenlesbar, jedoch wird vom System erkannt, welche Informationen der Barcode enthält. Hierbei kann es sich um Informationen handeln, die ein Medikament, ein medizinisches Gerät oder einen Patienten repräsentieren. Die Informationen werden über eine FHIR Ressource dargestellt.

Quelle: https://wiki.ihe.net/index.php/Uniform_Barcode_Processing

Routine Interfacility Patient Transport

Häufig gehen wichtige Informationen verloren, wenn es zur Zusammenarbeit von Krankenhaus und Rettungsdienst kommt. In diesem Profil wird eine Möglichkeit zur Verringerung des Informationsverlustes beschrieben. Zur Minimierung von Fehlern werden von Transportorganisationen (z.B. Rettungsdienst) Informationen über den Patienten aufgenommen. Diese werden durch Befragungen gesammelt und müssen aufwendig dokumentiert werden. Nach Abschluss des Transportes erhält die behandelnde Organisation (z.B. Krankenhaus) diese Informationen. Heutzutage werden Informationen meist elektronisch übermittelt. Der Mangel an Standards hat jedoch häufig zur Folge, dass Informationen oft doppelt vorliegen oder nicht korrekt verarbeitet werden. Durch den Einsatz von FHIR und CDA soll zusätzlich zum papierlosen Austausch von Daten, der Aufwand der Informationsbeschaffung und -übertragung reduziert werden. So soll auch der Patient davon profitieren, da die am Prozess beteiligten Personen mehr Zeit für den Versorgungs- und Behandlungsprozess haben.


Akteure und Transaktionen:


Quelle: https://wiki.ihe.net/index.php/Routine_Interfacility_Patient_Transport