En spade er en spade er en skovl

Af 7

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.

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!

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Henrik Liliendahl Sørensen

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.

  • 0
  • 0
#2 Deleted User

Det er godgørende at se en gammel sandhed bryde frem til overfladen igen - integrationer handler ikke kun om den tekniske betydning og syntaks, men i lige så høj grad om den forretningsmæssige betydning. Dette synspunkt har jeg først som løsningsarkitekt og siden som enterprise architect fremført for mange organisationer siden midten af 90'erne. De tager som regel godt imod synspunktet, men kun på skrømt - det er vel noget IT-drengene ordner - ikke?

Nixen - det er først og fremmest forretningens opgave og ansvar. Jeg har netop været med til at skrive en kogebog i intergration mellem ESDH-systemer og fagsystemer baseret på et pilotprojekt. Over 65% af ressourcer og kræfter skal inversteres i at afklare begreber og betydninger mellem de involverede parter i en læreproces før man tager fat på den tekniske integration.

Dette skal organisationerne involveret i integrationer erkende og være parat til at sætte kræfterne af til. Ellers for intergrationerne ikke nær den forretningsmæssige effekt, som de kan have.

Det er glædeligt at ønsket om forandringsparate værktøjer og arbejdsgange på tværs i det offentlige igen sætter dette på dagsordenen via SOAs popularitet og nødvendig som IT-arkitektur stil. Og det udtiller igen-igen at uden forretningsarkitektur i form af processer og begreber/information ingen SOA, der dur

  • 0
  • 0
#4 Peter Nørregaard Blogger

@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_PersonCivilRegi...

  • 0
  • 0
#5 Henrik Liliendahl Sørensen

@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’.

  • 0
  • 0
#6 Peter Nørregaard Blogger

@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.

  • 0
  • 0
#7 Henrik Liliendahl Sørensen

@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.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen