Interoperability standards and schema
Standards development activiteiten die sinds het begin van de jaren tachtig werden ondernomen om oplossingen te bieden voor deze interoperabiliteitsuitdagingen., De Digital Imaging and Communications in Medicine (DICOM®), standards committee van de National Electrical Manufacturers Association (NEMA), was een van de eersten die een standaard ontwikkelde voor het communiceren van medische beeldvormingsinformatie, nu gepubliceerd door de Internationale Organisatie voor normalisatie (ISO12052:2017). Alle normen van gezondheidsniveau zeven (HL7) worden gepubliceerd door een officiële nationale normalisatie-instelling, het American National Standards Institute (ANSI)., Het is belangrijk op te merken dat HL7-normen (gezondheidsniveau zeven) zich richten op technische interoperabiliteit (uitwisseling van gezondheidsgegevens), wat resulteert in beperkte operationele (semantische) interoperabiliteit .
de nu zeer populaire Fast Healthcare Interoperability Resources (FHIR®) standaard heeft de operationele informatiestromen aanzienlijk verbeterd . Het HL7 FHIR ® referentiemodel wordt gedefinieerd door een verzameling informatiemodellen (bronnen). Deze kunnen worden geprofileerd (of niet) om een klinisch informatiemodel te genereren., FHIR ® – bronnen worden geproduceerd uit een superset van gegevens in legacy-systemen die rechtstreeks door ontwikkelaars worden gebruikt. Strikt genomen zijn dit geen “modellen” omdat geen van de gebruikelijke overerving, inkapseling van gemeenschappelijke elementen of typepraktijken worden gebruikt. Het succesvol gebruik van de FHIR® – standaard is afhankelijk van de mate van overeenstemming tussen de partijen. Het bereiken van overeenstemming op deze manier is gemakkelijker binnen organisaties door een klein aantal stakeholders, waaronder clinici, dan overeenkomsten voor uitgebreidere netwerken. Dit beperkt mogelijkheden voor hergebruik van software .,
een overzicht van zes Amerikaanse zorgorganisaties die verantwoordelijk zijn voor Medicare heeft opnieuw de noodzaak aangetoond van een standaardbenadering. Het bleek dat degenen die gebruik maakten van een enkel elektronisch systeem voor gezondheidsdossiers in hun netwerk van aanbieders, in staat waren om gegevens in real time te delen, waardoor het vermogen van aanbieders om zorg te coördineren werd verbeterd. Anderen hadden toegang tot robuuste uitwisseling van gezondheidsinformatie die toegang bood tot patiëntgegevens van externe zorgverleners. Ondanks dit werd opgemerkt dat het volledige potentieel van de gezondheid is niet gerealiseerd.,e het resultaat van een slechte interoperabiliteit afbreuk te doen aan de capaciteit om zorg die resulteert in:
•
de Afhankelijkheid van andere middelen om gegevens te delen met inbegrip van telefoontjes en faxen,
•
Omslachtig en frustrerend gebruik van EHRs,
•
Arts burn-out als gevolg van de werklast verbonden met EPD-management,
•
de Toegang tot de gezondheidszorg informatie-uitwisseling met weinig of onvolledige gegevens maken moeilijkheden met betrekking tot de zorg coördinatie,
•
niet kunnen aanbieden van gezondheidszorg aan patiënten van andere dan de online portals van hun EHRs,
•
het Onvermogen om google analytics te gebruiken voor het aanpassen van de zorg aan een individuele patiënt nodig heeft.,
een initiatief van de particuliere sector voert momenteel een project uit om de invoering door de industrie van moderne, open interoperabiliteitsnormen, bekend als het Argonaut-project, te bevorderen . Het doel van dit project is het ontwikkelen van een eerste generatie FHIR®-gebaseerde API en Core Data Services specificatie om uitgebreide informatie-uitwisseling mogelijk te maken voor elektronische gezondheidsdossiers en andere gezondheidsinformatietechnologie gebaseerd op internetstandaarden en architectonische patronen en stijlen. Dit werk wordt gesponsord door tal van leveranciers, waaronder Cerner, Epic en Accenture., Het doel van dit werk is het versnellen van de ontwikkeling van FHIR® – modellen door zich te richten op meer specifieke FHIR® – profielen en documentatie, inclusief een focus op de bijbehorende beveiligingsspecificaties en documentatie om interoperabiliteit mogelijk te maken tussen Legacy propriëtaire systemen, waarbij hun leveranciers contractueel de toegang tot gegevens controleren. Het gebruik van deze API ’s creëert inherente risico’ s voor fouten en patiëntveiligheid als gevolg van data mapping.
gezondheidszorgorganisaties zijn nu bezig met het beheer van de snelle opname van FHIR® en het grotere Gebruik van API ‘ s., Vanuit het oogpunt van de nationale infrastructuur moeten er middelen zijn om het hergebruik van een aantal veelgebruikte FHIR®-modellen te vergemakkelijken. Deze kunnen worden gekozen om goedgekeurde HL7-normen te worden. Zonder de goedkeuring van overeengekomen standaardmodellen zal er een wildgroei zijn van FHIR®-modellen die zijn ontwikkeld om te voldoen aan lokale behoeften, vele herhalingen en inconsistenties die de algemene nationale vooruitgang in de richting van een goed verbonden digitaal gezondheidsecosysteem beperken., FHIR® – modellen voldoen niet aan bekende modelleringsconventies, zoals aangetoond door Beale die concludeerde dat:
De FHIR-middelen lijken het resultaat te zijn van afzonderlijke commissies die werken zonder kruisverwijzingen, methodologie of gemeenschappelijke ontwerpbasis. Het resultaat is dat elke bron zoiets is als een” zak van attributen”, vermoedelijk als gevolg van de toepassing van de zogenaamde 80/20-regel in de context van het Comité.
FHIR® – modellen moeten rekening houden met een zeer groot en onbeheersbaar aantal gegevenspunten., Deze beperking wordt opgeheven door de invoering van generieke modellen die perfect geschikt zijn voor messaging, maar niet voor semantisch samenhangende opslag van klinische gegevens. Context is een integraal onderdeel van hoe clinici informatie verwerken. De Context moet in aanmerking worden genomen bij de ontwikkeling van systemen voor beslissingsondersteuning of kunstmatige intelligentie, bij de vaststelling van verschillende strategieën voor gegevensanalyse en voor een aantal relevante normen, waaronder die welke worden gebruikt voor het in kaart brengen van gegevens.,
De FHIR ® bronnen zouden een continuüm van ontologische niveaus bevatten, ze hebben twee kenmerken die ongewenst zijn in een stabiel informatiemodel :
volatiliteit — klinisch specifieke bronnen zullen duidelijk in de loop van de tijd moeten veranderen. Hoe dit afhankelijke profielen beïnvloedt is een interessante vraag;
open-endedness-men moet aannemen dat de set van middelen gewoon zal blijven groeien om nieuwe belangrijke klinische informatiecategorieën tegemoet te komen.,
de gevolgen van deze factoren zijn dat het model “nooit voltooid” is en dat alle databases of software die erop gebaseerd is, eveneens continu onderhoud nodig zullen hebben. Er is nog een andere kwestie die verband houdt met downstream-informatieverwerking voor secundair gebruik. Dat is een onvermogen om te weten of datastructuren die lijken te zijn bijna hetzelfde kan worden behandeld op dezelfde manier; de standaard met FHIR is dat elke bron is zijn eigen ding ., Een internationale standaarden expert merkte op dat:
FHIR® is ontworpen en bedoeld als een API/interchange standaard, de meeste grote ITC-organisaties (Google, Microsoft, IBM, enz.) en ten minste een belangrijke EHR leverancier (Cerner) hebben FHIR® omarmd als een persistence object schema en datastore schema. FHIR® blijft onderspecificeerd op internationaal niveau, omdat de binding van waarde sets wordt verwezen naar implementatiegidsen (bijvoorbeeld de US Core FHIR® implementation guide)., Gezien de huidige nationale predisposities voor nationale gezondheidsinformatietechnologie (HIT) codes (vrijwel elk land heeft zijn eigen verdomde publicatie van Procedurecodes, en vreemd genoeg gebruikt de hele wereld nog geen ICD11) is deze scheiding zeer pragmatisch. De belemmeringen voor internationale HIT-interoperabiliteit hebben minder te maken met technische syntaxisspecificaties, en veel meer met de bijna hardnekkige neiging van landen om hun eigen, soms propriëtaire, coderingssystemen te specificeren.,
het gebruik van het openEHR architectural framework vereist het gebruik van een uitgebreidere modelleringsbenadering . Deze modellen kunnen waar nodig worden gekoppeld aan FHIR® – modellen, bijvoorbeeld het openEHR Adverse reaction risk archetype en FHIR® AllergyIntolerance resource werden eind 2015 gezamenlijk gepubliceerd en op elkaar afgestemd., Archetypen omvatten het gezamenlijke werk van een grote virtuele internationale gemeenschap van multidisciplinaire professionals die gezondheidsgegevens omzetten in een evidence based elektronische (computable) vorm om universele interoperabiliteit binnen elk digitaal gezondheidsecosysteem te waarborgen. Deze aanpak bestaat uit multi-level, single source modellering binnen een service-georiënteerde softwarearchitectuur die wordt afgebakend door een set van specificaties gepubliceerd door de openEHR foundation en vrij beschikbaar is voor iedereen.,
de openEHR is een open standaard specificatie beheerd door een non-profit stichting, Het is vrij beschikbaar om te worden geïmplementeerd door elke ontwikkelaar. OpenEHR SPECIFICATIES, het resultaat van 25 jaar onderzoek en ontwikkeling, vormen de enige serieuze instantiatie van het ISO 13606 referentiemodel voor elektronische medische dossiers communicatie dat een hiërarchische structuur voor klinische informatie detailleert . Deze norm wordt steeds vaker gebruikt in grootschalige projecten in het Verenigd Koninkrijk, Noorwegen, Finland, Slovenië en Duitsland., Ook China, Chili, Brazilië, Italië en het Caribisch gebied hebben deze aanpak gevolgd. In feite is ISO 13606 afgeleid van de ervaring van openEHR, en meer recent is beïnvloed door de ervaring met andere normen, waaronder FHIR®. De klinische modellering werk is uitgebreider dan die ergens anders eerder ondernomen met een vrijwilligersgemeenschap van meer dan 2000 mensen uit 93 landen.
De ISO13606 domein klinische modellen bekend als “archetypes” zijn extern aan de software., Elk archetype definieert een maximum aantal mogelijke datapunten en gegevensgroepen die van toepassing zijn op het gemodelleerde concept. Dit zorgt voor een maximaal aantal verschillende contexten die geschikt zijn voor alle klinische specialiteiten en potentiële data-toepassingen. Templates, bestaande uit een” recombinatielaag “van modellen om datasets te definiëren, maken gebruik van alleen die datapunten van een set (een willekeurig aantal of selectie) van archetypen die vereist zijn voor een specifieke” use case ” of toepassing, zoals elk type klinische beoordeling., Sjablonen kunnen worden gebruikt als berichtdefinities voor oudere systemen, evenals datasets voor nieuwe toepassingen, waaronder formulieren. Dit betekent dat elke set van archetypes kan worden hergebruikt voor meerdere use cases. Het maakt het mogelijk dat belangrijke delen van de software machine-afgeleid zijn van de archetypes. Archetypen vertegenwoordigen atomaire gegevens in een open standaard; een kritische succesfactor die bestand is tegen veranderingen in technologie, met name uitwisseling en persistentie.,
Deze “Archetypes” (modellen) worden gebruikt door verschillende toepassingen, waaronder in de Britse National Health Service, waar ze worden gebruikt voor de conversie van schaduwsystemen die het gebruik van vendor neutral data repositories mogelijk maken. Andere gebruikers zijn: Queensland Health en een aantal particuliere ziekenhuizen voor hun infectie controle systemen, een aantal Westerse Sydney primaire gezondheidsfaciliteiten en de Northern Territory Health ‘ s Gedeelde EPD, en openEHR industrie partners waarvan de systemen worden op grote schaal geïmplementeerd in Scandinavische landen., Conforme componenten en systemen zijn “open” in termen van datamodellen en API ‘ s. Strategisch gezien heeft de openEHR-aanpak een gezondheidsrecordfocus die geschikt is voor patiëntgerichte zorg. Deze aanpak maakt een platformgebaseerde of “open back-end” softwaremarkt mogelijk waarin leveranciers uit de gezondheidsindustrie en ontwikkelaars van oplossingen met elkaar communiceren via gestandaardiseerde informatiemodellen, inhoudsmodellen, terminologieën en service-interfaces.,
een OPEN samenwerking van individuen, het bedrijfsleven, normalisatie-instellingen en zorgaanbieders is overeengekomen samen te werken om de ontwikkeling van open normen voor interoperabiliteit in de gezondheidszorg en de sociale sector te versnellen. Ze hebben een gezamenlijk forum voor het delen van ervaringen en het bieden van oplossingen gericht op het overwinnen van dit verwarrende landschap. In juli 2018 publiceerden ze een overzicht van wat hier is beschreven . Er werd opgemerkt dat deze vele normen aan het convergeren zijn. De FHIR® – en openEHR-standaarden pakken niet hetzelfde probleem aan., Ze maken beide klinische informatiemodellen, maar de openEHR-modellen (archetypes) zijn datacentersonafhankelijk voor alle openEHR-platforms. FHIR® is application centric omdat het een gemeenschappelijk model creëert voor gebruik in elke toepassing om vervolgens de basis te vormen voor het definiëren van interoperabiliteit tussen applicaties, ongeacht de open of propriëtaire modellen waarop ze zijn gebouwd. Degenen die gebruikmaken van applicatiegerichte interoperabiliteitsoplossingen doen dit om het voortdurende gebruik van dure oudere systemen mogelijk te maken.,
openEHR en FHIR® bieden complementaire maar verschillende benaderingen om een complex lappendeken van toepassingen in één samenhangend systeem te verbinden . De data centric openEHR aanpak richt zich op het normaliseren van de gezondheidsgegevens eerst, en het bouwen van nieuwe systemen op de top van legacy systemen om de interoperabiliteit problemen allemaal te voorkomen. Dit gaat over het definiëren van een datalaag binnen een open systeemarchitectuur. Dit is de belangrijkste laag omdat het een optimaal gebruik van gegevens mogelijk maakt om de resultaten te verbeteren, chronische ziekten beter te beheren en een beter beheer van de volksgezondheid mogelijk te maken., Dit vereist dat gegevens worden opgeslagen in leverancierneutrale formaten in tegenstelling tot propriëtaire formaten van de meeste oudere systemen. De data centric approach maakt digitale opslag en gebruik van gezondheidsgegevens mogelijk gedurende de hele levensduur van elke patiënt.
bijna elk op openEHR gebaseerd systeem ontwikkelt momenteel FHIR®-interfaces om ervoor te zorgen dat deze de reis van de patiënt tussen openEHR-en niet-openEHR-systemen kunnen ondersteunen . openEHR connectivity schema kan eenmaal worden gebouwd en gedeeld tussen alle openEHR-leveranciers, omdat ze zijn gebaseerd op gemeenschappelijke openEHR archetypes., Applicaties geclusterd op een openEHR – gebaseerd platform hebben geen uitwisselingsoplossingen nodig zoals FHIR®, omdat ze rechtstreeks met elkaar kunnen communiceren via gedeelde klinische dataopslagplaatsen. Dit stelt nieuwkomers in de markt in staat zich te concentreren op het ontwikkelen van echt innovatieve toepassingen en functioneel te voldoen aan niche klinische eisen. FHIR ® capaciteit is alleen nodig om hen in staat te stellen om te communiceren met bredere ecosysteemleveranciers propriëtaire applicaties .
Leave a Reply