Webservices i sundhedssektoren Lasse Nørgaard, Enhed for klinisk kvalitet lasse.noergaard@regionh.dk
Agenda Domænet Det forretningsmæssige rationale Integrationskonceptet XML Anvendelse af SAS Webservice Datakvalitet Konklusion
Enhed for klinisk kvalitet i Region H (EKK) Decentral enhed under Koncern Plan og Udvikling 9 årsværk + SAS konsulenter Rådgivning, implementering og drift af regionale og landsdækkende databaser til monitorering af behandlingskvaliteten i sundhedsvæsenet 20 landsdækkende kliniske kvalitetsdatabaser Fx diabetes, tyk- og endetarmskræft, screening af gravide, behandling af hjertsygdomme Datakilder Klinisk MåleSystem (KMS) CPR register, Landspatientregisteret, Cancerregisteret etc. Webservices Rapporter og analysedata i SAS Analyseportal
Hvad er en klinisk kvalitetsdatabase? En klinisk kvalitetsdatabase er et register, der indeholder udvalgte kvantificerbare indikatorer, der med udgangspunkt i det enkelte patientforløb kan belyse dele af eller den samlede kvalitet af sundhedsvæsenets ydelser for en afgrænset gruppe af patienter Sundhedsstyrelsen
Danske Regioner: Finansiering og basiskrav Udvikling og drift af databaserne finansieres af Danske Regioner 35 landsdækkende kliniske kvalitetsdatabaser Informatiske mål at data kan udveksles mellem systemerne, med henblik på datagenbrug Middel Fælles integrationsprincipper og standarder for udveksling af data (interoperabilitet) Service Orienteret Arkitektur (SOA) - Systemer opbygges modulært - Veldefinerede systemgrænseflader - Services/tjenester Tilbyde både brugergrænseflade og systemgrænseflade til dataregistrering
Agenda Domænet Det forretningsmæssige rationale Integrationskonceptet XML Anvendelse af SAS Webservice Datakvalitet Konklusion
San Francisco s sporvogne anno 1890 og Sundheds-IT anno 2010 Ligheder?
De 8 originale San Francisco sporvognsselskaber i 1890 Clay Street Hill Railroad En linje, 3½' sporvidde, bottom grip kabeltræk. I drift fra 1873 Sutter Street Railroad To linjer, 5' sporvidde, side grip kabeltræk. I drift fra 1877 California Street Cable Railroad Tre linjer, 3½' sporvidde, side grip kabeltræk på California St. linje, bottom grip kabeltræk på de to øvrige. Service from 1878 Presidio & Ferries Railroad En linje, 5' sporvidde, bottom grip kabeltræk. I drift fra 1882 Market Street Cable Railway Fem linjer, 4 og 8½ sporvidde, side grip kabeltræk. I drift fra 1883 Ferries & Cliff House Railway Fire linjer, 3½' sporvidde, bottom grip kabeltræk. I drift fra 1888 Omnibus Railroad & Cable Company Fem linjer, 3½ sporvidde, bottom grip kabeltræk. I drift fra 1889 Geary Street, Park & Ocean Railroad Geary Street, Park & Ocean Railroad fra 1880 (manglende oplysninger om sporvidde og kabeltræk) Kilde: http://www.cablecarmuseum.com
Karakteristika ved San Francisco s sporvognsselskaber Specifikationer Skræddersyede sporvogne Bevidst valg af inkompatible sporvidder og kabeltræk Formål At beskytte operatøren fra fjendtlig overtagelse af konkurrenterne Problemer Begrænset konkurrence Højere priser Svært at gøre rentabelt Dyrt/svært at integrere sporvognslinjerne!
Karakteristika ved Sundheds-IT anno 2010 Specifikationer Proprioritære IT-systemer er reglen Uintenderet valg af inkompatible IT-systemer Formål Intet Problemer Begrænset konkurrence Højere priser Heterogene datamodeller Data-integration vanskelig
Dataintegration Behov for teknologi- og platformsuafhængige grænseflader!
Hvorfor etablere integration mellem kliniske kvalitetsdatabaser og lokale/regionale Sundheds-IT systemer? GENBRUG, GENBRUG, GENBRUG Data til kvalitetsmonitoreringen registreres i vid udstrækning i forvejen i andre Sundheds-IT systemer Dobbeltindtastning er demotiverende Brugerne kan fortsætte med at arbejde med de vante ITsystemer Løbende validering af kildedata i forhold til de centrale valideringskriterier i de kliniske kvalitetsdatabaser
Agenda Domænet Det forretningsmæssige rationale Integrationskonceptet XML Anvendelse af SAS Webservice Datakvalitet Konklusion
Principper Fra proprietære formater til fælles formater Fra fokus på teknologi til øget forretningsfokus Udnyttelse af eksisterende IT-platforme Uafhængig af underliggende teknologisk implementering hos serviceudbyder og bruger Fra tæt koblede løsninger til løst koblede forretningsmuligheder Fra manuel til automatisk datafangst
OIO som referenceramme Offentlig Information Online OIO.dk blev etableret i 2001 som en fællesoffentlig portal med redaktører fra Forskningsministeriet, Statens Information, KL og Amtsrådsforeningen I dag forankret i IT- og telestyrelsen Fælles åbne standarder for udveksling af information OIOXML projektet OIO Arkitekturguide Koordinering i XML komiteer
OIOXML og webservices Navngivnings- og designregler (NDR, v. 3.1 2009) Krav om genbrug at typer, elementer og værdier på tværs af XML skemaer Fælles navngivningsmetodologi Fælles designprincipper Restriktioner i design af XML skemaer Namespaces ejerskab til datatyper og elementer Den gode webservice www-links digitaliser.dk Itst.dk/arkitektur-og-standarder medcom.dk http://rep.oio.dk
Eksempler på OIO XML standarder Sundhedssektoren (www.medcom.dk) Den gode XML recept Den gode XML Epikrise Den gode XML henvisning Det gode XML laboratoriesvar De gode XML kvitteringer Øvrige CPR opslag OIOfakturaer (virk.dk)
Samlet koncept for systemgrænseflade Forbedret udveksling af data gennem fælles regler for strukturering, genbrug af variable, fælles byggeklodser (OIO) XML som fælles udvekslingsformat ( fil-formatet ) Webservice til overførsler af XML-dokumenterne Sikker overførsel inden for fælles VPN netværk i sundhedssektoren ( Sundhedsdatanettet)
Agenda Domænet Det forretningsmæssige rationale Integrationskonceptet XML Anvendelse af SAS Webservice Datakvalitet Konklusion
XML is like violence. If it doesn't solve your problem, you're not using enough of it.
Diabetes XML-dokument
XML (Extensible Markup Language) handler om data Lingua franca for dataudveksling Løsning på HTML s ( præsentationssprog ) begrænsninger separation af præsentation og data Repræsentation af data-strukturen XML handler om hvad og ikke hvordan
XML som udvekslingsformat Bredt accepteret format for udveksling af data og dets korresponderende semantik Universelt format til at repræsentere og udveksle strukturerede data System, leverandør- og platformsuafhængigt Struktureret dokumentformat Både maskin- og menneskelæsbart Opmærkningssprog Hierarkisk opbygning Metadata (betydning af data) indlejret i XML
XML-skema XML-skemaet beskriver XML-dokumentets struktur (syntaks) Elementer (typer, antal, over-under elementer) Validering (feltvalideringer) Men krydsvalideringer (implementeret som SAS valideringer i Webservicen) XML-skemaet kan valideres af standardværktøjer til XML-parsing (program som analyserer XMLdokumentet syntaks og indhold)
XML skemaer i EKK s SAS Webservices XML modellering af sygdomsspecifikke datasæt Målsætning om OIOXML compliance Ikke målsætning om egentlig ophøjelse af XML skemaer til OIO standarder Langvarig proces Færre frihedsgrader Dynamisk datagrundlag
Hierarkisk modellering af datasættet i XML
Krav om genbrug af elementer og typer Et OIOXML-skema skal genbruge eksisterende elementer eller typer fra Kerneklassen eller Domæneklassen Et OIOXML-skema skal genbruge de indbyggede simple typer i XML skema anbefalingen frem for at definere egne typer til at repræsentere egne typer
www.w3schools.com
Valg eller fravalg af kvitteringer fra Webservice
Håndtering af ændringer i indberetninger til WS
Navngivning af typer Navnet på en simpel eller kompleks type skal afsluttes med suffiks Type Navnet skal anvende termen repræsentation i typenavnet for en for en simpel type Navnet må ikke anvende termen repræsentation i typenavnet for en kompleks type Navngivning af simple og komplekse typer med UpperCamelCase
Time Tid Tidspunktet indenfor en ikke specificeret dag. Baseret på ISO 8601:1988. Eksempler på repræsentationstermer Engelsk Dansk Beskrivelse Code Kode En karakterstreng der kan bruges til at repræsentere eller erstatte en definitiv værdi eller tekst, f.eks. som forkortelse og/eller for at opnå sproguafhængighed. Koder er normalt vedligeholdt i en kodeliste per type, f.eks. farve. Date Dato En dato indenfor et bestemt kalenderår, baseret på ISO 8601. DateTime (*) DatoTid Et bestemt tidspunkt. Identifier Identifikator En karakterstreng der, indenfor en identifikationsramme, bruges til at identificere og unikt udpege én instans af et objekt blandt alle objekter indenfor samme ramme. Name Navn Et ord eller en frase som indeholder den præcise betegnelse for en person, et sted, ting eller koncept.
Navngivning af elementer Et OIO-XML skema skal navngive dets element identisk med elementets type (uden typens Type suffiks), hvis elementerklæring og typedefinition forekommer sammen i skemaet Et OIOXML-skema skal navngive dets element med UpperCamelCase
Agenda Domænet Det forretningsmæssige rationale Integrationskonceptet XML Anvendelse af SAS Webservice Datakvalitet Konklusion
Udgangspunktet: Den gode Webservice Fælles webserviceprofil for sundhedssektoren Muliggør udveksling af data på tværs af IT-produkter og platforme i sundhedssektoren (Sikrer ikke i sig selv, at produkter og systemer er interoperationelle) Retningslinjer for sikkerhedsniveauer Uafhængig af den underliggende transportprotokol Kan anvendes på det åbne net med SSL-kryptering Kan anvendes med VPN kryptering på det lukkede sundhedsdatanet
To-trins kommunikationsmodel
SOAP (Simple Object Access Protocol) Kommunikationsprotokol til kommunikation i et distribueret miljø Kuverten til indpakning af XML dokumenterne De facto standard for webservicekuvert Optimeret i forhold til læsbarhed HTTP = Firewall venlig transportprotokol Envelope Header element som indeholder forsendelsesoplysninger (og sikkerhedsoplysninger) Body element indeholder de faktiske XML data som indberettes (selve brevet)
WSDL (Web Service Description Language) WSDL beskriver både hvad og hvordan XML baseret sprog til beskrivelse til interfacet til Webservicen Målet er at muliggøre, at to applikationer kan kommunikere automatisk uden kendskab til, hvordan de hver især er implementeret WSDL beskriver Hvilke beskeder den kan genkende Hvordan webservicen benyttes (SOAP via HTTP) Hvordan man kontakter servicen Muliggør validering hos klientsystemet inden indberetning!!
Opbygning af WSDL (Henrik Hvid Jensen, 2006)
SAS Webservice til Analyseportalen Java baseret En operation: report Input: En Emessage indeholdende en DiabetesReport Output: En Emessage (NegativeReciept/PositiveReceipt) Ved program fejl: En SOAP-fault To valideringer: Kontekst uafhængig XML validering (Java) Kontekst-afhængig validering (SAS)
Testservice og rigtig service To webservices Server: http://<server>:<port> /ClinicalReporting/DiabetesService.wsdl /ClinicalReporting/DiabetesTestService.wsdl Tre servere saswsprod.hs.medcom:9080 (produktion) Sasws01.hs.medcom:9080 (test) Clinicalreporting.analyseportal.dk:9444 (udvikling https adresse uden for sundhedsdatanettet)
Kommandolinje-klient >java jar wsclient.jar Server - http://saswsprod.hs.medocm:9080/clinicalreporting/ SOAPaction - http://rep.oio.dk/sundcom.dk/medcom.dk/xml/schemas/2007/02/ 01/DiabetesReport Input - Indberetning.xml Output - Svar.xml
Positiv response fra webservicen
Negativ response fra webservice
Webservice Logviewer
Udsnit fra log afviste indberetninger envelopeid letterid refusecode refusetext refused 171 216 syntaksfejl Path: /Emessage/DiabetesReport/Letter/Authorisation/Time cvc-type.3.1.3: The value '40:32' of element 'Time' is not valid.] yes 171 216 syntaksfejl Path: /Emessage/DiabetesReport/Patient/CivilRegistrationNumber cvcpattern-valid: Value '251248-4916' is not facet-valid with respect to pattern '((((0[1-9] 1[0-9] 2[0-9] 3[0-1])(01 03 05 07 08 10 12)) ((0[1-9] 1[0-9] 2[0-9] 30)(04 06 09 11)) ((0[1-9] 1[0-9] 2[0-9])(02)))[0-9]{6}) 0000000000' for type 'CivilRegistrationNumberType'.] yes 171 216 ikke_specificeret Nytbrev brev med EAN identifier: 5790000123414, Sender identifier: 5790000123414, Letter identifier: 216 findes allerede i databasen yes
Agenda Domænet Det forretningsmæssige rationale Integrationskonceptet XML Anvendelse af SAS Webservice Datakvalitet Konklusion
Datakvalitet!
Forudsætninger for god kvalitet af data ved dataintegration Dataleverandørerne skal kunne levere: 1. De rigtige data 2. I den rigtige kontekst med tilstrækkelig nøjagtighed 3. I det rigtige format (in casu XML/Webservice) 4. Til rette tid Serviceudbyderen skal kunne levere: 1. En integrationsløsning, som sikrer at indberettede data efterlever den kliniske kvalitetsdatabases forretningsregler
1. De rigtige data Forudsætninger Den nødvendige data kan registreres i dataleverandørernes IT-systemer De nødvendige data bliver registreret! (Få ændringer af den landsdækkende kliniske kvalitetsdatabases datasæt) Udfordringer Forskellige datamodeller Forskellige forretningsregler Forskellige brugergrænseflader Varierende registreringspraksis
De rigtige data alle de data vi skal bruge? Kildesystem Targetsystem 1:½ mapning Manglende dataelementer Fx systematiske huller i indberetning til diabetesdatabase Manglende registrering af obligatoriske elementer Forskelle i brugergrænseflader og valideringsregler Spøgelsespatienter i kildesystemerne Databasedækningsgrad > 100 % Kun delvis retro-fitting af kildesystemer ved etablering af integration!
2. Data i den rigtige kontekst med tilstrækkelig nøjagtighed Forudsætninger Semantisk integration ens betydning af data = tæt kobling af det semantiske niveau Nødvendige valideringer implementeret i dataleverandørernes brugergrænseflader Ensartet registreringspraksis Udfordringer Datakvalitet Fitness to the purpose of use - Forskellige krav til kvaliteten af transaktionssystemernes data og de kliniske kvalitetsdatabaser Forskellige registreringsbehov Forskellig granulering af svarmuligheder
Kender vi betydningen af data, og kan vi stole på data? Forskellige registreringsformål EPJ hos praktiserende læger Diabetesjournal på sygehus ambulatorium Forskelligt granuleringsniveau fx en generel diabetesdiagnose versus opdeling i type 1, type 2. Forskellige datadefinitioner
Anders And-værdier Dilemma ved kombination af utilstrækkelige feltvalideringer og automatiske indberetninger Patienter med blodtryk på 0! Patienter med diagnosedato < fødselsdato! Patienter med højde på 0 eller vægt på 999!
3 og 4. Data i rette format til rette tid Forudsætning Dataleverandørerne udvikler program til udtræk og XML konvertering af kildedata Dataleverandørerne udvikler webserviceklient til indberetning af XML data til webservicen Dataleverandørerne overvåger webserviceindberetningerne og håndterer af fejl og mangler ved indberetningerne Daglige indberetninger Udfordringer Begrænsede økonomiske, humane og intellektuelle ressourcer
Tilstrækkelig anvendelse af XML s muligheder i diabetes Webservicen? NEJ Oprindelig fuld udnyttelse af felt- og kryds-valideringer i Webservice, dvs. - Max og min værdier for undersøgelsesresultater - SAS krydsvalideringer (check for overholdelse af valideringer på tværs af elementerne) - Størstedelen af elementerne var obligatoriske Valideringsregler fjernet i 2008 på foranledning af de klinisk ansvarlige for diabetesdatabasen - Demotiverende for de indberettende enheder med mange negative kvitteringer fra webservicen - Anvendelse af særegne default-værdier i obligatoriske dataelementer. Resultatet af ændringerne har været muligheder for indberetninger af meningsløse værdier
Ny beslutning (maj 2010) truffet omkring diabetes webservicen Genindførsel af alle tidligere valideringsregler i webservicen og lidt til
Barrierer
Silo-tænkning som barriere for anvendelse af webservices Hvem skal nu betale? Løn til læger, sygeplejersker etc. til indtastning af data i brugergrænseflade til kliniske kvalitetsdatabaser betales af en kasse! IT-udvikling og drift betales (ofte) af en anden kasse! Not Invented Here (NIH princippet)
Agenda Domænet Det forretningsmæssige rationale Integrationskonceptet XML Anvendelse af SAS Webservice Datakvalitet Konklusion
Konklusion Hold kompleksiteten af target-datasæt på et minimum! Brug nu nok XML! Gylden business case i et samfunds- og sygehusperspektiv Genbrug af data 2.000 diabetespatienter ( standard ambulatorium) 15 minutters besparelse pr. diabetes indberetning = 500 timers besparelse ved webserviceindberetninger 0,3 årsværk 200.000 kr. årligt 200.000 diabetikere 20 millioner kr. i årlig besparelse Udviklings- og driftsudgifter 50.000-100.000 kr. til lokal/regional udvikling af webserviceklienter +? Kr. til tilpasning af kildesystemerne? Kr. til drift- og overvågning af webserviceklienterne
Spræng rammerne for silotænkningen og sæt yderligere gang i webservice-integrationer i sundhedssektoren!