Spørgsmål fra Djævlens Advokat

1. Relation til S&D rapporten om EOJ
   Q: I Strand & Donslund rapporten "Medicineringsprojektet - Den kommunale hjemmesygeplejes adgang til den Personlige Elektroniske Medicinprofil", anbefales i utvetydige vendinger, at der skal etableres en "service bus" medieret gennem Sundhed.dk. Hvad er argumenterne for, at vi i SOSI projektet ikke gør som de anbefaler?
   A: Det er rigtigt, at rapportens overordnede konklusion er at services skal udstilles gennem Sundhed.dk og vidererestilles til de underliggende systemer. Imidlertid opblødes denne konklusion i rapportens kapitel 6, "Perspektivering", hvor der fremlægges en plan for at gøre Sundhed.dk til integrationsplatform. Første skridt i denne plan er at genbruge Sundhed.dks sikkerhedslogik (OCES validering, autentifikation mod SSTs Autorisationsregister mm.) til at etablere et "portvagtmønster", hvilket netop er et af SOSI projektets præmisser. At bruge Sundhed.dk som central proxy for samtlige service-kald vil medføre en merudgift på hardware hos Sundhed.dk over tid. Samtidig introduceres et dramatisk single-point-of-failure for alle services i SOA arkitekturen. Det bemærkes dog, at der kan være god fornuft i at benytte mønsteret i forbindelse med skærbilledebaseret integration, dvs. i scenariet hvor det er et skærmbillede der hentes fra en underliggende service. Medicinprofilen integrerer allerede på denne måde med Sundhed.dk og der er derfor en erfaringsbase at tappe her. Emnet bør diskuteres.
2. ACUREs løsningsforslag
   Q: ACURE har udfærdiget et dokument vedlagt i leverancekontrakten til EPM til KA (bilag O - Opslag fra EPJ systemer i Medicinprofilen via browser.pdf), der anbefaler en yderst simpel løsning baseret på tickets. Hvorfor laver vi nu en meget mere kompleks løsning?
   A: Spørgsmålet kan omformuleres til flg. to spørgsmål: "Hvorfor benytte certifikater i integrationen?" og "Hvorfor involvere Sundhed.dk i integrationen?". Se svar på disse spørgsmål nedenfor.
3. Anvendelse af certifikater
   Q: Hvorfor er der behov for at benytte certifikater i løsningen. Vi har jo levet uden certifikater i mange år i sundhedssektoren.
   A: Medicindata er følsomme data. Et angreb på udveksling af medicindata kan i yderste konsekvens have fatale følger for patienten. Der er derfor (som bare ét aspekt) behov for mere sikkerhed omkring brugerens påståede identitet (minimum niveau 3 jf. VTU retningslinier for autentitetssikring, der er baseret på NIST - Electronic Authentication Guideline), og et brugernavn/password derfor ikke altid tilstrækkeligt. Jf. NIST og VTU arbejdet skal niveauet af autenticitetssikring besluttes på baggrund af en analyse af, hvor store konsekvenser der vil være ved et autenticitetsbrud. Designet i SOSI gør det muligt at autenticitetsikre på flere niveauer (f.eks. med brugernavn/password eller digitale certifikater).
   
   Der er endvidere etableret flere pilotprojekter, der pt. kører i regi af Amterne og H:S vedr. brugen af certifikater til autentifikation (se evt. ARF rapporten her).
4. Sundhed.dk
   Q: Hvorfor overhovedet involvere Sunhed.dk i integrationsløsningen? Hvorfor ikke bare integrere EPJ systemet direkte med PEM uden at involvere Sundhed.dk?
   A: Der er flere grunde til at Sundhed.dk bør indgå i integrationsløsningen.
   1. Da løsningen blandt andet baserer sig på certifikater, er det oplagt at genbruge sikkerhedsløsningerne fra Sundhed.dk. Alternativet er, at PEM også skal etablere en certifikatløsning, hvilket der næppe er en god businesscase for. I det store perspektiv ville det betyde, at alle nye serviceudbydere skal etablere deres egen sikkerheds- og brugerløsning.
   2. Forespørgsler/Indberetninger i/til PEM må kun foretages af passende autoriserede brugere. Frem for at PEM skal indgå "tro og love" aftale med hver enkelt EPJ system om, at brugerautorisationen håndteres korrekt af EPJ systemet, virker det væsentligt mere bæredygtigt (og sikkert!) at benytte Sundhed.dk's centrale brugerkatalog og de tilknyttede centrale autorisationer.
   3. Sundhed.dk er fra national hold udpeget som det den primære integrationspunkt i sundhedssektoren. Dette kan blandt andet læses af bemærkningerne til lovforslaget om etableringen af PEM:
      "Lægerne og sygehusene henter medicinprofilen gennem den offentlige sundhedsportal. ..."
5. Shibboleth
   Q: Hvorfor lave vores egen løsning, når nu andre (f.eks. statsbiblioteket) baserer deres løsning på Shibboleth?
   A: Det er ikke umuligt, at vi kan basere implementationen på Shibboleth . Opgaven må være at afdække kravene først og derpå addressere mulige løsningsmodeller. I dag understøtter Shibboleth ikke SAML 2.0, som Videnskabsministeriet anbefaler, men dette er under udvikling. Tidsrammen er dog uklar og det kan være, at det er mere hensigtsmæssigt at basere integrationen på et kommercielt produkt der allerede understøtter SAML 2.0.
6. Skærmbilledebaseret integration vs. programmatisk
   Q: Hvorfor kan man ikke bare indlejre PEMs HTML grænseflader i medicinmodulerne?
   A: Ribe- og Københavns Amters Medicinmoduler er såkaldte "rige klienter" i den forstand, at de ikke er baseret på en webbrowser, men derimod er selvstændige applikationer (Java, Swing). Ved anvendelse af skærmbilledebaseret integration vil medicinmodulerne skulle indeholde en browserkomponent, der så skulle kaldes med de rigtige parametre for at koble de to systemer. Dette giver dels en dårlig brugeroplevelse, dels umuliggør det samstilling af data med lokale medicinoplysninger fra hospitalet. En programmatisk integration vil løse disse problemer, da den tillader at grænsefladen er så "rig" som i resten af medicinmodulet og at data kan samstilles så en bedre brugeroplevelse kan opnås.
   OBS: Det bemærkes, at der i dag ikke er hjemmel i loven om Medicinprofilen til at samkøre data (i modsætning til samstilling og/eller "anvendelse", f.eks. i forbindelse med etablering af nye ordinationer.
   Se lovforslaget med bemærkninger her og bekendtgørelsen her (§13 vedr. sammenstilling).
   
   Umiddelbart må målet med §13 være:
   
   1. at undgå redundans (herunder "korrosion" af data).
      Da udtræk fra PEM formodentligt vil blive anvendt som grundlag for nye ordinationer, er der i princippet kun tale om anvendelse af data som udgangspunkt for en arbejdsgang. Der er derfor reelt ikke tale om "samkøring".
   2. at sikre at PEMs medicindata bliver behandlet med behørig diskretion og varsomhed (som reguleres af lovgivningen omkring PEM).
      Dette bør ikke være et problem, dels fordi der reelt ikke er tale om sammenstilling, dels fordi der er de samme diskretions- og varsomhedskrav til medicinmoduler.