SIT-0104 Anvisning för informationsmodellering - Webbhotell SLL
SIT-0104 Anvisning för informationsmodellering - Webbhotell SLL
SIT-0104 Anvisning för informationsmodellering - Webbhotell SLL
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>SLL</strong> IT<br />
Förvaltningen <strong>för</strong> IT-ramverket<br />
IT-ramverket<br />
<strong>Anvisning</strong><br />
<strong>SIT</strong>-<strong>0104</strong><br />
ITR-026<br />
<strong>SIT</strong>-<strong>0104</strong> <strong>Anvisning</strong> for <strong>informationsmodellering</strong><br />
Version 1.0 Datum 2009-09-23<br />
Denna anvisning beskriver vilka krav IT-ramverket ställer på en<br />
informationsmodell och vilka rapporter som ska lämnas in innan<br />
<strong>för</strong>granskning.<br />
RRR 8, Ramverkstillämpningar och plattformsfunktioner utgår från<br />
fastställda informationsmodeller.<br />
Beslutsdatum: Klassificering: Beslutad av: Styrgruppen <strong>för</strong> IT-ramverket<br />
2009-09-23 K1R2T1<br />
Dokumentets namn: <strong>SIT</strong>-<strong>0104</strong> <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
1 (14)
1 Allmänt ...................................................................................................3<br />
1.1 Dokumentets typ och målgrupper ..................................................3<br />
2 Referenser.............................................................................................. 4<br />
3 Bakgrund ................................................................................................5<br />
4 Syfte ....................................................................................................... 6<br />
5 Notation................................................................................................. 6<br />
5.1 Grafer..............................................................................................6<br />
5.2 Klasser ............................................................................................6<br />
5.3 Samband .........................................................................................6<br />
5.3.1 Associativa samband ..............................................................7<br />
5.3.2 Generiska samband.................................................................7<br />
5.4 Attribut .........................................................................................10<br />
6 Tillvägagångssätt .................................................................................. 11<br />
6.1 Deltagare.......................................................................................11<br />
6.2 Harmoniering mot <strong>SLL</strong> RIM........................................................11<br />
6.3 Granskning ...................................................................................12<br />
7 Dokumentation.....................................................................................13<br />
7.1 Rapporter ......................................................................................13<br />
7.2 Filer från Qualiware......................................................................13<br />
7.3 Märkning ......................................................................................13<br />
Bilaga 1.....................................................................................................14<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Sid 2(14)
1 Allmänt<br />
1.1 Dokumentets typ och målgrupper<br />
För vem<br />
>>>>>>>>><br />
Typ av dokument<br />
Övergripande<br />
principer<br />
Informationsmodeller<br />
<strong>Anvisning</strong><br />
PlattformsfunktionsbeskrivningIntegrationstjänstbeskrivningSystemarkitekturdokument<br />
(SAD)<br />
Mall<br />
Projektledare/<br />
Förvaltare<br />
Modellör Arkitekter<br />
Informatik<br />
+++<br />
+++<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Arkitekter<br />
Teknik<br />
Utvecklare<br />
Sid 3(14)
2 Referenser<br />
Ref Dokument<br />
ID<br />
R1<br />
Dokument<br />
http://www.uml.org/<br />
R2 <strong>SIT</strong>-0063 Termer, begrepp, kodverk<br />
R3 ProjektiL granskningsbild, PROJEKTiL<br />
R4 <strong>SIT</strong>-0112 Checklista <strong>för</strong> informationsmodeller<br />
R5 <strong>SIT</strong>-0129 Rapportmall <strong>för</strong> informationsmodeller<br />
R6 <strong>SIT</strong>-0130 Presentationsmall <strong>för</strong> inforamtionsmodeller<br />
R7 http://www.webbhotell.sll.se/sv/itramverket/Kunskapsbas/Modeller/Informationsmodeller/<strong>SLL</strong>-RIM/<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Sid 4(14)<br />
R8 LIT-0127 http://www.webbhotell.sll.se/Global/ITramverket/Dokument/Modeller/Fl%c3%b6desmodeller/Informatikfl%c3%b6de.pdf<br />
Tabell 1. Referenser eller rapporter som har LIT-/<strong>SIT</strong>- nummer publiceras<br />
på IT-ramverkets hemsida, www.it-ramverket.sll.se
3 Bakgrund<br />
I figuren nedan visas det flöde där denna anvisning är aktuell.<br />
Figur 1. Flöde <strong>för</strong> att ta fram en informationsmodell och harmoniera den med <strong>SLL</strong> RIM<br />
(Stockholms Läns Landstings referensinformationsmodell). Den kompletta bilden finns i<br />
bilaga 1<br />
Med informationsmodell menas här en grafisk och textuell beskrivning av<br />
struktur och innehåll <strong>för</strong> den verksamhetsinformation som hanteras i ett<br />
informationssystem.<br />
För att säkerställa att <strong>informationsmodellering</strong>arna görs på ett enhetligt<br />
sätt skall dessa anvisningar följas. Den notation vi <strong>för</strong>espråkar är<br />
huvudsakligen hämtad från Unified Modeling Language (UML) [R1].<br />
Genom att använda metodiskt analyserade och formellt definierade<br />
verksamhetsbegrepp i informationsmodellerna kan kvaliteten på<br />
informationsmodellerna <strong>för</strong>bättras och miss<strong>för</strong>stånd som uppstår mellan<br />
verksamhetsrepresentanter och övriga projektmedlemmar kan undvikas.<br />
Det är där<strong>för</strong> lämpligt att använda fastställda termer och begrepp <strong>för</strong><br />
namnsättning av klasser och attribut. Dessa bör hämtas från fastställd<br />
terminologi eller begreppsmodell. Förklaringstexter i klassdiagrammen bör<br />
också utgå ifrån entydiga definitioner. [R2]<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Sid 5(14)
4 Syfte<br />
Syftet med detta dokument är att ange regler <strong>för</strong> hur en informationsmodell<br />
ska ritas och tolkas. Informationsmodeller används inom IT-ramverket <strong>för</strong><br />
att strukturera de informationsbehov som verksamheten har i ett visst<br />
sammanhang. Dessa informationsbehov modelleras inom ramen <strong>för</strong> t.ex.<br />
ett projekt eller en <strong>för</strong>valtning.<br />
5 Notation<br />
5.1 Grafer<br />
Informationsmodeller noteras med klassdiagram enligt Unified Modeling<br />
Language, (UML).<br />
5.2 Klasser<br />
Klasser i informationsmodellen är av tre typer: instansklass, typklass och<br />
extern klass. Klasser benämns i singularis och namnet på klassen börjar<br />
med versaler, dvs. stor bokstav. Samtliga klasser ska färgkodas.<br />
En instansklass representerar <strong>för</strong>ekomster av information i<br />
verksamheten, dvs. information som skapas i den ”verkliga världen”. Ett<br />
exempel är den information som hamnar i vårddokumentation om en<br />
identifierad patient, t.ex. information om en ut<strong>för</strong>d operation.<br />
Typklasser visar information om de typer av <strong>för</strong>ekomster som finns i<br />
verksamheten. Det kan vara typer av aktiviteter, typer av tillstånd etc.<br />
Externa klasser är klasser som är definierade i andra modeller som vi vill<br />
referera till från vår modell.<br />
Klasser:<br />
• Klasser är av tre typer: instansklass, typklass, extern klass<br />
• Benämns i singularis<br />
• Namnet på en klass börjar med versaler<br />
• Färgkodning enligt följande: instansklasser med färgen ljusgul,<br />
typklasser med färgen orange, externa klasser färgkod ljusblå<br />
5.3 Samband<br />
Ett samband är en koppling mellan två informationsklasser. Ett samband<br />
innebär att vi vill hålla reda på sambandet mellan två informationsklasser,<br />
t.ex. att en ”Journal avser en och endast en Patient”.<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Sid 6(14)
I en informationsmodell finns flera typer av samband: associativa och<br />
generiska samband.<br />
5.3.1 Associativa samband<br />
Associativa samband ritas som visas i figur 2. På etiketten <strong>för</strong><br />
sambandet visas ett litet pilhuvud som anger läsriktning <strong>för</strong> namnet på<br />
sambandet. Multipliciteten eller kardinalitetsvillkoret <strong>för</strong> sambandet anges<br />
i slutet. M.a.o. anger att man läser multipliciteten i pilens riktning vid den<br />
klass som sambandet går till. Första siffran är minsta antalet referenser<br />
som en klass kan ha till en annan. Det gäller alltså i ena riktningen. Andra<br />
siffran är den övre gränsen. En asterisk (*) betyder att det inte finns någon<br />
övre gräns, dvs. godtyckligt många.<br />
IT-ramverket har in<strong>för</strong>t <strong>för</strong>kortningarna 1 <strong>för</strong> (1..1) och (*) <strong>för</strong> (0..*).<br />
Sambandsnamn börjar alltid med gemener, dvs. liten bokstav, och kan<br />
bestå av flera ord med små bokstäver. Man läser sambandet i figur 2 som<br />
”Person äger noll till flera Bilar”. Det går bra att lägga till ett namn på<br />
sambandet inom parentes som gäller andra riktningen. Namnet utan<strong>för</strong><br />
parenteserna läses i pilen riktning. I riktning mot pilen läser man omvänt<br />
”Bil ägs av en och endast en Person”, tyvärr är möjligheten att ange<br />
inversnamn (namn på läsning av samband i omvänd riktning) borttagen i<br />
UML.<br />
attribut<br />
Person<br />
heter: Namn [1..*]<br />
borPå: Adress [*]<br />
Samband<br />
(associativt)<br />
1 *<br />
äger<br />
multiplicitet<br />
Figur 2. Exempel på notation av multiplicitet (kardinalitetsvillkor) <strong>för</strong> ett samband och <strong>för</strong><br />
attribut.<br />
5.3.2 Generiska samband<br />
Generiska samband går från specifika klasser (subklass) till generella<br />
klasser (superklass), i figur 4 visas ett exempel där som subklassen är Man<br />
och superklassen är Person, det utläses som Man är en Person.<br />
Det går också bra att säga att en subklass är en delmängd av superklassen.<br />
Till exempel: mängden av alla Kunder är en delmängd av alla Personer eller<br />
med andra ord, en Kund är också en Person. Det betyder att en Kund har<br />
alla egenskaper (samband och attribut) som en Person har.<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Bil<br />
identifierasAv: RegNr [1]<br />
Sid 7(14)
Generiska samband kallas ibland generalisering och inversen, dvs.<br />
sambandet i motsatt riktning, kallas specialisering.<br />
Det finns två huvudtyper av generiska samband och det är ”uttömmande”<br />
och ”överlappande”. ”Uttömmande” betyder att subklasserna utgör en<br />
fullständig uppdelning av superklassen. ”Överlappande” betyder att<br />
subklasserna kan överlappa varandra, t ex att vissa element i subklasserna<br />
Anställd och Kund <strong>för</strong> Person kan vara desamma.<br />
Notera att subklasser som tillhör olika specialiseringshierarkier alltid är<br />
överlappande då de har olika specialiseringskriterier. Negativa <strong>för</strong>ekomster<br />
uttrycks med ”ej uttömmande” respektive ”ej överlappande”. Dessa<br />
varianter kan alla kombineras. Exempelvis kan ett samband vara ”ej<br />
uttömmande ” och ”överlappande”.<br />
Dessa varianter representeras alla i UML med samma grafiska symbol.<br />
Skillnaderna anges med en villkorstext, dvs. Uttömmande, Ej<br />
uttömmande, Överlappande, Ej överlappande (se figur 3).<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Sid 8(14)
Ej uttömmande: Det finns personer<br />
som inte är anställda<br />
Person<br />
Anställd<br />
Ej uttömmande<br />
Utömmande: Alla personer är<br />
antingen män eller kvinnor<br />
Utläses: anställd är en person Utläses: man och kvinna är personer<br />
Överlappande: En del kunder kan<br />
vara anställda och en del anställda kan<br />
vara kunder<br />
Person<br />
Överlappande<br />
Anställd Kund<br />
villkorstext<br />
Utläses: anställda och kunder är<br />
personer<br />
Person<br />
Man Kvinna<br />
Ej överlappande: En person är<br />
antingen man eller kvinna men inte<br />
både och. Alternativt: ingen person<br />
kan samtidigt vara kvinna och man.<br />
Person<br />
Utläses: man och kvinna är personer<br />
Figur 3. Exempel på de olika typerna av generiska samband med egenskaperna ej<br />
uttömmande, uttömmande, överlappande och ej överlappande.<br />
För generiska samband kan man också ange en diskriminator. Den anger<br />
vilken egenskap som avgör om en klass tillhör en viss subklass. För<br />
specialiseringen i man och kvinna är diskriminatorn kön. För anställd och<br />
kund kan det vara avtalstyp. Kriteriet pekar alltså ut en egenskap <strong>för</strong><br />
superklassen. En klass kan ha mer än en diskriminator samtidigt (t ex mankvinna<br />
respektive anställd-kund). I UML sägs att alla generiska samband<br />
med samma kriterium tillhör samma hierarki.<br />
IT-ramverket har in<strong>för</strong>t konventionen att rita ihop pilspetsarna <strong>för</strong> de<br />
generiska samband som tillhör samma hierarki (Figur 4).<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Uttömmande<br />
Ej överlappande<br />
Man Kvinna<br />
Sid 9(14)
diskriminator<br />
n<br />
Person<br />
avtalstyp<br />
Anställd Kund<br />
Figur 4. Notationen vid mer än ett generiskt samband <strong>för</strong> en klass<br />
Samband<br />
• Är av två typer: associativa samband och generiska samband<br />
• Namn inleds med gemener<br />
• Multipliciteten noteras med: 1, *<br />
Kvinna<br />
{ Överlappande<br />
Ej uttömmande Man<br />
• De olika typerna av generiska samband ritas i UML med samma<br />
grafiska symbol och skillnaden anges med en villkorstext (figur 3<br />
och 4)<br />
• Generiska samband som tillhör samma hierarki noteras genom att<br />
rita ihop pilspetsarna (figur 4)<br />
5.4 Attribut<br />
Ett attribut är en koppling från en informationsklass till en annan<br />
informationsklass, ett kodverk eller en datatyp. Attribut fungerar på samma<br />
sätt som samband. De ritas dock inte ut i diagrammet utan läggs i<br />
attributfacket på klasserna som de utgår från (se figur 2).<br />
Attributnamn börjar alltid med en gemen och skrivs ihop till ett ord om det<br />
består av mer än ett. Varje nytt ord får då en versal <strong>för</strong> att de skall kunna<br />
särskiljas. Exempel: identifierasAv, avKod.<br />
Normalt byggs attributnamn och samband upp av ett verb eller en verbfras.<br />
Det gör att man kan läsa sambandet och <strong>för</strong>stå vad det betyder; t.ex.<br />
’Person äger:Bil’, ’Bil identifierasAv:Regnr’ eller ’Personidentitet avKod<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
kön<br />
{ Uttömmande<br />
Ej överlappande<br />
Sid 10(14)
Personnummer’. För attribut kan bara huvudriktningens multiplicitet anges<br />
i UML och den sätts inom hakparentes efter attributtexten (se figur 2).<br />
Attribut<br />
• Refererar till en annan klass, ett kodverk eller till en datatyp<br />
• Attributnamn börjar alltid med en gemen och skrivs ihop till ett<br />
ord, där varje nytt ord börjar med versal men inleds med gemen<br />
• Byggs normalt upp av ett verb eller en verbfras<br />
• Anger sin multiplicitet endast <strong>för</strong> huvudinriktningen inom<br />
hakparentes efter attributnamnet.<br />
6 Tillvägagångssätt<br />
6.1 Deltagare<br />
I modelleringsarbetet bör följande roller besättas:<br />
• modelleringsledare<br />
• <strong>för</strong>eträdare <strong>för</strong> verksamheten<br />
• <strong>för</strong>eträdare som deltagit i verksamhetsanalys inom projektet<br />
• representant från IT-ramverket<br />
6.2 Harmoniering mot <strong>SLL</strong> RIM<br />
För varje klass i projektmodellen skall en harmoniering mot motsvarande<br />
klass i <strong>SLL</strong> RIM göras[R7].<br />
<strong>SLL</strong> RIM är uppbyggd i 6 vyer:<br />
1. Vård och behandling<br />
2. Organisation och befattning<br />
3. Vårdplanering<br />
4. Resursplanering<br />
5. Hälsotjänst<br />
6. Koder och identifierare<br />
Initialt bestäms till vilken vy i <strong>SLL</strong> RIM den aktuella klassen tillhör. Det är<br />
t.ex. en aktivitet som görs <strong>för</strong> en patient ingår den i vy ett och skall härledas<br />
till klassen Patientrelaterad aktivitet.<br />
Härledningen dokumenteras <strong>för</strong> klassen enligt:<br />
<strong>SLL</strong> RIM klass, typ av härledning (ren specialisering, härledningsregel), om<br />
det är en härledningsregel skall den anges i beskrivande text.<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Sid 11(14)
Exempel:<br />
Ut<strong>för</strong>d tjänst<br />
BoS <strong>SLL</strong> RIM<br />
avKod : GVD kod [1..1]<br />
avTyp : Beställningsbar Tjänst (typ) [0..1]<br />
harBenämning : Text [0..1]<br />
harUt<strong>för</strong>dtid : Tidpunkt [0..1]<br />
harUt<strong>för</strong>dtidsintervall : Tidsperiod [0..1]<br />
harKommentar : Text [0..1]<br />
Ut<strong>för</strong>d tjänst motsvarar<br />
Patientrelaterad aktivitet och<br />
aktivitetsstatus i <strong>SLL</strong> RIM<br />
Figur 5. Ut<strong>för</strong>d tjänst i projektet BoS och Patientrelaterad aktivitet i <strong>SLL</strong> RIM<br />
I ovanstående exempel skulle BoS dokumentera harmonieringen som:<br />
Ut<strong>för</strong>d tjänst är en specialisering av Patientrelaterad aktivitet med<br />
Aktivitetsstatus = ”ut<strong>för</strong>d”.<br />
Säkerställande av gemensamma kodverk<br />
Modellen ska innehålla de kodverk man behöver. En grundregel är att<br />
använda redan fastställda kodverk. Man ska i projekt och <strong>för</strong>valtningar<br />
undvika att ta fram egna kodverk om sådana redan finns fastställda [R2].<br />
6.3 Granskning<br />
Enligt ProjektiL, Stockholms läns landstings projektmodell, ska granskning<br />
av projektet ske av IT-ramverket [R3]. Granskningen genom<strong>för</strong>s i två steg<br />
där det i <strong>för</strong>sta steget ingår en granskning av informationsmodellen.<br />
Granskning av informationsmodellen sker enligt en granskningsmall [R4]<br />
som är upprättad inom IT-ramverket.<br />
I det andra steget görs en formell granskning av projektet tillsammans med<br />
IT-ramverket. Där granskas om projektet har uppfyllt de Regler, Riktlinjer<br />
och Rekommendationer (RRR) som krävs – däribland att en<br />
informationsmodell är gjord och godkänd i det <strong>för</strong>sta steget.<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Patientrelaterad aktivitet<br />
identifierasAv : Aktivitetsid [1]<br />
avTyp: Patientrelaterad aktivitet (typ) [1]<br />
1<br />
⊳ gäller<br />
Sid 12(14)<br />
Aktivitetsstatus<br />
1..* avKod: AktStatuskod [1]<br />
from: Tid [1]<br />
tom: Tid [0..1]<br />
harOrsak : Text [0..1]
7 Dokumentation<br />
Vid leverans av modell till IT-ramverket skall följande dokumentation<br />
bifogas.<br />
7.1 Rapporter<br />
Modellerna skall beskrivas enligt strukturen i en rapportmall [R5] där<br />
man anger syfte, bakgrund/sammanhang, resultat, eventuella avvikelser<br />
och resterande arbete. En PowerPoint-presentation skall tas fram som<br />
pedagogiskt presenterar modellvyerna och hur de hänger ihop. En mall <strong>för</strong><br />
ppt-dokumentation finns [R6].<br />
7.2 Filer från Qualiware<br />
För modeller som ritas i Qualiware programmet ska alltså exportfilen av<br />
modellen inlämnas.<br />
7.3 Märkning<br />
Alla dokument (modellvyer, rapporter och klassrapporter) ska<br />
versionsmärkas och innehålla följande uppgifter både i dokumentet och i<br />
filnamnet:<br />
• Klassrapporten eller modellens innehåll eller namn. Exempel:<br />
Beställning och svar.<br />
• Dokumentnamn. Exempel: Klassrapport eller informationsmodell.<br />
• Versionsnummer.<br />
• Datum då versionen togs fram.<br />
Dokumentation:<br />
• Rapport ska skrivas<br />
• En PowerPoint-presentation ska tas fram<br />
• Modellerna ska märkas med namn datum och version<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
Sid 13(14)
Informatikens arbetsflöde<br />
2007-11-19, version 0.9<br />
LIT-0127, FRV-156<br />
Forum/AVI<br />
Uppdrag<br />
Verksamhetskrav<br />
Verksamhets<br />
RRR<br />
Bilaga 1<br />
IT-ramverket<br />
Informatik<br />
Förvalta informatik<br />
Kriterier <strong>för</strong> när<br />
informationsmodell skall<br />
tas fram<br />
Projekt<br />
eller<br />
<strong>för</strong>valtning<br />
Ta fram<br />
informationsmodell<br />
Informatik dokument<br />
RRR<br />
8<br />
<strong>Anvisning</strong> <strong>för</strong><br />
<strong>informationsmodellering</strong><br />
Informations<br />
modell<br />
Harmoniera med <strong>SLL</strong><br />
RIM<br />
<strong>Anvisning</strong>:<br />
<strong>SLL</strong> RIM<br />
RRR<br />
9<br />
<strong>Anvisning</strong> <strong>för</strong> harmonisering med<br />
<strong>SLL</strong> RIM<br />
Förgranska<br />
informationsmodell<br />
Harmonierad<br />
informationsmodell<br />
Granskningsmall <strong>för</strong><br />
informationsmodell<br />
Nej<br />
Ja<br />
Godkänd?<br />
Ta fram meddelande<br />
Ta fram<br />
meddelandemodell<br />
Dokumentets namn: <strong>Anvisning</strong> <strong>för</strong> <strong>informationsmodellering</strong><br />
RRR<br />
77<br />
Ja<br />
Meddelande<br />
modell<br />
<strong>Anvisning</strong> <strong>för</strong><br />
meddelandemodellering<br />
RRR granskning<br />
Förgranska<br />
meddelandemodell<br />
Ja<br />
Godkänd?<br />
Nej Ja<br />
Ta fram RMIM<br />
RRR<br />
73<br />
RMIM<br />
Sid 14(14)<br />
Utforma meddelande<br />
Meddela
Change language