SOSI Executive Summary

Det Danske Sundhedsvæsen har med tjenester som Sundhedsportalen og Medicinprofilen (PEM) over de seneste år for alvor taget hul på at eksponere klinisk funktionalitet via Internettet. I første fase har fokus været på webgrænseflader, og tjenesterne har fortrinsvist henvendt sig til borgere og sundhedsfagligt personale i primærsektoren.

Parallelt med denne udvikling er amterne (regionerne) i færd med opbygningen af en digital klinisk arbejdsplads i form af EPJ-projekterne til sekundærsektoren. Disse systemer er typisk baseret på andre teknologier end webgrænseflader - teknologier der bedre understøtter de komplicerede arbejdsgange i sygehusenes kliniske hverdag. Systemerne udvikles og drives decentralt af amterne og fokus er her først og fremmest at få systemerne implementeret på egne hospitaler.

I takt med at EPJ-systemerne kommer i drift opstår der, for at kunne realisere målet om "valide, sammenhængende og tilgængelige patientinformationer" i Sundhedsstyrelsens nationale IT-strategi for 2003-2007, dels et behov for at udveksle patientoplysninger på tværs af sekundærsektoren og dels med primærsektoren. En sådan dataudveksling baseres på system-til-system kommunikation og kræver, at EPJ-systemerne samt de centrale tjenester udstiller funktionalitet til at afsende og modtage patientoplysninger.

Dataudveksling kan imidlertid realiseres på et utal af måder, og givet den decentrale udvikling af EPJ-systemerne er der således et stort behov for standardisering af alle aspekterne i denne kommunikation. En løsning skal forholde sig til internationale samt nationale standarder udstukket af Videnskabsministeriet, til lovningskrav i form af Persondataloven og Patientretsstillingsloven og lov om digital signatur, til Sundhedsstyrelsens nationale IT-strategi, samt naturligvis genbruge eksisterende infrastruktur herunder eksisterende online tjenester, SundhedsDataNettet, etc.

Formålet med projektet "Service Orienteret System Integration" (SOSI) er at levere et forslag til, hvordan en sådan system-til-system integration i det samlede danske Sundhedsvæsen kan realiseres. SOSI bygger på fuld åbenhed, hvor alle kan se det fremskridende arbejde, hvor alle relevante parter enten høres, eller inviteres med i projektet, og alle har mulighed for at give deres besyv med.

SOSI Visionen

Den overordnede forretningsmæssige vision, som SOSI ønsker at bidrage til, er det ubegrænsede, kvalitetsforøgende og sikre informations-flow mellem relevante aktører i sundhedsvæsenet. Ubegrænset skal i denne sammenhæng læses som, at løsningen skal kunne omfatte al system-til-system kommunikation i sundhedsvæsenet, hvad enten der er tale om systemer til praktiserende læger, sygehussystemer, omsorgssystemer eller omgivende støttesystemer. SOSI bliver derfor i bund og grund drevet af et ønske om, at være med til at forenkle og forbedre arbejdsgangene i behandlings- og plejeforløb for patienterne!

Sekundært har SOSI til formål at minimere den investering, der skal til, for at eksponere nye eller eksisterende tjenester i sundhedssektoren, eller for at benytte disse tjenester. Hvis det bliver nemt, billigt og hurtigt, at etablere nye tjenester i sundhedssektoren, vil det også gavne patienterne, der får bedre kvalitet tidligere.

Teknisk set bygger SOSI på en vision om at samle al system-kommunikation mellem sundhedsvæsenets parter i en føderation med veldefinerede rammer og med faste spilleregler. Dette realiseres ved at etablere den nødvendige infrastruktur, fastsætte krav til parterne i infrastrukturen, og definere de protokoller og udvekslingsformater der er tilladte imellem føderationens parter.

Præciseringen af infrastruktur og protokoller har blandt andet til formål at sikre overholdelsen af relevante love, bekendtgørelser, cirkulærer mv., at sikre at tjenester bliver kompatible, at brugeren kun skal "logge på" én gang, samt at det bliver nemt at levere nye tjenester til SOSI komplekset.

Helt konkret har SOSI følgende tekniske mål:

1. Det er målet at skabe grundlag for en *føderation af nationale web services",
2. ... hvor der opretholdes "Single-Sign-On" (SSO) og
3. ... hvor det er muligt for serviceudbydere at overbevise sig om brugeres identitet og autenticitet
4. ... samt for alle parter i føderationen at kunne opretholde uafviselighed af beskeder, svar og andre vigtige data
5. ... ved brug af åbne internationale og nationale standarder (konkret OCES, SAML og OIO)
6. ... på en effektiv måde
7. ... og uden at introducere unødige "single points of failure"
8. ... så løsningen kan skalere til at kunne håndtere en stor del af (helst al) system-til-system integration mellem systemer i sundhedssektoren
9. ... uden at tvinge parterne til specifikke platforms-, leverandør- eller værktøjsvalg.

SOSI føderationen består af et antal parter koblet sammen via et sikkert netværk. Nedenstående figur illustrerer de roller, der vil være i en fuldbyrdet SOSI føderation:

Elementer i løsningen

Designet af SOSI er inspireret af fysiske ID-kort, der f.eks. anvendes af medarbejdere i en virksomhed til identifikation: når kortet bæres kan alle se hvem personen er og at denne har ret til at opholde sig i firmaet. ID-kort analogien bruges dels som bevis på at den pågældende part er "logget ind" i føderationen og dels til at autorisere adgangen til tjenester vha. de ekstra oplysninger kortet fik påtrykt under udstedelsesprocessen.

I en SOSI føderation indgår der som minimum følgende parter:

• Serviceudbyder. Et system, der udstiller en web service (tjeneste). Tjenesten kan benyttes af en Serviceaftager for så vidt denne medsender bevis for identitet og kan blive passende autoriseret. Der er typisk mange serviceudbydere i en føderation.
• Serviceaftager. Et system, der benytter en web service med henblik på at få udført et stykke arbejde, f.eks. at hente data eller opdatere et datalager. Der er typisk mange serviceaftagere i en føderation.
• Identity Provider (IdP). Et system, der kan verificere autenticiteten af en brugers akkreditiver, og dermed vedkommendes identitet. Der er typisk kun én eller meget få IdP'er i en føderation.
• Certificate Authority (CA). Et system, der kan udstede certifikater, udlevere oplysninger om personen bag og udlevere certifikater efter ønske. Der er typisk kun én eller meget få CA'er i en føderation.
• Autorisationsservice. Et system, der kan udlevere oplysninger om en bruger, f.eks. dennes organisatoriske tilhørsforhold, offentlige autorisationskode, etc. Bruges til at hente oplysninger der skal påtrykkes et ID-kort. Der kan være flere autorisationsservices i en føderation, men der vil ofte kun være få.

Nu da vi har de centrale aktører på plads, kan vi se lidt på, hvordan udstedelse af ID-kort foregår. I dette tilfælde udstedes der et ID-kort på baggrund af et OCES medarbejdercertifikat:

1. Før en serviceaftager kan begynde at anvende SOSI føderationens tjenester, skal serviceaftageren forbi "portvagten" og have udstedt et ID-kort. Det sker ved at serviceaftager laver en digital signatur med sin private nøgle og sender signaturen til Identity Provideren (IdP).
2. Hvis IdP'en ikke kender det certifikat der skal bruges for at validere signaturen, hentes certifikatet først fra Certifikat Autoriteten (CA). Samtidig kan brugerens CPR-nummer hentes fra CA ved at bruge certifikatets ID som nøgle.
3. Når brugeren og dennes CPR-nummer er kendt, kan yderligere oplysninger som f.eks. autorisationskode fra Sundhedsstyrelsen, organisatorisk tilhørsforhold etc. hentes eller verificeres hos en eller flere Autorisationsservices.
4. De rekvirerede/verificerede oplysninger påtrykkes et digitalt ID-kort, som underskrives af IdP'en og returneres til serviceaftageren.
5. Serviceaftageren er nu klar til at benytte tjenester i SOSI føderationen. Dette gøres ved at serviceaftageren danner en web service forespørgsel og putter den i en "konvolut" sammen med ID-kortet. Alt sammen sendes til serviceudbyderen. Kuverten kan, hvis serviceudbyderen kræver det, krydres med en digital signatur af indholdet.
6. ID-kortet er lavet, så ægthed og gyldighed kan verificeres decentralt, dvs. hos den enkelte serviceudbyder uden at spørge andre parter i føderationen. Serviceudbyderen verificerer nu kortet og autoriserer brugeren til den ønskede funktionalitet på baggrund af kortets oplysninger.
7. Når funktionaliteten er udført, pakkes svaret i en web service svarkonvolut, som returneres til serviceaftageren.

Formelt set er ID-kort mekanismen en overdragelse af tillid, hvor IdP'en overtager ansvaret for og står inde for en brugeres autenticitet. Da tillidsforholdet mellem serviceudbydere og IdP'en er stort, kan alle serviceudbydere i SOSI føderationen, efterfølgende kontrollere den oprindelige tillidsoverdragelse, og dermed brugerens autenticitet, ved at sikre sig at et ID-kort er udstedt af den pågældende IdP. Konkret betyder det, at serviceudbydere udelukkende behøver at kende ét offentligt certifikat, nemlig IdP'ens.

Tillidsoverdragelse vha. ID-kort eller "tickets" har dog en bagside, nemlig at jo længere tid der er gået, siden et ID-kort blev udstedt, desto større er risikoen for, at ID-kortet ikke bliver anvendt af den bruger, som ID-kortet tilhører. Nogle gang glemmer en bruger at logge sig af det lokale system, og dermed kan en anden bruger (mange gange uden at tænke over det) sætte sig til tastaturet og fortsætte med at benytte applikationen i den forrige brugers navn. Et ID-korts "alder" er således en vigtig parameter i sikkerhedsløsningen, og i SOSI forholder vi os til "alderen" ved at lade det være muligt for serviceudbydere at afvise forespørgsler/indberetninger, hvor ID-kortet er for gammelt. Er kravet 8 timer, er der noget større risiko for autenticitetsfejl end hvis kravet er 30 minutter. Er kravet 10 sekunder er det næsten helt sikkert den rigtige bruger, der anvender ID-kortet, men i praksis betyder det også, at brugeren skal afgive sine akkreditiver (f.eks. password) hele tiden.

Et andet aspekt er juridisk uafviselighed. Hvis en serviceudbyder ønsker bevis for, at en bruger har foretaget en given forespørgsel på et givet tidspunkt, kan serviceudbyderen kræve en digital signatur af forespørgslen/indberetningen. I langt de fleste tilfælde vil det dog være tilstrækkeligt med indicier i auditlogs til at godtgøre, at en bruger har foretaget en given forespørgsel. Serviceudbydere kan dog i specialtilfælde kræve en digital signatur.

Løsningens overordnede egenskaber

I dette afsnit redegør vi for fordelene ved SOSI løsningen, set fra forskellige parters synspunkt, nemlig:

• Hvorfor er det en god løsning for de sundhedsprofessionelle?
• Hvorfor er det en god løsning for ejerne af serviceudbydersystemer?
• Hvorfor er det en god løsning for ejerne af serviceaftagersystemer?
• Hvorfor er det en god løsning for leverandørerne?

Det er en god løsning for sundhedsprofessionelle

Vi har tidligere skrevet, at det væsentligste mål, der driver SOSI, er forbedringer i patientens behandligsforløb. Løsningen skal med andre ord kunne påvise, at den giver værdi for de sundhedsprofessionelle i den kliniske hverdag. SOSI løsningen har flg. fordele for de sundhedsprofessionelle:

• En bruger kan med et gyldigt ID-kort benytte mange tjenester hos mange serviceudbydere (Single-Sign-On)
• En bruger vil kun blive afkrævet nyt password, i de situationer der absolut kræver det, f.eks. hvis ID-kortet bliver for gammelt, eller hvis serviceudbyderen kræver digital signatur.
• Løsningen er baseret på direkte system-til-system kommunikation, med mulighed for decentral verificering og autorisation. Løsningen er dermed optimeret mht. svartider.
• Når OCES medarbejdercertifikater er fuldt udrullet, skal brugeren kun holde styr på denne ene identitet (dette ene password) for at kunne anvende tjenester indenfor føderationen.
• Tjenester kan etableres hurtigere og billigere i en SOSI føderation, end med de teknikker der anvendes i dag. Det har en afledt fordel for slutbrugere, der vil få en professionel platform at behandle ud fra tidligere end det ville være muligt i et ad-hoc koordineret miljø.

Det er en god løsning for ejere af serviceudbyder-systemer

Det bliver væsentligt nemmere og billigere at udstille services i sundhedsvæsenet, idet

• Al kommunikation baseres på leverandør- og platforms-uafhængige standarder og teknikker. Dette forbedrer konkurrenceevnen og dermed muligheden for at vælge den leverandør, der bedst kan løse opgaven. Anvendelsen af bredt anerkendte standarder øger samtidig sandsynligheden for at internationale standardprodukter kan anvendes som løsningselementer.
• Etablering af tjenester bliver simplere, idet serviceudbydere ikke skal etablere kontakt med (potentielt mange) autorisationsservices i føderationen for at rekvirere attributter til autorisation - dette centraliseres hos IdP'en og påtrykkes ID-kortet.
• Serviceudbydere skal ikke etablere mekanismer til verificering af certifikater - dette centraliseres hos IdP'en.

Senere i dokumentet vil vi behandle muligheden for at etablere én eller flere SOSI komponenter, der indeholder de fælles mekanismer, der er behov for i SOSI føderationen. Alle serviceudbydere og -aftagere vil kunne anvende og få gavn af en sådan komponent, og det vil dermed blive endnu mere enkelt at udstille og anvende tjenester. Samtidig vil én leverandørs forbedringer til komponenten gavne alle andre parter i føderationen, og der er således sikret maksimal udbytte af det stykke arbejde en leverandør leverer.

Det er en god løsning for ejere af serviceaftager-systemer

• I dag skal systemerne hos serviceaftagere kende og mestre mange forskellige måder at benytte tjenester på. Med en SOSI føderation er anvendelsesmønstret, teknikkerne og formaterne fasttømret. Gentagne forbedringer og udvidelser af serviceaftageres systemer bliver dermed væsentligt billigere, nemmere og hurtigere.
• Konkurrenceevnen forbedres for de systemejere der har arkitekturer, hvor disse "eksterne integrationer" er udskildt i komponenter, f.eks. i de større EPJ systemer.

Det er en god løsning for leverandører

• Leverandører skal kun mestre et begrænset sæt teknikker, standarder og formater. Udgiften til kompetenceudvikling nyansættelser etc. minimeres dermed, med efterfølgende mindre risiko for ikke at kunne genanvende disse kompetencer.
• Da SOSI er platforms-uafhængig kan én leverandør basere sin løsning på netop de kompetencer der differentierer den pågældende leverandør. Leverandøren kan frit vælge programmeringssprog, udviklingsmiljø, testværktøjer etc.
• På et tidspunkt vil antallet af potentielle kunder til SOSI tjenester have nået en kritisk masse, der vil gøre det muligt for nogle leverandører at specialisere sig i udvikling af SOSI tjenester, og dermed forøge muligheden for prækvalifikation i udbudsrunder.

Rollebesætning

En række aktører er allerede på plads i dag og fylder naturligt nogle af de nævnte roller ud:

• TDC: Er allerede CA for OCES certifikater og fungerer derfor som den autoritet der kan udstede og udlevere certifikater.
• Sundhed.dk: Fungerer i dag som det samlende punkt for web-baseret kommunikation med Sundhedsvæsenet og har eksisterende faciliteter til at autentificere medarbejder OCES certifikater. Sundhed.dk vil derfor være et naturligt bud på en IdP.
• SundhedsDataNettet: Defacto netværket for kommunikation mellem Sundhedsvæsenets parter vil naturligt spille rollen som krypteret transportlag.

Sikkerhedsaspekter

Da der vil være meget stor forskel på de lovgivningsmæssige krav til forskellige tjenester har det været nødvendigt at lave et design som er fleksibelt og som præcist kræver den nødvendige sikkerhed i en given situation. SOSI understøtter 4 niveauer af autenticitet. Disse niveauer er koordineret med MedComs "Den Gode WebService" (DGWS). Generelt handler autenticitetssikring om, at en given part i kommunikationen kan overbevise sig om, at brugeren er den vedkommende udgiver sig for at være. Typisk kan en part overbevise sig om dette ved at brugeren eller brugerens system præsenterer nogle akkreditiver, der styrker tilliden til den påståede identitet. I IT industrien er har mest anvendte akkreditiv gennem tiderne været brugernavn+password. Hvis en bruger kan præsentere et password, der hører til en identitet (brugernavn), har man en vis sikkerhed for, at brugeren er den vedkommende påstår at være ... såfremt passwordet ikke er kompromiteret. I nyere tid er man begyndt at benytte stærkere akkreditiver som digitale signaturer (f.eks. OCES), hvor brugeren beviser, at vedkommende har adgang til en privat nøgle. Denne nøgle kan være beskyttet på forskellig vis (typisk et password), og den ekstra sikkerhed består således i, at brugeren beviser, at vedkommende dels kender dette password (uden at sende det) og dels kan få fysisk adgang til den private nøgle. I SOSI og DGWS er der som omtalt 4 autenticitetsniveauer:

SOSI Autenticitetssikring
Autenticitetsniveau	Krævede akkreditiver
4	OCES medarbejdercertifikat
3	OCES virksomhedscertifikat
2	Brugernavn+Password
1	evt. brugernavn

På autenticitetsniveau 1 medsendes ingen akkreditiver. Dette kan f.eks. anvendes ved masseindlevering af data, hvor der ikke kan henføres en bruger. Niveau 2 er det velkendte brugernavn+password akkreditiv. Niveau 3 er "system tillid", hvor klientsystemet beviser sin identitet ved hjælp af "virksomheds digital signatur" (VOCES), og hvor brugeren forventes at være passende autentificeret i klientsystemet. Niveau 4 er anvendelse af personlig digital signatur (MOCES), hvor brugeren selv beviser sin identitet. Niveau 4 benyttes f.eks. i scenarier hvor der kræves sundhedsfaglig autorisation for at få adgang til data. Det kunne være indhentning af journaloplysninger, svar på testprøver etc.

Ovenstående autenticitetsniveauer er relativt godt koordineret med retningslinier som National Institute of Standards and Technology (NIST) har offentliggjort. Det skal dog bemærkes at SOSI niveau 4 svarer til NIST niveau 3. NIST har endvidere udfærdiget flg. skema til vurdering af risici og konsekvenser, og tilsvarende krav til autenticitetsniveau:

VTU har ligeledes valgt at basere deres retningslinier på arbejdet fra NIST. Af tabellen fremgår det, at hvis der blot er lille risiko for fysisk personskade (direkte eller indirekte) som følge af et autenticitetsbrud, så skal serviceudbyderen kræve autenticitetssikring på mindst niveau 3, dvs. baseret på OCES certifikater. Dette vil omfatte en del af de services, vi vil se i sundhedsvæsenet. Omvendt vil der være flere typer af services, hvor der ikke vil være behov for certifikater, f.eks. indberetning af statistiske data til forskning eller lignende. Det er klart, at hvis en bruger har et ID-kort på niveau 3, kan alle tjenester på niveau 1+2 også anvendes.

SOSI beskytter data ved at kræve al kommunikation udført over en krypteret transportlinje som ikke kan aflyttes eller korrumperes uden at parterne opdager det. I Sundhedsvæsenet benyttes SundhedsDataNettet, der er et internetbaseret VPN som drives af MedCom/UNI-C. SundhedsDataNettet udmærker sig ved at have en streng, manuel procedure for hvordan to parter får mulighed for at kommunikere. Først når den konkrete aftale er underskrevet af begge parter åbner MedCom for trafik mellem de ønskede maskiner. Dette betyder i praksis at ingen Serviceudbydere nogensinde vil blive udsat for kald fra Serviceaftagere de ikke allerede har lavet en aftale med.

Ingen kæde er dog stærkere end det svageste led, og da SOSI ikke addresserer lokal sikkerhed i de enkelte parters egne netværk opstår der en potentiel risiko for brist her. Vi antager, at kommunikationen er sikret med SSL3.0/TLS1.0 og dermed sikret mod "Man in the Middle (MITM)", "replay" og andre kendte angreb.:

Det blå stempel

SOSI baseres på etableret infrastruktur og en række standarder. For at sikre at SOSI bliver en løsning, der er bæredygtig i hele sundhedsvæsenet, er der involveret eksperter og organer indenfor forskellige områder, som i kraft af deres tilknytning til industrien vil kunne stå inde for løsningen.

Standarder

Videnskabsministeriet definerer i sit rammeværk for e-Government interoperabilitet en lang række internationale tekniske standarder som benyttes i arbejdet med offentlig forvaltning. SOSI baserer sig på følgende standarder fra dette katalog:

• XML Schema: XML skemaer udtrykker en delt modelforståelse, der tillader maskinel behandling. Skemaer definerer strukturen, indholdet og semantikken af konkrete XML dokumenter. XML skema er en W3C standard fra 2. Maj 2001.
• OIOXML: Dansk standard for hvordan XML skemaer udformes. Udarbejdet af Videnskabsministeriet.
• SOAP: Kommunikationsprotokol, der tillader applikationer at kommunikere med hinanden bla. via HTTP med XML-baseret information. Kan bruges til udveksling af struktureret og maskinskrevet information mellem parter i et decentraliseret, forgrenet miljø.
• HTTP: Hypertext Transportprotokollen, som er fundamentet for webbaseret kommunikation, herunder gængs HTML. Bruges i SOSI til transport af SOAP beskeder.
• WS-Security: XML baseret sikkerhedsspecifikation. Bruges når forskellige organisationer og/eller geografisk adskilte adresser skal integreres ved hjælp af SOAP. WS-sikkerhed arbejder med XML Encryption og XML Signature. Indleveret til OASIS (IBM; Microsoft, Verisign).
• OCES: Dansk standard for digital signatur der giver mulighed for at identificere sig i den digitale verden. Systemet indfrier de basale krav borgere, myndigheder og private virksomheder stiller til sikkerhed for at udveksle fortrolige og følsomme oplysninger over internettet.
• SHA-1 MD5: Mekanisme til at repræsentere en digital signatur af f.eks. en SOAP besked.
• XMLSig: Sikrer oprindelse og integritet af XML meddelelser og standardiserer processen, hvorunder XML indhold signeres og indsættes i XML dokumenter.
• SAML: Muliggør Single-Signon ved at definere en ramme for udveksling af sikkerhedsoplysninger, herunder autentifikation og attributter der kan anvendes til autorisation.

Medcom driver Det Danske Sundhedsdatanet og udstikker desuden standarder for EDI og XML-formater til Sundhedsvæsenet. SOSI baserer sig på følgende ydelser og formater fra Medcom:

• SundhedsDataNettet. Fungerer som sikker, krypteret kommunikationskanal.
• Den Gode Web Service. SOAP konvolut, der indeholder domænespecifikke informationer til brug ved servicekald i Sundhedsvæsenet.

Organer og eksperter

Reviewgruppen er sammensat af parter der indgår i pilotprojekterne samt eksperter fra industrien:

• Videnskabsministeriet/ITST: Kvalitetssikring af anvendelsen af nationale og internationale standarder.
• Medcom: Anvendelse af Sundhedsdatanettet samt review af SOSI og Den Gode Web Service i forening.
• TDC: Certifikatautoritet. Kommentarer til anvendelse af OCES til SSO fra sekundærsektoren.
• Sundhed.dk: Kommentarer til IdP rollen og integrationen.
• IBM/Acure: Leverandør af Sundhed.dk og Medicinprofilen. Kvalitetssikring af integrationen til disse systemer.
• Cryptomathic: Verificerer sikkerhedsaspekterne i løsningen.
• Amtsrådsforeningen: Koordinerer review med amternes arkitekturenheder.
• V-CHI Leverandørforum: Generelt review og sammenhæng med eksisterende systemer.
• Teknologisk Institut: Generelt review.

SOSI komponenten

At bygge en web service i regi af en Service Udbyder, der anvender digitale certifikater og signaturer og kan fungere i en føderation kræver software der kan:

• Bruge en privat nøgle til at underskrive dele af en SOAP konvolut.
• Verificere en digital signatur fra en anden part i føderationen via dennes offentlige nøgle.
• Håndtere certifikater på egne og andre i føderationens vegne.
• Checke et ID-korts gyldighed og validitet.
• Udtrække oplysninger fra et ID-kort og anvende disse til autorisationscheck.
• Overholde de standarder og formater der er sat for føderationen.

Mange af disse opgaver skal også varetages af systemer der indgår i Service Aftager rollen samt af en IdP. Der vil utvivlsomt være en barriere forbundet med at skulle foretage en sådan implementation for nogle af de parter der ønsker at koble sig på føderationen og arbejdsgruppen har derfor identificeret behovet for en komponent som udstiller ovennævnte funktionalitet. Med en sådan komponent til rådighed vil der være en markant mindre barriere for at koble sig på en SOSI føderation, noget der vil være afgørene for om systemet bliver en succes eller ej.

Arbejdsgruppen foreslår udviklingen af en sådan SOSI komponent udført i Java, der er det dominerende sprog indenfor EPJ systemer. Det anbefales at komponenten med kildetekst stilles gratis til rådighed for alle parter i SOSI føderationen. Komponenten bør etableres som et Open Source projekt med en veldefineret udviklingsorganisation bag.

Relateret arbejde

En del fællesoffentlige rapporter relaterer sig til SOSI komplekset eller dele heraf. I udarbejdelsen af designet er disse inddraget som inspiration eller retningslinjer:

• Den kommunale sygeplejes adgang til den Personlige Elektroniske Medicinprofil, version 1.0, 13.09.2004. Devoteam Fischer & Lorentz Rapport for Den Digitale Taskforce om hvordan den kommunale sygeplejes Elektroniske OmsorgsJournal Systemer (EOJ) vil kunne indberette til - og hente oplysninger fra Lægemiddelstyrelsens Medicinprofil.
• Medicineringsprojektet - Den kommunale hjemmesygeplejes adgang til den Personlige Elektroniske Medicinprofil - Evaluering af løsningsscenarier, Version 1.00, 03.06.2005, Strand og Donslund. Rapport for Den Digitale Taskforce der evaluerer løsningsscenarier for en arkitektur, som defineret i Devoteam Fiscer og Lorentz' rapport af 13.09.2004 (ovenfor). SOSI projektet etablerer en variant over "portvagt" mønsteret som skitseret i rapportens afsnit 6, "Perspektivering".
• National IT-strategi for sundhedsvæsenet 2003-2007, 05.2005, Inderigs- og Sundhedsministeriet. Udstikker IT strategien for det samlede danske Sundhedsvæsen. SOSI relaterer sig bla. til initiativ 21 om standarder for kommunikation, initiativ 24 om informationssikkerhed, samt i særdeleshed initiativ 26 om etableringen af en landsdækkende, sikker kommunikationsinfrastruktur.
• Hvidbog om IT-arkitektur, 06.2003, Ministeriet for Videnskab, Teknologi og Udvikling. Generelle retningslinjer og anbefalinger for offentlig IT-arkitektur, bla. om standarder, processer mv. der skal etableres for at få IT-systemer til at arbejde sammen.