SmartFraming Et vindue til nationale sundhedssystemer Version 3.0
Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med deres daglige arbejde. Det kan eksempelvis være Elektroniske PatientJournaler (EPJ), Elektroniske OmsorgsJournaler (EOJ) og LægePraksisSystemer (LPS). I det følgende vil disse systemer blive betegnet som klientsystemer. Da mange af disse klientsystemer beskæftiger sig med samme problemområde, er det naturligt at data kan deles mellem disse. Hidtil er denne system-system integration ofte sket via meddelelsesbaseret EDIFACTkommunikation, eksempelvis med MedComs Den gode -EDIFACT meddelelse -standarder. Derudover sker der fra mange af klientsystemerne en indberetning af data til centrale registre. Den meddelelsesbaserede integration har det problem, at data typisk kun er udvekslet mellem to aktører. Der sker således ingen central registrering af oplysningerne, og nye eller ændrede data er ikke umiddelbart tilgængelige for øvrige relevante aktører (andre læger, sygehuse, hjemmepleje m.m.). I de senere år er der dog opstået løsninger, der baserer sig på central registrering af data. Eksempler på dette er f.eks. Receptserveren og Fælles Medicinkort. I dette tilfælde tilgår klientsystemer data via en central server. Denne type af systemer vil i det følgende blive benævnt nationale services. Grænseflader De nationale services stiller typisk flere grænseflader til rådighed: En webbaseret brugergrænseflade, der kan tilgås med en standard internet browser En webservice-snitflade, som klientsystemerne kan benytte til decideret system-system integration. Figur 1 skitserer disse to muligheder: Adgang via browser, hvor den nationale services egen brugergrænseflade præsenteres for brugeren og tilgang til den nationale service via webservicesnitfladen, hvor resultatet præsenteres for brugeren af dennes klientsystem. En eksponering af en national services funktionalitet via en webbaseret brugergrænseflade giver i princippet mulighed for den bredest mulige udbredelse, da det blot forudsætter adgang til en standard internet browser. Ofte vil det dog ikke være en hensigtsmæssig anvendelsesmåde, da det kan give anledning til en besværlig arbejdsgang: Brugeren skal åbne en browser, finde servicens websted, logge på og vil først herefter kunne tilgå den ønskede funktionalitet. Et andet aspekt er, at der ikke er nogen integration mellem Figur 1: Kommunikationen mellem de nationale services og det sundhedsfaglige personale browseren og den normale klientapplikation, hvorfor klientapplikationen ikke umiddelbart har adgang til de data der er behandlet i webapplikationen. Et eksempel kan være registrering af oplysninger i en lægepraksis, hvor registrering ofte sker med to formål for øje: Dels med kliniske formål, dels med henblik
på økonomisk afregning. Antages det nu at et centralt system har eksponeret en webservicebaseret brugergrænseflade til registrering af en borgers medicinering, vil lægen så efterfølgende i sit eget klientsystem skulle generere oplysninger til økonomisk afregning. Endelig kan der være tekniske eller organisatoriske begrænsninger, f.eks. at man har valgt ikke at give brugerne adgang til en internet browser. En væsentlig fordel ved at tilgå den nationale service via den webbaserede brugergrænseflade er den hastighed, hvormed ny funktionalitet kan udrulles. I princippet er ny funktionalitet tilgængelig for brugerne så snart den er implementeret og sat i drift på det centrale system. I praksis kan der være begrænsninger i form af krav til undervisning af brugere m.m. Tilgås den nationale service i stedet som en indlejret del af klientsystemet giver det andre muligheder, men også andre udfordringer: Ved at benytte webservicesnitfladen til integration med den nationale service, kan funktionaliteten indlejres som en del af det normale klientsystem. Dette giver optimal mulighed for at tilrette systemet med henblik på at opnå den mest hensigtsmæssige arbejdsgang. Data vil umiddelbart være til rådighed i klientsystemet, og vil kunne anvendes af andre dele af dette hvis det ønskes. Ligeledes vil login i forhold til den nationale service kunne håndteres af klientsystemet transparent for den enkelte bruger af systemet. Mange forhold taler altså for etablering af system-system integration via webservice-baserede snitflader. Der er imidlertid også væsentlige praktiske udfordringer ved denne model. Det største problem er at udrulningstiden for ny funktionalitet kan blive meget lang. Et typisk udrulningsforløb kan se ud som herunder: 1. Det besluttes at en national service skal tilbyde en ny funktionalitet. 2. Den ny funktionalitet implementeres - og stilles typisk til rådighed både via en webbaseret brugergrænseflade og som webservice(s). 3. Det skal besluttes, at der i et klientsystem skal gøres brug af den nye funktionalitet 4. Klientsystemet skal opgraderes til at integrere mod den nye webservice / den nye version af webservicen. 5. En ny version af klientsystemet skal udrulles til brugerne. 6. Brugerne skal undervises i at benytte den nye funktionalitet. Der benyttes i øjeblikket 15 forskellige EPJ-, 11 LPS- og 4 EOJ-systemer fra et tilsvarende antal leverandører. For hvert af disse klientsystemer skal punkterne 3-5 gennemgås. Det gør det til en langstrakt og ressourcekrævende proces at tilføje ny funktionalitet. Det kan altså både tage meget lang tid men også være meget dyrt, hvis der eksempelvis skal implementeres ny lovgivning. Til sammenligning omfatter udrulning af funktionalitet via en webbaseret brugergrænseflade i princippet kun trin 1, 2 og 6. Der er altså tale om en væsentlig hurtigere udrulningsproces. SmartFraming Som nævnt er der fordele og ulemper ved hver af de to måder, hvorpå de nationale services kan tilgås. Med SmartFraming ønskes fordelene fra hver tilgang samlet i én ny tilgang. Denne nye tilgang til de nationale
services er ikke tænkt som en erstatning for de eksisterende tilgange - det vil altså stadig være muligt at tilgå de nationale services gennem eksempelvis webservices, hvis den helt tætte integration er ønsket. En af de væsentligste fordele ved den internet browser baserede tilgang til de nationale services er, at det er billigt at nå ud til det sundhedsfaglige personale. Ønskes en funktionalitet fra en national service implementeret i et klientsystem, er det en ressourcekrævende opgave, da funktionaliteten skal implementeres i en lang række systemer. Med websiden er funktionaliteten tilgængelig uden yderligere omkostninger. Som tidligere beskrevet, er det ikke altid let at lokke det sundhedsfaglige personale ud af klientsystemets vante omgivelser og over i en internet browser. Desuden kan det være tidskrævende, da der ofte skal arbejdes med certifikater, kodeord og digitale signaturer. I fald browseren var indlejret i klientsystemet, ville det sundhedsfaglige personale være i vante omgivelser og al håndtering af sikkerhed, kunne foregå gennem opsætning i klientsystemet. Ved samtidig at give mulighed for at kommunikere mellem websiden og klientsystemet gennem et passende API, ville en række opgaver kunne løses via websiden og det ville dermed ikke være nødvendigt at implementere funktionaliteten direkte i klientsystemet. Denne løsningsmodel, der ligger mellem den fuldstændig websidebaserende og den klientbaserede, kalder vi for SmartFraming. Formål Hovedformålet med SmartFraming er at kunne tilbyde ny funktionalitet til det sundhedsfaglige personale så hurtigt som muligt efter udvikling af denne. Desuden skal SmartFraming gøre det muligt at begrænse ressourceforbruget ved udviklingen af ny funktionalitet i de nationale services. Endelig skal SmartFraming være med til at give den helt rigtige palet af integrationsmuligheder (webservice, SmartFraming eller en kombination af disse), så den bedst mulige brugeroplevelse opnås. Overblik Idéen i SmartFraming er ganske enkel. Det handler om at kombinere det bedste, fra de forskellige måder hvorpå de nationale services kan tilgås. Ved at indsætte en internet browser i et klientsystem og give mulighed for, at websider der hentes via denne browser, kan kommunikere direkte med klientsystemet, kombineres en række af de fordele, der findes for de to eksisterende tilgange. Eksempel Fordelene illustreres nemmest ved et eksempel. Lad os derfor antage, at SmartFraming er implementeret i et LPS, som allerede kan kommunikere direkte med DDV. Det bliver imidlertid vedtaget, at DDV skal give mulighed for at indberette en ny type vaccinationer og afregningen for dette arbejde skal registreres direkte i det anvendte klientsystem. Med SmartFraming vil funktionaliteten være tilgængelig i det omtalte
LPS samtidig med, at funktionaliteten bliver offentlig tilgængelig. Når en læge herefter ønsker at gøre brug af den nye funktionalitet, finder han DDV's webside frem i LPS'et og indtaster de nødvendige oplysninger. Efterfølgende sker der det, at afregningen for vaccinationen bliver overført til LPS'et - fuldstændig som det ville være sket, i fald indtastningen var sket i LPS'et. Dette kan kun lade sig gøre, da DDV er indsat i klientsystemet via SmartFraming. Var indtastningen foretaget i en standard internet browser, ville afregningen ikke umiddelbart kunne overføres til klientsystemet. Uden SmartFraming ville den nye funktionalitet skulle implementeres i en lang række klientsystemer, før den ville være tilgængelig for det sundhedsfaglige personale landet over. Kommunikation mellem webside og klientsystem Det er umiddelbart simpelt at integrere en internet browser i et klientsystem. Det komplekse er, at få mere ud af det, end blot at det er hurtigere at komme ind på en given hjemmeside. Først i det øjeblik, hvor websiden kan kommunikere direkte med klientsystemet, kan der opnås øget effektivitet og forretningsværdi. Det er netop her SmartFraming har værdi. For internet browser komponenten i SmartFraming indeholder et mindre API, der gør websiden i stand til at sende beskeder til klientsystemet og klientsystemet i stand til at sende beskeder til websiden. API'et er tænkt som værende et letvægts-api, hvor kun basal funktionalitet er understøttet. Så API'et vil ikke skulle understøtte funktionalitet, som kun er relevant i forbindelse med eksempelvis DDV. Det er altså ikke API'ets opgave at stille de samme muligheder til rådighed, som allerede kan nås via eksempelvis webservices hos DDV. Derimod er det API'et opgave at gøre det muligt at give klientsystemet besked om eksempelvis en afregning for et stykke arbejde, der er udført via websiden. Det er funktionalitet, der ikke kun knytter sig til en enkelt national service, men som giver mening for en lang række services. Sikkerhed Sikkerhed er ikke et uvæsentligt aspekt i forbindelse med kommunikation mellem sundhedssystemer og bør altid være tænkt ind fra starten. I forbindelse med SmartFraming vil det være oplagt at autentificere brugerne ved hjælp af single-signon. Det vil sige, at når eksempelvis en læge er logget på klientsystemet med sin digitale signatur, skal han ikke logge på de enkelte nationale services der kører gennem SmartFraming, da signaturen automatisk overføres ved brug af disse services. Det er altså kun én gang der skal logges på systemet. Udover sikkerhed ved login på en national service, er der naturligvis også en række sikkerhedsaspekter forbundet med brugen af det omtalte API mellem SmartFraming og klientsystemet. Der er dog ikke umiddelbart nogen forskel på, om et klientsystem kommunikerer med en national service gennem en webside via SmartFraming eller, som det sker i dag, gennem eksempelvis en webservice. Uddannelse af det sundhedsfaglige personale Et vigtig del af det at tilføje ny funktionalitet til et system, er uddannelse af de brugere, der skal benytte systemet. Når funktionaliteten sker direkte i et klientsystem, er det forholdsvis enkelt at sørge for, at det sundhedsfaglige personale bliver uddannet i at benytte funktionaliteten, før denne sættes i produktion. Tilføjes ny funktionalitet til en webside hos en national service, er det straks sværere at sikre, at det relevante personale er uddannet i at benytte funktionaliteten, før denne sættes i produktion. Så er
funktionaliteten stillet til rådighed gennem SmartFraming, vil den som udgangspunkt være til rådighed hos det sundhedsfaglige personale landet over, så snart den sættes i produktion. Det vil dog være forholdsvis simpelt at sørge for, at funktionalitet kan stilles gradvist til rådighed for det sundhedsfaglige personale, efterhånden som dette bliver nødvendigt og personalet er blevet uddannet i brugen. Med SmartFraming er der nemlig ikke mulighed for, at personalet selv kan indtaste en URL (en adresse på en webside) i internet browseren. Det er derimod op til den ansvarlige for det enkelte klientsystem at konfigurere systemet således, at personalet har adgang til de rette dele af de nødvendige nationale services. Pilotprojekt Der har været afholdt et pilotprojekt vedr. SmartFraming i efteråret 2009. Der blev etableret en prototype komponent til SmartFraming i.net, og de primære punkter med usikkerhed og risici blev afprøvet. Prototypen byggede bro mellem A-Datas Læge Praksis System, WinPLC, som værtsapplikation og Vaccinationsregisteret som gæsteapplikation. Aktører I pilotprojektet var følgende aktører involveret: SSI, A-Data og Trifork. Resultat Pilotprojektet nåede en række resultater. Trifork udviklede en prototype SmartFraming-komponent i.net Vaccinationsregisteret blev gjort i stand til at være SmartFraming gæsteapplikation Trifork udviklede en simpel værtsapplikation, der kunne demonstrere principperne i SmartFraming prototypen A-Data integrerede prototype SmartFraming-komponenten i deres LPS, WinPLC Der blev udført teknisk test Det blev påvist, at det rent teknisk er muligt at kommunikere begge veje mellem en klient og en indlejret browserapplikation via integration med JavaScript WinPLC med SmartFraming af Vaccinationsregisteret blev demonstreret for de involverede interessenter Det blev med andre ord afdækket at det faktisk er muligt at få SmartFraming til at fungere i praksis. Hvad nu? Der foregår nu et arbejde med at udvikle og dokumentere den endelige SmartFraming løsning, hvilket i hvert fald involverer følgende punkter. Fastlæggelse af det endelige API og inspireret af tankerne fra arbejdet med SignOn Library vil dette API følge principperne fra HL7-CCOW, som er en standard for kontekst-deling og mellem applikationer. Implementation af SmartFraming komponenter til.net og Java.
Implementation af Vaccinationsregisteret som en gæsteapplikation i det endelige SmartFraming koncept. Dokumentation af konceptet og API erne så andre kan levere værtsapplikationer og gæsteapplikationer der kan integreres med SmartFraming komponenterne og dele kontekst gennem API erne. Nyt pilot-forløb med den endelige løsning. Udbrede kendskabet til løsningen, så det forhåbentlig kan vinde accept og udbredelse.