Interoperability standards und schema
Normen-Entwicklung-Aktivitäten seit den 1980er Jahren mit dem Ziel, Lösungen für diese Herausforderungen der Interoperabilität., Das Digital Imaging and Communications in Medicine (DICOM®), Normenkomitee der National Electrical Manufacturers Association (NEMA), war einer der ersten , der einen Standard für die Kommunikation medizinischer Bildgebungsinformationen entwickelte, der jetzt von der Internationalen Organisation für Normung (ISO12052:2017) veröffentlicht wurde. Alle Standards der Gesundheitsstufe Sieben (HL7) werden von einer offiziellen nationalen Normenorganisation, dem American National Standards Institute (ANSI), veröffentlicht., Es ist wichtig zu beachten, dass sich die HL7-Standards (Health Level Seven) auf technische Interoperabilität (Health Data Exchange) konzentrieren, was zu einer begrenzten operativen (semantischen) Interoperabilität führt .
Der mittlerweile sehr beliebte FHIR® – Standard (Fast Healthcare Interoperability Resources) hat den betrieblichen Informationsfluss erheblich verbessert . Das Referenzmodell HL7 FHIR® wird durch eine Sammlung von Informationsmodellen (Ressourcen) definiert. Diese können profiliert werden (oder nicht), um ein klinisches Informationsmodell zu generieren., FHIR ® – Ressourcen werden aus einer Obermenge von Daten in Legacy-Systemen erzeugt, die direkt von Entwicklern verwendet werden können. Streng genommen sind dies keine „Modelle“, da keine der üblichen Vererbung, Kapselung von gemeinsamen Elementen oder Typisierungspraktiken verwendet werden. Die erfolgreiche Anwendung des FHIR ® – Standards hängt vom Grad der Vereinbarung zwischen den Parteien ab. Eine Einigung auf diese Weise ist innerhalb von Organisationen durch eine kleine Anzahl von Interessengruppen, einschließlich Klinikern, leichter zu erreichen als Vereinbarungen für umfassendere Netzwerke. Dies schränkt die Möglichkeiten zur Wiederverwendung von Software ein .,
Eine Überprüfung von sechs US-amerikanischen Medicare Accountable Care-Organisationen hat erneut die Notwendigkeit eines Standardansatzes hervorgehoben. Es wurde festgestellt, dass diejenigen, die einer einzigen elektronischen Gesundheitsakte system über Ihren provider-Netzwerken, konnten die Aktien-Daten in Echtzeit, die Verbesserung Anbieter Fähigkeit zur Koordinierung der Pflege. Andere hatten Zugang zu einem robusten Gesundheitsinformationsaustausch, der den Zugriff auf Patientendaten von externen Anbietern ermöglichte. Trotzdem wurde festgestellt, dass das volle Potenzial der Gesundheit ES wurde nicht realisiert.,e das Ergebnis einer unzureichenden Interoperabilität, die die Fähigkeit zur Versorgung beeinträchtigt und zu Folgendem führt:
•
Abhängigkeit von anderen Mitteln zum Austausch von Daten, einschließlich Telefonanrufen und Faxen,
•
Belastende und frustrierende Verwendung von EHRs,
•
Burnout bei Ärzten aufgrund von Arbeitsbelastung im Zusammenhang mit dem EHR-Management,
•
Zugang zu Gesundheitsinformationsaustausch mit geringen oder unvollständigen Daten, die Schwierigkeiten bei der Koordinierung der Versorgung verursachen,
•
Unfähigkeit, anderen Patienten als Online-Portalen für ihre EHRs Health IT anzubieten,
•
Unfähigkeit, Analysen zu verwenden, um die Pflege an die Bedürfnisse eines einzelnen Patienten anzupassen.,
Eine private Initiative führt derzeit ein Projekt durch, das darauf abzielt, die Einführung moderner, offener Interoperabilitätsstandards, die als Argonaut-Projekt bekannt sind, in der Industrie voranzutreiben . Ziel dieses Projekts ist es, eine FHIR®-basierte API und Core Data Services-Spezifikation der ersten Generation zu entwickeln, um einen erweiterten Informationsaustausch für elektronische Gesundheitsakten und andere Gesundheitsinformationstechnologien auf der Grundlage von Internetstandards und architektonischen Mustern und Stilen zu ermöglichen. Diese Arbeit wird von zahlreichen Anbietern wie Cerner, Epic und Accenture gesponsert., Im Rahmen dieser Arbeit geht es darum, die FHIR® – Modellentwicklung zu beschleunigen, indem der Schwerpunkt auf spezifischeren FHIR® – Profilen und-dokumentationen liegt, einschließlich des Fokus auf begleitenden Sicherheitsspezifikationen und-dokumentationen, um die Interoperabilität zwischen älteren proprietären Systemen zu ermöglichen, bei denen ihre Anbieter vertraglich den Datenzugriff steuern. Die Verwendung dieser APIs birgt inhärente Risiken für Fehler und Patientensicherheit aufgrund der Datenzuordnung.
Gesundheitsorganisationen sind jetzt dabei, die schnelle Aufnahme von FHIR® und die stärkere Nutzung von APIs zu verwalten., Aus Sicht der nationalen Infrastruktur müssen die Mittel vorhanden sein, um die Wiederverwendung einiger häufig verwendeter FHIR®-Schlüsselmodelle zu erleichtern. Diese können gewählt werden, um zugelassene HL7-Standards zu werden. Ohne die Annahme vereinbarter Standardmodelle wird es eine Verbreitung von FHIR® – Modellen geben, die entwickelt wurden, um lokale Bedürfnisse zu erfüllen, viele Wiederholungen und Inkonsistenzen begrenzen den gesamten nationalen Fortschritt auf dem Weg zu einem gut vernetzten digitalen Gesundheitsökosystem., FHIR ® – Modelle entsprechen nicht den bekannten Modellierungskonventionen, wie Beale gezeigt hat, der zu dem Schluss kam, dass:
Die FHIR-Ressourcen scheinen das Ergebnis separater Ausschüsse zu sein, die fast ohne Querverweise, Methodik oder gemeinsame Entwurfsbasis arbeiten. Das Ergebnis ist, dass jede Ressource so etwas wie ein „Sack voller Attribute“ ist, vermutlich aufgrund der Anwendung der sogenannten 80/20-Regel im Ausschusskontext.
FHIR® – Modelle müssen eine sehr große und nicht verwaltbare Anzahl von Datenpunkten berücksichtigen., Diese Einschränkung wird durch die Einführung generischer Modelle überwunden, die sich perfekt für Messaging eignen, jedoch nicht für semantisch kohärente klinische Datenspeicherung. Kontext ist ein wesentlicher Bestandteil der Verarbeitung von Informationen durch Kliniker. Kontext muss bei der Entwicklung von Entscheidungsunterstützungs-oder Systemen für künstliche Intelligenz, bei der Annahme verschiedener Datenanalysestrategien und für eine beliebige Anzahl relevanter Standards, einschließlich derjenigen, die für die Datenzuordnung verwendet werden, berücksichtigt werden.,
Die FHIR ® – Ressourcen sollen ein Kontinuum ontologischer Ebenen enthalten, sie haben zwei Eigenschaften, die in einem stabilen Informationsmodell unerwünscht sind :
Volatilität — klinisch spezifische Ressourcen müssen sich im Laufe der Zeit eindeutig ändern. Wie sich dies auf abhängige Profile auswirkt, ist eine interessante Frage;
Offenheit-man muss davon ausgehen, dass die Ressourcen einfach weiter wachsen werden, um neue wichtige klinische Informationskategorien aufzunehmen.,
Die Folgen dieser Faktoren sind, dass das Modell „nie fertig“ ist und dass alle darauf basierenden Datenbanken oder Software ebenfalls gewartet werden müssen. Es gibt ein weiteres Problem, das mit der nachgelagerten Informationsverarbeitung für die sekundäre Datennutzung verbunden ist. Das ist eine Unfähigkeit zu wissen, ob Datenstrukturen, die fast gleich zu sein scheinen, auf die gleiche Weise behandelt werden können; Die Standardeinstellung bei FHIR ist, dass jede Ressource ihre eigene Sache ist ., Ein Experte für internationale Standards stellte fest, dass:
FHIR® wurde als API/Interchange-Standard entwickelt und gedacht, die meisten großen ITC-Organisationen (Google, Microsoft, IBM usw.) und mindestens ein großer EHR-Anbieter (Cerner) haben FHIR® als Persistenzobjektschema und Datenspeicherschema angenommen. FHIR® bleibt auf internationaler Ebene unterspezifiziert, da die Bindung von Wertesätzen auf Implementierungsleitfäden (z. B. den US Core FHIR® Implementation Guide) verbannt wird., Angesichts der aktuellen nationalen Prädispositionen für nationale Codes für Gesundheitsinformationstechnologie (HIT) (praktisch jedes Land hat seine eigene verdammte Veröffentlichung von Verfahrenscodes, und seltsamerweise verwendet die ganze Welt noch nicht ICD11) ist diese Trennung sehr pragmatisch. Die Hemmnisse für die Interoperabilität internationaler Systeme haben weniger mit technischen Syntaxspezifikationen zu tun als vielmehr mit der fast unlösbaren Tendenz der Länder, ihre eigenen, manchmal proprietären Codierungssysteme zu spezifizieren.,
Die Einführung des openEHR architectural Framework erfordert die Verwendung eines umfassenderen Modellierungsansatzes . Diese Modelle sind in der Lage, bei Bedarf mit FHIR® – Modellen zu verknüpfen, beispielsweise wurden der openEHR Adverse reaction risk Archetype und die FHIR® AllergyIntolerance Resource Ende 2015 gemeinsam veröffentlicht und ausgerichtet., Archetypen integrieren die kollaborative Arbeit einer großen virtuellen internationalen Gemeinschaft multidisziplinärer Fachleute, die Gesundheitsdaten in eine evidenzbasierte elektronische (berechenbare) Form umwandeln, um die universelle Interoperabilität in jedem digitalen Gesundheitsökosystem sicherzustellen. Dieser Ansatz besteht aus einer mehrstufigen Single-Source-Modellierung innerhalb einer serviceorientierten Softwarearchitektur, die durch eine Reihe von Spezifikationen der openEHR Foundation abgegrenzt und für jedermann frei verfügbar ist.,
Die openEHR ist eine offene Standardspezifikation, die von einer gemeinnützigen Stiftung verwaltet wird und von jedem Entwickler frei implementiert werden kann. openEHR-Spezifikationen, das Ergebnis von 25 Jahren Forschung und Entwicklung, stellen die einzige ernsthafte Instanziierung des ISO 13606-Referenzmodells für die Kommunikation elektronischer Gesundheitsakten dar, das eine hierarchische Struktur für klinische Informationen beschreibt . Dieser Standard wird zunehmend in Großprojekten in Großbritannien, Norwegen, Finnland, Slowenien und Deutschland eingesetzt., Auch China, Chile, Brasilien, Italien und die Karibik haben diesen Ansatz gewählt. Tatsächlich wurde ISO 13606 aus den Erfahrungen von openEHR abgeleitet und in jüngerer Zeit durch Erfahrungen mit anderen Standards, einschließlich FHIR®, beeinflusst. Die klinische Modellierungsarbeit ist umfangreicher als die, die zuvor mit einer freiwilligen Gemeinschaft von über 2000 Menschen aus 93 Ländern durchgeführt wurde.
Die klinischen Modelle der ISO13606-Domäne, die als „Archetypen“ bezeichnet werden, sind außerhalb der Software., Jeder Archetyp definiert eine maximale Anzahl möglicher Datenpunkte und Datengruppen, die für das modellierte Konzept gelten. Dies bietet eine maximale Anzahl verschiedener Kontexte für alle klinischen Spezialitäten und potenziellen Datenverwendungen. Vorlagen, die aus einer „Rekombinationsschicht“ von Modellen zur Definition von Datensätzen bestehen, verwenden nur die Datenpunkte aus einem Satz (beliebiger Anzahl oder Auswahl) von Archetypen, die für einen bestimmten „Anwendungsfall“ oder eine bestimmte Anwendung erforderlich sind, z. B. jede Art von klinischer Beurteilung., Vorlagen können als Nachrichtendefinitionen für ältere Systeme sowie Datensätze für neue Anwendungen, einschließlich Formulare, verwendet werden. Dies bedeutet, dass jeder Satz von Archetypen für mehrere Anwendungsfälle wiederverwendet werden kann. Es ermöglicht, dass wesentliche Teile der Software maschinell von den Archetypen abgeleitet werden. Archetypen stellen atomare Daten in einem offenen Standard dar; ein kritischer Erfolgsfaktor, der technologischen Veränderungen, insbesondere Austausch und Persistenz, standhalten kann.,
Diese „Archetypen“ (Modelle) werden von verschiedenen Anwendungen verwendet, auch im Nationalen Gesundheitsdienst des Vereinigten Königreichs, wo sie für die Konvertierung von Schattensystemen verwendet werden, die die Verwendung herstellerneutraler Datenrepositorien ermöglichen. Andere Benutzer sind: Queensland Health und einige private Krankenhäuser für ihre Infektionskontrollsysteme, eine Reihe von primären Gesundheitseinrichtungen in West-Sydney und das gemeinsame EHR von Northern Territory Health sowie openEHR-Industriepartner, deren Systeme in skandinavischen Ländern weit verbreitet sind., Konforme Komponenten und Systeme sind in Bezug auf Datenmodelle und APIs „offen“. Strategisch hat der openEHR-Ansatz einen gesundheitsbezogenen Fokus, der sich gut für die patientenzentrierte Versorgung eignet. Dieser Ansatz ermöglicht einen plattformbasierten oder“ offenen Back-End “ – Softwaremarkt, in dem Anbieter und Lösungsentwickler der Gesundheitsbranche über standardisierte Informationsmodelle, Inhaltsmodelle, Terminologien und Serviceschnittstellen miteinander interagieren.,
Eine OFFENE Zusammenarbeit von Einzelpersonen, Industrie, Normungsorganisationen und Gesundheitsdienstleistern hat vereinbart, zusammenzuarbeiten, um die Entwicklung offener Standards für die Interoperabilität im Gesundheits-und Sozialsektor zu beschleunigen. Sie haben ein kollaboratives Forum für den Erfahrungsaustausch und die Bereitstellung von Lösungen zur Überwindung dieser verwirrenden Landschaft zur Verfügung gestellt. Im Juli 2018 veröffentlichten sie einen Überblick über das, was hier beschrieben wurde . Es wurde festgestellt, dass diese vielen Standards konvergieren. Die Standards FHIR® und openEHR lösen nicht das gleiche Problem., Beide erstellen klinische Informationsmodelle, aber die openEHR-Modelle (Archetypen) sind datenzentrierte herstellerunabhängige openEHR-Plattformen. FHIR® ist anwendungsorientiert, da es ein gemeinsames Modell für die Verwendung in jeder Anwendung erstellt, um dann die Grundlage für die Definition der Interoperabilität zwischen Anwendungen zu bilden, unabhängig von offenen oder proprietären Modellen, auf denen sie aufgebaut wurden. Diejenigen, die anwendungsorientierte Interoperabilitätslösungen verwenden, tun dies, um die kontinuierliche Verwendung teurer Legacy-Systeme zu ermöglichen.,
openEHR und FHIR® bieten komplementäre, aber unterschiedliche Ansätze, um ein komplexes Patchwork von Anwendungen zu einem einzigen kohärenten System zu verbinden . Der datenzentrierte openEHR-Ansatz konzentriert sich zunächst auf die Normalisierung der Gesundheitsdaten und den Aufbau neuer Systeme auf älteren Systemen, um Interoperabilitätsprobleme zu vermeiden. Hier geht es darum, eine Datenschicht innerhalb einer offenen Systemarchitektur zu definieren. Dies ist die wichtigste Ebene, da sie eine optimale Datennutzung ermöglicht, um die Ergebnisse zu verbessern, chronische Krankheiten besser zu behandeln und ein besseres Gesundheitsmanagement für die Bevölkerung zu ermöglichen., Dies erfordert, dass Daten in herstellerneutralen Formaten gespeichert werden, im Gegensatz zu proprietären Formaten der meisten Legacy-Systeme. Der datenzentrierte Ansatz ermöglicht die Speicherung und Nutzung digitaler Gesundheitsdaten während der gesamten Lebensdauer eines Patienten.
Fast jedes openEHR-basierte System entwickelt derzeit FHIR ® – Schnittstellen, um sicherzustellen, dass sie die Reise des Patienten zwischen openEHR-und Nicht-openEHR-Systemen unterstützen können . openEHR Connectivity Schema kann einmalig erstellt und von allen openEHR-Anbietern gemeinsam genutzt werden, da sie auf gängigen openEHR-Archetypen basieren., Anwendungen, die auf einer openEHR – basierten Plattform zusammengefasst sind, benötigen keine Exchange-Lösungen wie FHIR®, da sie über gemeinsam genutzte klinische Datenrepositories direkt miteinander kommunizieren können. Dies ermöglicht es neuen Marktteilnehmern, sich auf die Entwicklung wirklich innovativer Anwendungen zu konzentrieren und die klinischen Nischenanforderungen funktional zu erfüllen. FHIR ® – Kapazität wird nur benötigt, damit sie mit einem breiteren Ökosystem proprietärer Anwendungen kommunizieren können .
Leave a Reply