GEPJ - Interventionsresultat med arketyper

Siden første version af dette dokument er der sket en del ændringer. GEPJ har flyttet sig både fysisk - fra medinfo.dk til sst.dk - og indholdsmæssigt - fra version 2.0 til 2.1. Der har således været al mulig grund til at omskrive dokumentet...

Det nedenstående er en gennemgang og eksemplificering af en arketype-baseret modellering af interventionsresultat i Sundhedsstyrelsens GEPJ. Det er en fortsættelse af mit arbejde med arketyper i GEPJ og skal ses som både baggrundsmateriale for og videreudvikling af den modellering, som er udmundet i GEPJ v2.1 release 20041115.

Modellen

Modelleringen af resultat i GEPJ v2.0 rummede nogle svagheder. Med reference til figur 1 kan disse udtrykkes således:

Utilstrækkelig beskrivelse af egenskaber for resultat

Egenskaberne for resultat blev udtrykt i Interventionsresultat.art. Datatypen var ResultatSpec, som i GEPJ v2.0 gav mulighed for at udtrykke et antal egenskaber. Imidlertid er det vurderet, at man selv med en langt større datatype ikke ville kunne udtrykke alle nødvendige egenskaber i fornøden detalje.

Unødvendig opbinding af resultat til intervention

Det var i GEPJ v2.0 specificeret, at ethvert Interventionsresultat hidrørte fra præcis én Intervention. Dette er unødvendigt for delresultater, hvilket blev påpeget af AAA under GEPKA-projektet.

Begrebsmæssigt uafklaret relation mellem intervention og tidligere resultater

GEPJ v2.0 åbnede mulighed for at Interventionsresultat kunne anvendes i Intervention. Under nøjere begrebsmæssig analyse er man kommet til konklusionen, at den relation, som var tilsigtet, bør udtrykkes som at resultater anvendes i andre resultater - fx vægt og højde anvendes i body-mass-index.

Med henblik på at rette op på disse svagheder i GEPJ v2.0 blev der udviklet en referencemodel, som er beregnet på arketype-modellering - se figur 2:

Betydningen af de enkelte klasser og associationer er som beskrevet i GEPJ v2.1, hvor jeg i dokumentet GEpjDn_Beskriv_021.doc har beskrevet konstruktionen.

I nærværende dokument vil jeg dog gerne give konstruktionen nogle ord med på vejen og således begrunde nogle af de valg, der blev truffet undervejs. Dokumentationen i GEPJ v2.1 release 20041115 forudsættes bekendt.

Attributten Interventionsresultat.resType

er af typen Arketype - en specialisering af EksternID, som blev indført med GEPJ v2.1.

Den oprindelige vision var at specificere arketyper i forhold til et nationalt bibliotek - og som sådan at kunne specificere arketyper med datatypen KlassId. Men en realistisk vurdering af udviklingskadencen i Sundhedsstyrelsen og udviklingskadencen i allerede eksisterende EPJ-udviklingsprojekter betinger, at der næppe vil være et nationalt bibliotek af arketyper, når H:S, AAA og de mange andre projekter går i luften.

Derfor besluttede vi at anvende EksternId til at specificere arketyper, og derved give mulighed for at man lokalt definerer, udvikler og vedligeholder sine egne arketyper.

Attributten Interventionsresultat.midlertidig

betragter jeg som et levn fra tidligere versioner af GEPJ, som vi blot ikke nåede at få med ud sammen med ResultatSpec.

Der er ingen årsag til specielt at fremhæve denne egenskab ved resultat fremfor alle de andre - at et resultat er midlertidigt kan sagtens - og bør - udtrykkes som en arketype-kontrolleret attribut. Men vi havde desværre ikke tiden til at analysere og diskutere det, så attributten lever i GEPJ v2.1. Måske i næste version...

Attributten ResultatInfo.mening

blev af datatypen string - en beslutning, som blev taget i de sidste dages slutspurt op til deadline for GEPJ v2.1.

Langt hen i udviklingsforløbet var 'mening' af typen KlassId, hvilket havde gjort arketyper lettere at standardisere og formodentlig bedret performance ved arketype-baseret implementering.

To faktorer gjorde, at 'mening' skiftede datatype fra KlassId til string:

1. Man skal i OperationeltMaal med præcision kunne specificere den type Interventionsresultat, som målet vedrører. Dette krav betyder, at OperationeltMaal skal indeholde en mekanisme, som kan gengive mindst én sti i en resultat-arketype - fx udtrykke alle blodtryksresultater, som vedrører arterielt blodtryk.

   Den åbenlyse løsning var, at lave en konstruktion i OperationeltMaal, som udgør en forsimplet version af RInfo-konstruktionen - det kunne være så simpelt, som en måde at udtrykke en ordnet liste af KlassId'er. En sådan liste ville kunne erstatte OperationeltMaal.filter.sti og OperationeltMaal.maal.sti - se GEPJ v2.1 Mål&Resultat.

   Men med få dage til en urokkelig deadline og med et massivt pres for ikke at lave mere om end højest nødvendigt, kunne vi ikke overskue at ændre mere på OperationeltMaal. Desværre.

2. At modellere ResultatInfo.mening som KlassId ville stille betydelige krav til GEPJ-terminologien - krav, som vi på tidspunktet for udvikling af konceptet ikke turde forudsætte.

Resultat-arketyperne

I forrige version af dette dokument var arketyper beskrevet vha tabeller og en masse tekst og forklaringer. I GEPJ-udviklingen fandt man, at det var mere formålstjenligt at beskrive arketyper ved et UML-efterlignende visuelt sprog - se beskrivelse og illustrationer i dokumentet GEpjDn_Beskriv_021.doc fra GEPJ v2.1.

Nedenstående præsenteres et supplerende illustrationsmateriale.

Q & A

Jeg får en del spørgsmål om arketyper - ikke specielt om Interventionsresultat, men indtil videre lægger jeg Q&A her...

1. Er man nødt til at implementere arketyper?

   Det spørgsmål ville vi gerne have skrevet et afsnit om i GEPJ v2.1, men tiden slog ikke til.

   Der er nok ikke noget simpelt og klart svar. Og med begrænset indsigt i de langhårede detaljer bag software-implementering er jeg måske ikke den rette til at svare. Så FWIW:

   Det er min opfattelse, at det er en fordel at modellere med arketyper. Ved at acceptere de constraints, som ligger i den meget forsimplede udtryksform tegnet af fx RInfo-konstruktionen (attributter i klynger, én værdi pr attribut), tvinges man til en struktureret tilgang, som gør den begrebsmæssige behandling af problemområdet simpel og let fattelig.

   Uanset om der implementeres arketype-baseret eller ej, er det således min anbefaling, at i hvert fald den initiale udvikling (begrebsanalyse og -struktur) foretages arketype-baseret. Foreligger der først en arketype, er det - alt andet lige - lettere at lave modellering med specialisering.

   
   Figur 3. Pulsresultat - specialisering lavet fra arketype

   På figur 3 er vist et eksempel på en arketype (PULS), som er oversat direkte til en specialisering. Bemærk de på figuren anførte constraints, som på simpel vis ligger indlejret i arketypens fremstilling.

2. I arketyperne - hvad betyder "KlassId= is_a(PULS_TYPE)"?

   Efter udgivelsen af GEPJ v2.1 er det gået op for mig, at vi aldrig fik gjort rede for den anvendte shorthand i arketyperne.

   Idéen er, at arketyper er baseret på terminologi i form af subsets, og en notation som "is_a(PULS_TYPE)" er ment som "er element i subsettet PULS_TYPE".

   Samme mening ligger i en anden notation: "KlassId= {liggende,siddende,stående)", hvor jeg - i stedet for at angive et (logisk) subsetnavn blot har skitseret det relevante udfaldsrum ved oplistning.