Från Meddelandeutväxling till Semantisk Interoperabilitet
•Télécharger en tant que PPTX, PDF•
2 j'aime•993 vues
Från Meddelandeutväxling till Semantisk Interoperabilitet, från Vitalis 2015.
Recommandé
Recommandé
Contenu connexe
Similaire à Från Meddelandeutväxling till Semantisk Interoperabilitet
Similaire à Från Meddelandeutväxling till Semantisk Interoperabilitet (20)
Från Meddelandeutväxling till Semantisk Interoperabilitet
- 1. Från meddelandeutväxling till semantisk interoperabilitet Vitalis 2015 Oskar Thunman @oskthu
- 2. Om mig • Medicinsk informatiker • Informationsarkitekt på Callista Enterprise • Regionala, nationella och internationella projekt • IHE och CDA
- 3. Innehåll • Semantisk interoperabilitet • Bakgrund • Nuläge • Framtidens smarta plattformar för vården
- 4. Semantisk interoperabilitet Semantisk interoperabilitet handlar om hur man bäst kodar, överför och använder... inte data utan information och kunskap • Från medborgare/patienter, medicinsk vetenskap och andra kunskapskällor • Mellan språkmässigt och kulturells skilda professioner, patienter, myndigheter och andra aktörer • Över system- och organisationsgränser.
- 5. Vad består vårdens informationssystem av? Informationsmodell Patientdata NI Koncept Domänkunskap NF Riktlinjer Beslutstöd/dynamisk kunskap
- 8. HL7 RIM v2
- 9. 1996 1998 2000 2002 2004 2006 2008 2010 2012 1987 HL7 v2.x HL7 v 3 CDA ebXML IHE iti årlig uppdatering FHIR 2016 openEHR 13606 meddelandeformat transport/ infrastruktur Standarder i Hälso- och sjukvård
- 10. Vad är det man vill lösa?
- 11. Intraorganisatoriska kontra interorganisatoriska utmaningar EHR LIS RIS eRx HIE EHR EHR EHR EHR
- 12. Fast informationsförsörjningen är lite mer komplex än så… Vårdgivare Andra vårdgivare Myndigheter Patienter/medborgareKvalitets-uppföljning Forskning
- 13. Meddelanden 13
- 14. HL7 v2 • Bra inom en organisation • Ett hundratal användningsfall stödjs • Skalar ej för interorganisatoriskt utbyte • (För) stor valfrihet gällande teminologi • Saknar RIM EHR LIS RIS eRx
- 16. HL7 v3, CDA • Pappersanalogi – dokumentbaserat, mänskligt läsbart, titel och rubriker • Passar metodiken för många till många-kontrakt, stor valfrihet. • Stor overhead, ej fingranulärt • All verksamhetslogik i specen • Implicit SOAP – Version 1 tar tid – Svårt att versionera – Krångligt bygga workflow HIE EHR EHR EHR EHR
- 17. Standardiseringens dilemma I (rätt) tid UttömmandeKorrekt
- 18. FHIR Fast Healthcare Interoperability Resources • ”Recept” på API:er att tillhandahålla istället för specar på dokument att producera. • Första HL7 standard under öppen licens • REST – XML och JSON – Oauth – Atom-liknande stöd för prenumeration • Både infrastruktur och kliniska data • Förenar det intraorganisatoriska med det interorganisatoriska • Mobilvänligt, utvecklarvänligt
- 19. Exempel FHIR <?xml version="1.0" encoding="UTF-8"?> <MedicationAdministration xmlns="http://hl7.org/fhir"> <identifier> http://myapplication.com/medicationAdministration/1 </identifier> <status value="inProgress"/> <patient> http://myapplication.com/patient/7 </patient> <practitioner> http://myapplication.com/practitioner/1234 </practitioner> <encounter> http://myapplication.com/encounter/4734982359 </encounter> <prescription> http://myapplication.com/prescription/23092509725 </prescription> <whenGiven>201401010</whenGiven> <medication> http://myapplication.com/medication/24095092 </medication> <device> http://myapplication.com/device/2 </device> <dosage> <!-- 0..* Medicine administration instructions to the patient/carer --> <timing[x]><!-- 0..1 dateTime|Period When dose(s) were given --></timing[x]> <asNeeded[x]><!-- 0..1 boolean|CodeableConcept Take "as needed" f(or x) --></asNeeded[x]> <site><!-- 0..1 CodeableConcept Body site administered to --></site> <route><!-- 0..1 CodeableConcept Path of substance into body --></route> <method><!-- 0..1 CodeableConcept How drug was administered --></method> <quantity><!-- 0..1 Quantity Amount administered in one dose --></quantity> <rate><!-- 0..1 Ratio Dose quantity per unit of time --></rate> <maxDosePerPeriod><!-- 0..1 Ratio Total dose that was consumed per unit of time -- ></maxDosePerPeriod> </dosage> </MedicationAdministration> 19
- 20. Stödjer flera arkitektoriella stilar • REST A B C D • Document • Message • Service
- 21. FHIR specas med en 80/20 regel BP Systolic: 120 Diastolic: 80 BP Systolic: 120 Diastolic: 80 Position: Seated BP:120/80 System A System B System C Frivillig Tvingande extension Bas-spec
- 23. RDF och framtiden Informationsmodell Patientdata NI Koncept Domänkunskap NF Riktlinjer Beslutstöd/dynamisk kunskap RDF The Yosemite Manifesto 1. RDF is the best available candidate for a universal healthcare exchange language. 2. Electronic healthcare information should be exchanged in a format that either: (a) is an RDF format directly; or (b) has a standard mapping to RDF. 3. Existing standard healthcare vocabularies, data models and exchange languages should be leveraged by defining standard mappings to RDF, and any new standards should have RDF representations. 4. Government agencies should mandate or incentivize the use of RDF as a universal healthcare exchange language. 5. Exchanged healthcare information should be self-describing, using Linked Data principles, so that each concept URI is de-referenceable to its free and open definition.
- 24. Tack!
Notes de l'éditeur
- Redan 1986 bildades en intressegrupp (MEDIX) kring informationsutbyte inom sjukvården som en del av IEEE Behov av en gemensam begreppsrymd för informationselement Bygger på objektorientering Meta-model standard, saknades i HL7 v2, gav en skjuts åt arbete med standardisering av hälsoinformation för t ex CEN och OpenEHR Övergick till internationellt samarbete mellan HL7, DICOM m fl för harmonisering
- Harmoniseringsarbetet ledde till konceptet av en referensinformationsmodell som samlade alla informationselement som underliggande standarder höll för att säkerställa semantisk interoperabilitet. Grunden OpenEHR:s aketyp-tänk Starten på HL7:s v3, och framväxten av en jättemodell över all information
- Genom genralisering och typning av klasser kunde modellen krympa från 120 till 40 klasser. Källa http://www.healthintersections.com.au/?p=188
- Två delar, meddelandeformat, transport och infrastruktur Meddelandeformat har även ett europeiskt initiativ, OpenEHR, För transport är valet i praktiken ebXML eller eget, HL7 v3 i XML gjordes innan XML-schema fanns
- Vad är det då man vill lösa?
- Modell/terminologi: informationskvalitén är dålig för användning av information utanför ursprungliga användningsfallet. Ej delmängder av ett kanoniskt meddelandeformat
- Intraoperabilitet, intraorganisatoriskt utbyte Inte så mycket utbyte som push-flöden från system till system för en mängd användningsfall.
- Text för mänsklig läsbarhet Titel och rubrik
- endast kunnat uppnå en minsta gemensamma nämnare mellan de inblandade systemen I praktiken tog många institutioner ett exempelmeddelande och strösslade med de värden de hade i sina system och hoppades att det skulle validera mot schemat. Problemet är att man måste sätta någon i mitten som hanterar drift, avtal Vill journalsystem X tllgängliggöra en ny parameter så måste en ny version av tjänsten tas fram och alla som skall konsumera
- Tagit det bästa från tidigare HL7-standarder, datatyper, domänmodeller,
- REST: Små resurser, patient, vårdenhet, åtgärd, diagnos etc. Med unika identiteter för varje resurts, i en RESTful designfilosofi. Dessa resurser utgör den minsta enheten för en transaktion. Document, Flera resurser kan paketeras som ett ”dokument”, men en header som säger något om innehållet. Bakåtkompabilitet mot CDA, den dokumentbaserade standarden som är den dominerande lösningen idag, även för hantering av t ex remisser och myndighetsrapportering där mottagaren förväntar sig att få ett dokument. Message, länge ingick ATOM-formatet som en metod att prenumerera på uppgifter, men nu har man övergått till ett eget format som både stödjer puch och pull genom en notifieringsfunktion. Service, vill man så går det så klart att packetera resurser eller kluster av resurser som web services för att göra RPC:er mot dem. REST och SOAP är inte två rivaliserande metoder utan REST är en arkitektoriell stil och SOAP är ett protokoll.
- Enkelt då många domäner redan är dokumenterade Extensions löser standardiseringens dilemma Kan vara obligatoriska för en konsument att förstå eller frivilliga Tillgängliggörs som en resurs-profil, även de som en resurs
- Sätter man ihop alla dessa delar får man en öppen plattformsarkitektur Som möjliggör ett ekosystem med tunga affärssystem, journalsystem i botten och ovanpå det kan man utveckla innovativa web och mobil appar. Journalsystemen väljer att tillgängliggöra hela eller delar av sin data via ett FHIR-API Ovanpå det kan man bygga appar för kliniska specialiteter, eller tillhandahålla funktionalitet i patientportaler Med hjälp av det standardiserade API:et vet dessa appar var de hittar rätt information. Vill man veta om data finns tillgängligt tittar man i profile-resursen.