FHIR och interoperabilitet i sjukvården
•Transferir como PPTX, PDF•
1 gostou•575 visualizações
Presentation från Cadec 2015 om interoperabilitet i sjukvården med fokus på vad API:er i allmänhet och FHIR i synnerhet kan erbjuda.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a FHIR och interoperabilitet i sjukvården
Semelhante a FHIR och interoperabilitet i sjukvården (9)
FHIR och interoperabilitet i sjukvården
- 1. | CALLISTAENTERPRISE.SE FHIR OCH INTEROPERABILITET I SJUKVÅRDEN OSKAR THUNMAN 2015-01-29
- 2. FHIR OCH INTEROPERABILITET I SJUKVÅRDEN • Semantisk interoperabilitet • Bakgrund • Dagens standarder • FHIR och framtidens smarta plattformar för vården
- 3. SEMANTISK INTEROPERABILITET INOM HÄLSO- OCH SJUKVÅRD 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.
- 4. INTEROPERABILITET I SVENSK SJUKVÅRD, SNABBVERSIONEN • 1980-2000 sker en datorisering av vården • 2001 använder hälften av alla läkare ett elektroniskt journalsystem och idag är siffran ca 99% • Sedan 2004 pågår arbete med nationell infrastruktur för att få informationen att följa patienten mellan vårdgivare och över systemgränser
- 5. INTRAOPERABILITET VS INTEROPERABILITET EHR LIS RIS eRx HIE EHR EHR EHR EHR Intraorganisatoriskt kontra interorganisatoriskt <<Radiologisystem>> <<eRemisser>><<Laboratoriesystem>> <<Journalsystem>> <<Integrationsplattform>>
- 6. FAST INFORMATIONSFÖRSÖRJNINGEN ÄR LITE MER KOMPLEX ÄN SÅ… Vårdgivare Andra vårdgivare Myndigheter Patienter/medborgareKvalitets-uppföljning Forskning
- 7. HL7 • Står för Health Level Seven • Amerikansk icke-vinstdrivande standardiseringsorganisation • HL7 v2 – standardiserade meddelanden för specifika användningsfall, datatyper • HL7 v3 – xml, referensmodell, domänmodeller • CDA – Clinical Document Architecture, del av v3, standard för dokument, header och strukturerad eller ostrukturerad data
- 8. STANDARDER I HÄLSO- OCH SJUKVÅRD 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
- 9. HL7 V2 • Bra inom en organisation • Ett hundratal användningsfall stödjs • Skalar ej för interorganisatoriskt utbyte • (För) stor valfrihet • Saknar gemensam modell/terminologiEHR LIS RIS eRx
- 11. 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
- 12. EXEMPEL CDA 12
- 13. STANDARDISERINGENS DILEMMA • En standard kan bara vara två av tre: I (rätt) tid UttömmandeKorrekt
- 14. 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
- 15. 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> 15
- 16. STÖDJER FLERA ARKITEKTORIELLA STILAR • REST A B C D• Document • Message • Service
- 17. 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
- 18. EXTENSIONS Exempel: Norska mellannamn URL <name> <use value="official" /> <family value=”Fiskars" /> <given value=”Minna" /> <given value=”Prästkulla"> <extension url="http://hl7.org/fhir/Profile/iso- 21090#name-qualifier" > <valueCode value="MID" /> </extension> </given> </name> <name> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.7.3'/> …
- 19. OAUTH • OAuth + OpenID • Autenticera användare • Sätta användar- och patientkontext
- 27. Koder CDA FHIR <code code="409586006” codeSystem="2.16.840.1.113883.6.96” displayName="Complaint"/> <value xsi:type="CD” code="233604007” codeSystem="2.16.840.1.113883.6.96” displayName="Pneumonia"/> <problem> <system value="http://snomed.info/sct” /> <code value="233604007" /> <display value="Pneumonia" /> </problem>
- 28. Web-service ”standarder” 1996 1998 2000 2002 2004 2006 2008 2010 2012 XML 1.0+1.1 XSLT 1.0+2.0 xPath 1.0-2.0 RDF+RDF Schema OWL 1+2 XML Schema 1.0+1.1 SOAP 1.1 WSDL 1.1 SOAP 1.2 WS-* JavaScript (+JSON)
Notas do Editor
- Största hotet mot min profession, fantastiskt!
- Tackla behovet av rätt informaton vid rätt tillfälle genom Intraoperabilitet handlar om att få ordning på det man har i den egna organisationen och ett antal avtalspartner, visionen är certifierad interoperabilitet från leverantörer, appifiering Interoperablitet informatioen skall följa patienten. En medelstor journalsystemsinstallation kan ha upp mot 50 anslutningar mot externa system Läsa, skirva i databaser, FTP, mail till att konsumera och producera diverse SOAP-tjänster Journalsystem är ”sviter” från en levernatör där ny funktionalitet måste beställas eller upphandlas 1980-2000 sker en datorisering av vården 2001 använder hälften av alla läkare ett elektroniskt journalsystem och idag är siffran ca 99% Sedan 2004 pågår arbete med nationell infrastruktur för att få informationen att följa patienten mellan vårdgivare och över systemgränser
- 7:an syftar på den sjunde nivån i OSI-modellen, dvs applikationsnivån, man utvecklar altså standarder för att utbyta information på applikationsnivå V2 är storsäljaren och de facto standard för utbyte mellan avdelningar på sjukhus runt om i världen. V3 var HL7:s försök att ta sig an SOA genom att lite måttfullt ta sig an att en gång för alla definiera alla tjänster och deras möjliga innehåll som behövs för att överföra information inom sjukvården.
- 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
- Intraoperabilitet, intraorganisatoriskt utbyte Inte så mycket utbyte som push-flöden från system till system för en mängd användningsfall.
- 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
- 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
- Text för mänsklig läsbarhet Titel och rubrik
- I tid och korrekt men sakna djup Korrekt och uttömmande vilket år som helst Uttömmande och i tid men på bekostnad av kvaliteén Hur kan vi göra saker snabbare?
- 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
- Här har vi ett exempel på en icke tvingande extension (det framgår av resursens profil) Exemplet här är hur ett norskt mellannamn skulle se ut för en utvecklare som interagerar med t ex en patient-resurs. Alla konsumenter måste förstå vad name är och att det innehåller family och given, men sen kommer ett till given, Prästkulla med en extension som hänvisar till definitionen av ett MID, ett mellannamn. Förstår inte konsumenten denna extension hanteras Prästkulla som ytteliggare ett förnamn, förstår konsumenten betydelsen så kan namnet hanteras separat. En annan intressant sak att notera är hur utvecklarvänligt det är med en URL till specen av denna extension,
- Framtiden, SMART on FHIR
- 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.
- Den som har utvecklat en app behöver bara känna till URL-förledet till en FHIR-server. Alla resurser heter likadant och beter sig likadant. Trots att standarden inte kommer att bli oficiell förän till slutet på året så finns redan hela app-bibliotek att tilgå. Här kan jag till exempel plocka in en tillväxtkurva till min medarbetarportal, eller för mina patienter i deras patientportal
- Slutligen kan man säga att framtiden ser ljus ut för sen semantiska interoperabiliteten men arbetet har precis bara börjat. För sveriges del gället det att hänga med för tåget går och vi har inte råd att missa att vara med.