standardy i schematy interoperacyjności
standardy działania podejmowane od początku lat 80.miały na celu dostarczenie rozwiązań tych problemów związanych z interoperacyjnością., Digital Imaging and Communications in Medicine (DICOM®), Komitet Normalizacyjny National Electrical Manufacturers Association (NEMA), jako jeden z pierwszych opracował standard przekazywania informacji o obrazowaniu medycznym, obecnie opublikowany przez Międzynarodową Organizację Normalizacyjną (ISO12052:2017). Wszystkie normy Health Level Seven (HL7) są publikowane przez oficjalną krajową organizację normalizacyjną, American National Standards Institute (ANSI)., Należy pamiętać, że standardy HL7 (poziom siódmy zdrowia) koncentrują się na interoperacyjności technicznej (wymiana danych dotyczących zdrowia), co skutkuje ograniczoną interoperacyjnością operacyjną (semantyczną).
bardzo popularny obecnie standard Fast Healthcare Interoperability Resources (FHIR®) znacznie poprawił przepływ informacji operacyjnych . Model referencyjny HL7 FHIR® jest definiowany przez zbiór modeli informacyjnych (zasobów). Można je profilować (lub nie) w celu wygenerowania modelu informacji klinicznej., Zasoby FHIR® są tworzone z zestawu danych znalezionych w starszych systemach, które są bezpośrednio wykorzystywane przez programistów. Ściśle mówiąc, nie są to „modele”, ponieważ nie są używane żadne zwykłe dziedziczenie, enkapsulacja elementów wspólnych lub praktyki typowania. Pomyślne zastosowanie standardu FHIR® zależy od stopnia porozumienia między stronami. Osiągnięcie porozumienia w ten sposób jest łatwiejsze do osiągnięcia w organizacjach przez niewielką liczbę interesariuszy, w tym klinicystów, niż porozumienia dopasowane do bardziej rozległych sieci. Ogranicza to możliwości ponownego wykorzystania oprogramowania .,
przegląd sześciu amerykańskich organizacji odpowiedzialnych za opiekę medyczną po raz kolejny uwypuklił potrzebę przyjęcia standardowego podejścia. Stwierdzono, że ci, którzy korzystali z jednego systemu elektronicznej karty zdrowia w sieciach swoich dostawców, byli w stanie udostępniać dane w czasie rzeczywistym, zwiększając zdolność dostawców do koordynowania opieki. Inni mieli dostęp do solidnej wymiany informacji zdrowotnych, umożliwiającej dostęp do danych pacjentów od dostawców zewnętrznych. Mimo to zauważono, że pełny potencjał zdrowia nie został zrealizowany.,
•
uciążliwe i frustrujące korzystanie z EHR,
•
wypalenie zawodowe lekarza spowodowane obciążeniem pracą związaną z zarządzaniem EHR,
•
dostęp do wymiany informacji zdrowotnych z niewielkimi lub niekompletnymi danymi stwarzającymi trudności w koordynacji opieki zdrowotnej,
•
niezdolność do oferowania zdrowia pacjentom innym niż portale internetowe swoim EHR,
/p> •
Brak możliwości korzystania z analityki w celu dostosowania opieki do indywidualnych potrzeb pacjenta.,
inicjatywa sektora prywatnego podejmuje obecnie projekt mający na celu przyspieszenie przyjęcia nowoczesnych, otwartych standardów interoperacyjności znanych jako projekt Argonaut . Celem tego projektu jest opracowanie pierwszej generacji interfejsu API FHIR®i specyfikacji podstawowych usług danych, aby umożliwić rozszerzoną wymianę informacji na potrzeby elektronicznej dokumentacji medycznej i innych technologii informacji zdrowotnej opartych na standardach internetowych oraz wzorcach i stylach architektonicznych. Praca ta jest sponsorowana przez wielu dostawców, w tym Cerner, Epic i Accenture., Zakres tych prac dotyczy przyspieszenia rozwoju modelu FHIR® poprzez skupienie się na bardziej konkretnych profilach i dokumentacji FHIR®, w tym na towarzyszących specyfikacjach bezpieczeństwa i dokumentacji, aby umożliwić osiągnięcie interoperacyjności między starszymi zastrzeżonymi systemami, w których ich dostawcy umownie kontrolują dostęp do danych. Stosowanie tych API stwarza nieodłączne ryzyko błędów i bezpieczeństwa pacjentów dzięki mapowaniu danych.
organizacje ochrony zdrowia są obecnie w trakcie zarządzania szybkim wykorzystaniem FHIR® i szerszym wykorzystaniem API., Z punktu widzenia infrastruktury krajowej muszą istnieć środki ułatwiające ponowne wykorzystanie niektórych często używanych kluczowych modeli FHIR®. Mogą one zostać wybrane jako zatwierdzone standardy HL7. Bez przyjęcia uzgodnionych modeli standardowych nastąpi mnożenie modeli FHIR® opracowanych w celu zaspokojenia lokalnych potrzeb, a wiele powtórzeń i niespójności ogranicza ogólny Krajowy postęp w kierunku osiągnięcia dobrze połączonego cyfrowego ekosystemu zdrowia., Modele FHIR® nie są zgodne ze znanymi konwencjami modelowania, co wykazał Beale, który doszedł do wniosku, że:
zasoby FHIR wydają się być wynikiem odrębnych komitetów pracujących prawie bez odsyłaczy, metodologii lub wspólnej podstawy projektowej. W rezultacie każdy zasób jest czymś w rodzaju „worka atrybutów”, prawdopodobnie ze względu na zastosowanie tzw. reguły 80/20 w kontekście Komitetu.
modele FHIR® muszą uwzględniać bardzo dużą i niemożliwą do zarządzania liczbę punktów danych., Ograniczenie to jest przezwyciężone przez przyjęcie modeli generycznych, które doskonale nadają się do przesyłania wiadomości, ale nie do przechowywania semantycznie spójnych danych klinicznych. Kontekst jest integralną częścią sposobu, w jaki lekarze przetwarzają informacje. Należy wziąć pod uwagę kontekst przy opracowywaniu systemów wspomagania decyzji lub sztucznej inteligencji, przy przyjmowaniu różnych strategii analizy danych oraz w odniesieniu do dowolnej liczby odpowiednich norm, w tym norm stosowanych do mapowania danych.,
zasoby FHIR® zawierają kontinuum poziomów ontologicznych, mają dwie cechy niepożądane w stabilnym modelu informacyjnym:
zmienność — klinicznie specyficzne zasoby będą musiały się z czasem zmieniać. Ciekawym pytaniem jest, jak to wpływa na profile zależne;
otwartość-należy założyć, że zestaw zasobów będzie po prostu rosnąć, aby pomieścić nowe główne kategorie informacji klinicznych.,
konsekwencją tych czynników jest to, że model jest „nigdy nie ukończony” i że wszelkie bazy danych lub oprogramowanie na nim oparte będą również wymagały ciągłej konserwacji. Jest jeszcze jeden problem związany z niższym przetwarzaniem informacji na potrzeby wtórnego wykorzystania danych. Jest to niezdolność do poznania, czy struktury danych, które wydają się być prawie takie same, mogą być traktowane w ten sam sposób; domyślnie FHIR polega na tym, że każdy zasób jest swoją własną rzeczą ., Jeden z międzynarodowych ekspertów ds. standardów zauważył, że:
FHIR® został zaprojektowany i przeznaczony jako standard API/interchange, większość głównych organizacji ITC (Google, Microsoft, IBM itp.) oraz co najmniej jeden główny dostawca EHR (Cerner) przyjęły FHIR® jako schemat obiektu trwałości i schemat magazynu danych. FHIR ® pozostaje słabo sprecyzowany na poziomie międzynarodowym, ponieważ Wiązanie zestawów wartości jest relegowane do przewodników wdrażania (np. US Core FHIR® implementation guide)., Biorąc pod uwagę obecne krajowe predyspozycje do krajowych kodów technologii informacji zdrowotnej (HIT) (praktycznie każdy kraj ma swoją własną publikację kodów procedur, a co dziwne cały świat nie używa jeszcze ICD11), rozdzielenie to jest wysoce pragmatyczne. Bariery dla międzynarodowej interoperacyjności HIT mają mniej wspólnego ze specyfikacjami składni technicznej, a znacznie więcej z prawie trudną tendencją krajów do określania własnych, czasem zastrzeżonych, systemów kodowania.,
przyjęcie openehr architectural framework wymaga zastosowania bardziej kompleksowego podejścia do modelowania . Modele te są w stanie połączyć się z modelami FHIR® w razie potrzeby, na przykład archetyp ryzyka wystąpienia reakcji niepożądanych openEHR i zasób alergii FHIR® zostały wspólnie opublikowane i dostosowane pod koniec 2015 roku., Archetypy obejmują wspólną pracę podjętą przez dużą wirtualną międzynarodową społeczność multidyscyplinarnych specjalistów, przekształcając dane dotyczące zdrowia w elektroniczną (obliczeniową) formę opartą na dowodach, aby zapewnić uniwersalną interoperacyjność w dowolnym cyfrowym ekosystemie zdrowia. Podejście to polega na wielopoziomowym modelowaniu z jednego źródła w architekturze oprogramowania zorientowanej na usługi, wyznaczonej zestawem specyfikacji opublikowanych przez openehr foundation i swobodnie dostępnych dla każdego.,
openEHR jest otwartą standardową specyfikacją zarządzaną przez fundację non-profit, jest swobodnie dostępna do wdrożenia przez dowolnego dewelopera. Specyfikacje OpenEHR, wynik 25 lat badań i rozwoju, stanowią jedyną poważną instancję modelu referencyjnego ISO 13606 dla komunikacji elektronicznej dokumentacji zdrowia, który szczegółowo opisuje hierarchiczną strukturę informacji klinicznych . Standard ten jest coraz częściej stosowany w dużych projektach w Wielkiej Brytanii, Norwegii, Finlandii, Słowenii i Niemczech., Również Chiny, Chile, Brazylia, Włochy i Karaiby przyjęły takie podejście. W rzeczywistości ISO 13606 zostało zaczerpnięte z doświadczenia openehr, a ostatnio wpłynęło na to doświadczenie z innymi standardami, w tym FHIR®. Prace nad modelowaniem klinicznym są bardziej rozległe niż te podejmowane wcześniej przez społeczność wolontariuszy ponad 2000 osób z 93 krajów.
domena ISO13606, Każdy archetyp definiuje maksymalną liczbę możliwych punktów danych i grup danych, które mają zastosowanie do modelowanego pojęcia. Zapewnia to maksymalną liczbę różnych kontekstów dostosowanych do wszystkich specjalności klinicznych i potencjalnych zastosowań danych. Szablony, składające się z warstwy” rekombinacji „modeli do definiowania zestawów danych, wykorzystują tylko te punkty danych z zestawu (dowolnej liczby lub wyboru) archetypów, które są wymagane dla każdego konkretnego” przypadku użycia ” lub zastosowania, takiego jak każdy rodzaj oceny klinicznej., Szablony mogą być używane jako definicje komunikatów dla starszych systemów, a także zestawy danych dla nowych aplikacji, w tym formularzy. Oznacza to, że każdy zestaw archetypów może być ponownie użyty do wielu przypadków użycia. Pozwala to na wykorzystanie znacznej części oprogramowania w postaci maszynowej, wywodzącej się z archetypów. Archetypy reprezentują dane atomowe w otwartym standardzie; krytyczny czynnik sukcesu, który jest w stanie wytrzymać zmiany w technologii, w szczególności wymianę i trwałość.,
te „archetypy” (modele) są używane przez różne aplikacje, w tym w Narodowej służbie zdrowia Zjednoczonego Królestwa, gdzie są wykorzystywane do konwersji systemów cieni umożliwiających korzystanie z repozytoriów danych neutralnych dla dostawcy. Inni użytkownicy to: Queensland Health i niektóre prywatne szpitale dla swoich systemów kontroli zakażeń, szereg podstawowych placówek medycznych Western Sydney i wspólnego EHR Northern Territory Health oraz partnerzy branżowi openEHR, których systemy są szeroko wdrażane w krajach skandynawskich., Komponenty i systemy zgodne są „otwarte” Pod względem modeli danych i interfejsów API. Strategicznie, podejście openEHR ma rekord zdrowia ostrości dobrze dostosowane do opieki skoncentrowanej na pacjencie. Takie podejście umożliwia oparty na platformie lub „otwarty back-end” rynek oprogramowania, w którym dostawcy branży zdrowotnej i twórcy rozwiązań interfejsy ze sobą systemy za pomocą standardowych modeli informacyjnych, modeli treści, terminologii i interfejsów usług.,
otwarta współpraca osób fizycznych, przemysłu, organizacji normalizacyjnych i świadczeniodawców zgodziły się współpracować w celu przyspieszenia rozwoju otwartych standardów interoperacyjności w sektorze zdrowia i opieki społecznej. Zapewniły one wspólne forum wymiany doświadczeń i rozwiązań mających na celu przezwyciężenie tego zagmatwanego krajobrazu. W lipcu 2018 roku opublikowali przegląd tego, co zostało tutaj opisane . Zauważono, że te liczne standardy są w trakcie zbieżności. Standardy FHIR® i openEHR nie rozwiązują tego samego problemu., Oba modele tworzą kliniczne modele informacji, ale modele openEHR (archetypy) są niezależne od dostawców danych na platformach openEHR. FHIR® jest zorientowany na aplikacje, ponieważ tworzy wspólny model do wykorzystania w każdej aplikacji, aby następnie stanowić podstawę do zdefiniowania interoperacyjności między aplikacjami niezależnie od otwartych lub zastrzeżonych modeli, na których zostały zbudowane. Ci, którzy korzystają z rozwiązań interoperacyjnych zorientowanych na aplikacje, robią to, aby umożliwić dalsze korzystanie z drogich starszych systemów.,
openEHR i FHIR® zapewniają komplementarne, ale różne podejścia do łączenia złożonej mozaiki aplikacji w jeden spójny system . Podejście openehr skoncentrowane na danych koncentruje się najpierw na normalizacji danych dotyczących stanu zdrowia i budowaniu nowych systemów w oparciu o starsze systemy, aby uniknąć problemów związanych z interoperacyjnością. Chodzi o zdefiniowanie warstwy danych w otwartej architekturze systemu. Jest to najważniejsza warstwa, ponieważ ułatwia optymalne wykorzystanie danych w celu poprawy wyników, lepszego zarządzania chorobami przewlekłymi i lepszego zarządzania zdrowiem populacji., Wymaga to przechowywania danych w formatach neutralnych dla dostawcy, w przeciwieństwie do formatów zastrzeżonych większości starszych systemów. Podejście oparte na danych umożliwia przechowywanie i wykorzystywanie cyfrowych danych zdrowotnych przez cały okres życia każdego pacjenta.
prawie każdy system oparty na openEHR opracowuje obecnie interfejsy FHIR®, aby zapewnić, że mogą one wspierać podróż pacjenta między systemami openEHR i non-openEHR . openEHR connectivity schema może być zbudowany raz i udostępniony wszystkim dostawcom openEHR, ponieważ są one oparte na wspólnych archetypach openEHR., Aplikacje skupione na platformie openEHR nie wymagają rozwiązań exchange, takich jak FHIR®, ponieważ są w stanie komunikować się bezpośrednio ze sobą za pośrednictwem współdzielonych repozytoriów danych klinicznych. Dzięki temu nowi uczestnicy rynku mogą skoncentrować się na opracowywaniu prawdziwie innowacyjnych aplikacji i funkcjonalnie spełniać niszowe wymagania kliniczne. Pojemność FHIR® jest potrzebna tylko po to, aby umożliwić im komunikację z szerszymi aplikacjami zastrzeżonymi przez dostawców ekosystemu .
Leave a Reply