Interoperabilitet, standarder og skema
udvikling af Standarder aktiviteter, der er gennemført siden begyndelsen af 1980’erne med henblik på at levere løsninger til disse interoperabilitet udfordringer., Digital Imaging and Communications in Medicine (DICOM®), standarder udvalg af National Electrical Manufacturers Association (NEMA), var en af de første til at udvikle en standard for at kommunikere medicinsk billedbehandling oplysninger , som nu er offentliggjort af den Internationale Organisation for Standardisering (ISO12052:2017). Alle Health Level Seven (HL7) standarder offentliggøres af en officiel national standards organi .ation, American National Standards Institute (ANSI)., Det er vigtigt at bemærke, at HL7 (sundhedsniveau syv) standarder fokuserer på Teknisk interoperabilitet (udveksling af sundhedsdata), hvilket resulterer i begrænset operationel (semantisk) interoperabilitet .
den nu meget populære Fast Healthcare Interoperability Resources (FHIR)) standard har i høj grad forbedret operationelle informationsstrømme . HL7 FHIR reference referencemodellen er defineret af en samling informationsmodeller (ressourcer). Disse kan profileres (eller ikke) for at generere en klinisk informationsmodel., FHIR resources ressourcer er produceret fra et supersæt af data, der findes i ældre systemer, der skal bruges direkte af udviklere. Strengt taget er disse ikke “modeller”, da ingen af de sædvanlige arv, indkapsling af fælles elementer eller typepraksis anvendes. Den vellykkede brug af FHIR standard-standarden afhænger af graden af enighed mellem parterne. At nå til enighed på denne måde er lettere at opnå inden for organisationer af et lille antal interessenter, herunder klinikere, end aftaler, der passer til mere omfattende netværk. Dette begrænser mulighederne for genbrug af Soft .are .,en gennemgang af seks Amerikanske Medicare-ansvarlige plejeorganisationer har igen fremhævet behovet for at vedtage en standardmetode. Det blev konstateret, at de, der brugte et enkelt elektronisk patientjournalsystem på tværs af deres udbydernetværk, var i stand til at dele data i realtid, hvilket forbedrede udbydernes evne til at koordinere pleje. Andre havde adgang til robuste sundhedsinformationsudvekslinger, der gjorde det muligt at få adgang til patientdata fra eksterne udbydere. På trods af dette blev det bemærket, at det fulde potentiale af sundhed det er ikke blevet realiseret.,e resultatet af dårlig interoperabilitet gå på kompromis med kapaciteten til at passe, hvilket resulterer i:
•
Afhængigheden af andre midler til at dele data, herunder telefonopkald og faxer,
•
Belastende og frustrerende brug af EHRs,
•
Lægen udbrændthed på grund af arbejdsbyrden forbundet med EPJ-management,
•
Adgang til sundhed udveksling af information med lille eller ufuldstændige data oprettelse af vanskeligheder med hensyn til pleje koordinering,
•
manglende Evne til at tilbyde sundheds-IT til andre patienter end online-portaler til deres EHRs,
•
manglende Evne til at bruge analytics til at tilpasse sig for at passe en enkelte patients behov.,
et initiativ fra den private sektor er i øjeblikket ved at gennemføre et projekt, der sigter mod at fremme industriens vedtagelse af moderne, åbne interoperabilitetsstandarder kendt som Argonaut-projektet . Formålet med dette projekt er at udvikle en første generation af FHIR based-baseret API og Core Data Services-specifikation for at muliggøre udvidet informationsdeling til elektroniske patientjournaler og anden sundhedsinformationsteknologi baseret på internetstandarder og arkitektoniske mønstre og stilarter. Dette arbejde bliver sponsoreret af mange leverandører, herunder Cerner, Epic og Accenture., Omfanget af dette arbejde handler om at fremskynde FHIR® model udvikling ved at fokusere på mere specifikke FHIR® – profiler og dokumentation, herunder fokus på medfølgende sikkerheds specifikationer og dokumentation for at gøre det muligt at opnå interoperabilitet mellem ældre proprietære systemer, hvor deres leverandører er kontraktligt kontrol med adgang til data. Brugen af disse API ‘ er skaber iboende risici for fejl og patientsikkerhed på grund af datakortlægning.
sundhedsorganisationer er nu i færd med at styre den hurtige optagelse af FHIR and og den større anvendelse af API ‘ er., Fra et nationalt infrastrukturperspektiv skal der være midler til at lette genanvendelsen af nogle ofte anvendte FHIR models-nøglemodeller. Disse kan vælges til at blive godkendte HL7 standarder. Uden vedtagelse af aftalte standardmodeller vil der være en spredning af FHIR models-modeller udviklet til at imødekomme lokale behov, mange gentagelser og uoverensstemmelser, der begrænser de samlede nationale fremskridt hen imod at opnå et godt forbundet digitalt sundhedsøkosystem., FHIR® – modeller ikke er i overensstemmelse med vel-kendte modellering konventioner, som det fremgår af Beale, der konkluderede, at:
FHIR ressourcer synes at være resultatet af et særskilt udvalg, der arbejder med næsten ingen krydsreferencer, metode, eller fælles. Resultatet er, at hver ressource er noget som en “taske af attributter”, formodentlig på grund af anvendelsen af den såkaldte 80/20-regel i udvalgskonteksten.
FHIR models-modeller skal overveje et meget stort og uhåndterligt antal datapunkter., Denne begrænsning overvindes ved vedtagelse af generiske modeller, der er perfekt egnede til messaging, men ikke til semantisk sammenhængende klinisk datalagring. Kontekst er integreret i, hvordan klinikere behandler information. Kontekst skal overvejes, når der udvikles beslutningsstøtte eller kunstige intelligenssystemer, når der vedtages forskellige dataanalysestrategier og for et hvilket som helst antal relevante standarder, herunder dem, der anvendes til datakortlægning.,
FHIR resources — ressourcerne siges at indeholde et kontinuum af ontologiske niveauer, de har to egenskaber uønskede i en stabil informationsmodel:
volatilitet-klinisk specifikke ressourcer skal klart ændres over tid. Hvordan dette påvirker afhængige profiler er et interessant spørgsmål;
åbenhed-man må antage, at ressourcesættet simpelthen fortsætter med at vokse for at imødekomme nye større kliniske informationskategorier.,
konsekvenserne af disse faktorer er, at modellen er “aldrig færdig”, og at enhver databaser eller software baseret på det vil ligeledes skal fortsat vedligeholdelse. Der er et andet problem forbundet med Do .nstream information-behandling til sekundær databrug. Det er en manglende evne til at vide, om datastrukturer, der synes at være næsten det samme, kan behandles på samme måde; standard med FHIR er, at hver ressource er sin egen ting ., En internationale standarder sagkyndige bemærkede, at:
FHIR® er designet og beregnet som et API/interchange standard, de fleste større ITC organisationer (Google, Microsoft, IBM, osv.) og mindst én større EPJ-leverandør (Cerner) har taget FHIR® som en vedholdenhed objekt skema og datastore skema. FHIR remains forbliver underspecificeret på internationalt plan, da bindingen af værdisæt henvises til implementeringsvejledninger (f.eks., I betragtning af de nuværende nationale tilbøjeligheder i retning af national Health Information Technology (HIT) koder (stort set alle lande har deres egne darn offentliggørelse af Procedure-koder, og underligt hele verden endnu ikke er bruger ICD11) denne adskillelse er meget pragmatisk. Hindringerne for international hit interoperabilitet har mindre at gøre med tekniske syntaksspecifikationer, og langt mere at gøre med den næsten uhåndterlige tendens i lande til at specificere deres egne, undertiden proprietære, kodningssystemer.,
Vedtagelsen af openEHR arkitektoniske rammer kræver brug af en mere omfattende modellering tilgang . Disse modeller er i stand til at forbinde med FHIR® – modeller, hvor det er påkrævet, for eksempel openEHR bivirkning risiko arketype og FHIR® AllergyIntolerance ressource i fællesskab udgivet og er justeret i slutningen af 2015., Arketyper inkorporerer det samarbejde, der udføres af et stort virtuelt internationalt samfund af tværfaglige fagfolk, der omdanner sundhedsdata til en evidensbaseret elektronisk (beregnelig) form for at sikre universel interoperabilitet inden for ethvert digitalt sundhedsøkosystem. Denne tilgang består af multi-level, enkelt kilde modellering inden for en serviceorienteret soft .arearkitektur afgrænset af et sæt SPECIFIKATIONER udgivet af openEHR foundation og frit tilgængelige for alle.,
openEHR er en åben standardspecifikation, der styres af et non-profit-fundament, det er frit tilgængeligt for at blive implementeret af enhver udvikler. OpenEHR specifikationer, resultatet af 25 års forskning og udvikling, repræsenterer den eneste alvorlige instantiering af ISO 13606 Reference Model for elektronisk patientjournal kommunikation, der i detaljer beskriver en hierarkisk struktur for klinisk information . Denne standard bliver i stigende grad brugt i massive projekter i Storbritannien, Norge, Finland, Slovenien og Tyskland., Også Kina, Chile, Brasilien, Italien og Caribien har vedtaget denne tilgang. Faktisk blev ISO 13606 afledt af erfaringerne fra openEHR, og for nylig er blevet påvirket gennem erfaring med andre standarder, herunder FHIR.. Det kliniske modelleringsarbejde er mere omfattende end det, der blev foretaget andre steder tidligere med et frivilligt samfund på over 2000 mennesker fra 93 lande.
de ISO13606 domæne kliniske modeller kendt som “arketyper” er uden for soft .aren., Hver arketype definerer et maksimalt antal mulige datapunkter og datagrupper, der gælder for det modellerede koncept. Dette giver mulighed for et maksimalt antal forskellige sammenhænge, der passer til alle kliniske specialiteter og potentielle dataanvendelser. Skabeloner, der består af et” rekombination ” – lag af modeller til at definere datasæt, bruger kun de datapunkter fra et sæt (ethvert antal eller valg) af arketyper, der kræves til en bestemt “brugssag” eller applikation, såsom enhver form for klinisk vurdering., Skabeloner kan bruges som meddelelsesdefinitioner for ældre systemer samt datasæt til nye applikationer, herunder formularer. Dette betyder, at ethvert sæt arketyper kan genbruges til flere brugssager. Det gør det muligt for betydelige dele af Soft .aren at være maskinafledt fra arketyperne. Arketyper repræsenterer atomdata i en åben standard; en kritisk succesfaktor, der er i stand til at modstå ændringer i teknologi, især udveksling og vedholdenhed.,
disse “arketyper” (modeller) bruges af forskellige applikationer, herunder i Det Forenede Kongeriges nationale sundhedsvæsen, hvor de bruges til konvertering af skyggesystemer, der muliggør brug af leverandørneutrale datalagre. Andre brugere er: Healthueensland Health og nogle private hospitaler til deres infektionskontrolsystemer, en række vestlige Sydney primære sundhedsfaciliteter og Northern Territory Health ‘ s delte EPJ og openEHR-industripartnere, hvis systemer er bredt implementeret i skandinaviske lande., Overensstemmende komponenter og systemer er “åbne” med hensyn til datamodeller og API ‘ er. Strategisk har openEHR-tilgangen et sundhedsrekordfokus, der er velegnet til patientcentreret pleje. Denne tilgang muliggør et platformbaseret eller” åbent back-end ” soft .aremarked, hvor leverandører af sundhedsindustrien og løsningsudviklere interface med hinandens systemer via standardiserede informationsmodeller, indholdsmodeller, terminologier og servicegrænseflader.,
et åbent samarbejde mellem enkeltpersoner, industri, standardiseringsorganisationer og sundhedsudbydere har aftalt at arbejde sammen for at fremskynde udviklingen af åbne standarder for interoperabilitet i den sundhedsmæssige og sociale sektor. De har leveret et samarbejdsforum til at dele erfaringer og levere løsninger, der sigter mod at overvinde dette forvirrende landskab. I juli 2018 offentliggjorde de en oversigt over, hvad der er beskrevet her . Det blev bemærket, at disse mange standarder er i færd med at konvergere. FHIR standards-og openEHR-standarderne løser ikke det samme problem., De skaber begge kliniske informationsmodeller, men openEHR-modellerne (arketyper) er datacentriske leverandøruafhængige på tværs af openEHR-platforme. FHIR is er applikationscentrisk, da det skaber en fælles model til brug på tværs af enhver applikation for derefter at danne grundlaget for at definere interoperabilitet mellem applikationer uanset åbne eller proprietære modeller, de blev bygget på. De, der gør brug af applikationscentriske interoperabilitetsløsninger, gør det for at muliggøre fortsat brug af dyre ældre systemer.,
openEHR og FHIR provide giver komplementære, men forskellige tilgange til at forbinde et komplekst patch ofork af applikationer til et enkelt sammenhængende system . Den datacentriske openEHR-tilgang fokuserer først på at normalisere sundhedsdataene og opbygge nye systemer oven på ældre systemer for at undgå interoperabilitetsproblemer sammen. Det handler om at definere et datalag inden for en åben systemarkitektur. Dette er det vigtigste lag, da det letter optimal dataanvendelse til at forbedre resultaterne, bedre håndtere kroniske sygdomme og muliggøre bedre befolkningssundhedsstyring., Dette kræver, at data gemmes i leverandørneutrale formater i modsætning til proprietære formater af de fleste ældre systemer. Den datacentriske tilgang muliggør lagring og brug af digitale sundhedsdata i hele enhver patients levetid.
næsten alle openEHR-baserede systemer udvikler i øjeblikket FHIR interfaces-grænseflader for at sikre, at de kan understøtte patientens rejse mellem openEHR og ikke-openEHR-systemer . openEHR connectivity schema kan bygges andn gang og deles mellem alle openEHR leverandører, da de er baseret på fælles openEHR arketyper., Applikationer grupperet på en openEHR – baseret platform behøver ikke udvekslingsløsninger som FHIR because, fordi de er i stand til at kommunikere direkte med hinanden gennem delte kliniske datalagre. Dette giver nye markedsdeltagere mulighed for at koncentrere sig om at udvikle virkelig innovative applikationer og funktionelt opfylde nichekliniske krav. FHIR capacity kapacitet er kun nødvendig for at sætte dem i stand til at kommunikere med bredere økosystem leverandør proprietære applikationer .
Leave a Reply