Dette indlæg er alene udtryk for skribentens egen holdning.

En spade er en spade er en skovl

25. februar 2008 kl. 13:006
Artiklen er ældre end 30 dage

Jeg er for tiden involveret i et nationalt pilotprojekt, Det Fælles Medicinkort, der bla. sigter på at sørge for at behandlere i sundhedssektoren får adgang til opdateret og relevant information om egne patienters aktuelle medicinering uanset hvor i landet behandleren og patienten befinder sig. Det er et yderst sympatisk projekt, der i fuld skala vil forbedre kvaliteten af patientbehandling i Danmark væsentligt.

Projektet involverer en lang række aktører fra sundhedssektoren herunder Lægemiddelstyrelsen, hjemmeplejen, privatpraktiserende læger og hospitaler. Disse parter har i mange år samarbejdet om patientbehandling og inden projektet startede havde vi teknikere derfor en implicit forventning om at alle også benyttede en fælles sprogbrug.

SOA i Babelstårnet

Men da modelleringsarbejdet gik i gang og man fik arbejdet sig igennem de forskellige aktørers forståelse af domænet stod det klart at der er stor forskel på verden set fra hospitalsgangen og den der ses fra privatpraksisen eller plejehjemmet.

Udfordringer knytter sig bla. til angivelse af medicindoseringer. På sygehuset finder man f.eks. angivelsen "1+1+1+1" i betydningen "1 tablet morgen, middag, aften og nat". Sidstnævnte angivelse svarer i øvrigt til hvad man ofte ser på den privatpraktiserende læges recept.

Artiklen fortsætter efter annoncen

Det lyder måske ikke så slemt, men når de arbejdsgangsunderstøttende it-systemer i begge dele af sektoren har valgt at implementere angivelserne på hver sin måde kan der opstå problemer når data udveksles. I hvert fald hvis man insisterer på at denne type information skal kunne bruges til andet end ren og skær visning f.eks. kontrolcheck og derfor ikke må angives som fri tekst.

Dertil kommer at parterne kan have individuelle ekstra behov som f.eks. når 1+1+1+1 skal associeres med bestemte klokkeslæt hos hjemmeplejen.

Jeg skal skynde mig at tilføje at problemet efter omfattende arbejde fra teknikere og klinikere nu er løst og man er kommet til enighed om en fleksibel model. Det er imidlertid heller ikke pointen.

SOA kræver enighed

Uenigheden om dosisangivelsen har nemlig intet med projektet at gøre og har eksisteret i mange år. Systemet har formodentlig fungeret fordi tolkningen skulle foretages af mennesker, som kan lære at leve med mange alternative angivelser for samme information.

Når den bryder ud i lys lue her er det fordi en servicebaseret arkitektur kræver at kommunikerende parter er enige om hvad der angives, hvornår det angives, syntaks og semantik.

Personligt har oplevelsen givet mig brændt-barn-respekt for de sproglige og semantiske aspekter i at digitalisere tværgående arbejdsprocesser på tværs af organisationer, sektorer og fagfolk.  

It-systemer kan bringes til at skalere og protokoller kan bankes på plads. Det her handler mere end noget andet om mennesker, sprog, arbejdsrutiner, vaner og dogmer. For at lykkes må alle parter have respekt for hinandens faglighed og føle ejerskab for den fælles løsning. 

Det er her de virkeligt store udfordringer i SOA ligger!

6 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
7
26. februar 2008 kl. 09:28

@Peter – fuld respekt mht KMD og det at blogge for sig selv.

Her i landet sætter vi den personlige integritet højt – dette hensyn overgås kun af hensynet til skattevæsenet – så derfor er anvendelse af CPR-numre forbeholdt det offentlige og finanssektoren. Alle andre må bruge andre metoder til at opnå en unik identificering af privatpersoner.

Når det gælder firmaer, er der jo fri anvendelse af CVR. Men her driller det mange, at firmaregistrering ikke er lige så entydig som personregistrering.

Alt i alt er registrering af stamdata – på engelsk Master Data Management – en stor udfordring for mange. Som tidligere nævnt skærper SOA denne udfordring – men giver også nye muligheder.

6
25. februar 2008 kl. 22:54

@Henrik, Nu er det vores kunder, der kan kræve CPR-numre af alle og enhver, ikke os. Og firmaet hedder KMD nu, ikke Kommunedata :-)

(jeg udtaler mig forresten aldrig herinde på vegne af KMD - jeg taler altid kun for mig selv)

Du peger på et andet vigtigt krav til en succesfuld SOA end fælles begreber, nemlig det at kunne identificere et objekt på tværs af systemer uden der er enighed om primærnøglen eller at den ikke må bruges som i CPR-nummerets tilfælde. Nogle af RKIs webservices afspejler problemet med at identificere en person når nu CPR-nummeret ikke må bruges – der skal bruges diverse underlige kombinationer af andre data, fx. fødselsdato, postnummer og vejnavn eller noget i den dur.

Og hvis et objekt ikke engang kan identificeres entydigt inden for et system, så er der tale om alvorlige datakvalitetsproblemer som i dit teleselskabs-eksempel i en anden kommentar ( http://www.version2.dk/artikel/6202#p12388 ). I en SOA bliver den slags kun værre.

5
25. februar 2008 kl. 21:24

@Peter – ja, udfordringer er der nok af, men i jo heldige hos Kommunedata, at i sådan kan rende rundt og kræve CPR-numre af alle og enhver. Andre dødelige er nødt til at identificere folk som fx: ’Grigoriy Sostakovic, Oehlenschlægersgade 577, et sted i København’.

4
25. februar 2008 kl. 20:46

@Niels, jeg er helt enig: Begreber skal bare være afklarede og ensrettede (eller deres forskellige betydninger fastlagt og beskrevne og også gerne versionerede) før man kan bruge services.

Det er en bekræftelse af ideen om "hvis du ikke kan få det til at fungere på papir, så kan du heller ikke elektronisk"

OIOXML initiativet fra IT&ST skulle være det offentliges garant for en vis kvalitet af veldefinerede begreber. Og det har masser af gode elementer i sig som kan hjælpe med at fastlægge begreber. Men her beskrives kun interfacet, ikke semantikken og alt for meget skrammel har sluppet igennem nåleøjet.

Fx. skal et CPR-nummer være på 10 cifre med et avanceret regulært udtryk til at tjekke formatet ... eller 10 nuller efter hinanden som bruges ”hvor personnummeret er påkrævet men ukendt” (det står der!). Og CPR-nummer strukturen bor i kernen af OIO, dvs. et element der SKAL genbruges. Så hvad gør man så, hvis man vil kræve et rigtigt CPR-nummer i et interface?

Se selv: http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/CPR_PersonCivilRegistrationIdentifier.xsd

1
25. februar 2008 kl. 14:32

Datakvalitet er netop en udfordring – men også en mulighed i relation til SOA.

Som du skriver er det ikke bare formen – i form af protokoller og standarder – men også indholdet, som man skal interessere sig for.

I den forbindelse er SOA med til at skærpe kravene til definition og konsolidering af data. Men samtidig giver SOA også nogle nye muligheder for at løse disse udfordringer. Dette kan fx ske ved at have nogle centrale eller måske ligefrem eksterne regler og hjælpedata, som er tilgængelige for hele ’forretningen’ i alle processer. Dette kan understøttes ganske godt af SOA tankegangen og de underliggende teknologier.