Anvisning för utformning av nyttolast i tjänstekontrakt

 

Anvisning för utformning av nyttolast i tjänstekontrakt


Version 1.0
ARK_0061
2020-12-03

Innehållsförteckning

Revisionshistorik

Revision

Revisionsdatum

Beskrivning

Ändringarna gjorda av

Definitiv revision fastställd av

Revision

Revisionsdatum

Beskrivning

Ändringarna gjorda av

Definitiv revision fastställd av

1.0

2020-12-03

Revision 1.0 fastställd.

Thomas Siltberg, Arvid Thunholm, Lars Börjesson, Claudia Ehrentraut, Viktor Jernelöv

Tjänstekontraktsförvaltningen & Samverkansarkitektur

Referenser

Referens-id

Namn

Länk

Inledning

När nya tjänstekontrakt/domäner tas fram ska anvisningar som styr såväl den tekniska som informatiska utformningen följas. Anvisningar finns i form av RIV Tekniska Anvisningar [R5], VI-boken [R6], listor över kodverk och identifierare [R2, R3] samt De facto-konventioner för datatyper [R1].

Denna anvisning utgör ett stöd för de personer som arbetar med att beskriva innehållet i tjänstekontrakt, framförallt genom informationsspecifikationer och tjänstekontraktsbeskrivningar. Anvisningen omfattar i dagsläget information om hur vissa datatyper ska tillämpas.

Hur avsteg från det som beskrivs i anvisningarna, respektive detta dokument hanteras beskrivs under Gör avsteg.

Sätt datatyp

I befintliga tjänstekontrakt (XML-scheman) används ett antal datatyper (komplexa typer) som är gemensamma inom en domän eller för flera domäner. Dessa beskrivs på defacto-sidan [R1].

Följ nedanstående steg för att bestämma om en gemensam datatyp kan användas för ett attribut inom det tjänstekontrakt som du arbetar med:

  • bekanta dig med de datatyper som finns på defacto-sidan [R1]

  • avgör om någon eller några av de befintliga defacto-datatyperna som anges kan tillämpas för attributet i frågan

    • om någon eller några av de befintliga defacto-datatyperna kan användas, så ska de, i möjligaste mån, tillämpas i det formatet/den strukturen som är specat på defacto-sidan [R1]. OBS! Om avsteg ska göras från hur datatypen är utformad ska det hanteras enligt beskrivning under Gör avsteg.

    • om inga av de befintliga defacto-datatyperna kan användas för attributet i frågan är det tillåtet att använda sig av andra etablerade datatyper eller skapa egna komplexa typer. Kontakta förvaltare av defacto-datatyperna om du ser behov av att någon av dessa datatyper kan vara relevanta för andra tjänstekontrakt och därmed bör ingå i defacto-datatyperna.

Generella regler för tillämpning av datatyper

Vid tillämpning av en datatyp ska alla attribut som ingår i datatypen listas i fältregeltabellen i TKB:n, där nedanstående hantering för attributen gäller:

  • attributens namn och datatyp får inte ändras

  • attributens befintliga beskrivningar ska anges i TKB men får konkretiseras ytterligare om tillämpningen kräver det

  • attributen som är icke-obligatoriska, t.ex codeSystemName, codeSystemVersion, displayName samt originalText för CVType eller extension för IIType, får ändras till att vara obligatoriska om tillämpningen kräver det. Multipliciteten sätts då till 1..1. OBS! Om schematron eller andra sätt att validera används behöver de uppdateras.

Reglerna som beskrivs för datatyps-attributen under tabellen på defacto-sidan [R1] ska gälla vid tillämpningen. Schemat som finns för respektive datatyp på defacto-sidan [R1] ska användas.

Tillämpning av CVType

Datatypen CVType ska användas för att skicka kodade värden. Beskrivningen av datatypen och dess schema finns på defacto-sidan [R1]. Vid tillämpningen av CVType ska Generella regler för tillämpning av datatyper samt nedanstående anvisningar om val av kodverk, typ av kodverksanvändning och urval följas.

Välj kodverk

När datatypen CVType används behöver det väljas/pekas ut ett kodverk, resp. ett urval som omfattar de koder som ska skickas för attributet i frågan. I befintliga tjänstekontrakt används olika kodverk som finns sammanställt på kodverkslistan [R2].

Följ nedanstående steg för att bestämma om ett kodverk kan användas för ett attribut inom det tjänstekontrakt som du arbetar med:

  • bekanta dig med de kodverk som finns på kodverkslistan

  • avgör om något av de befintliga kodverken som listas kan tillämpas för attributet i frågan

    • om något av de befintliga kodverken kan användas, så ska den refereras till i enlighet med datatypens utformning.

    • om inget av de befintliga kodverken kan användas för attributet i frågan kan det vara aktuellt att

      • skapa eller uppdatera ett kodverk. I detta fall ska processen för att skapa eller uppdatera kodverk [R4] följas.

      • använda sig av ett annat etablerat kodverk. Kontakta kodverksförvaltningen för att utreda om kodverket ska tas med i kodverkslistan.

I dokumentationens referenslista ska alltid referens till kodverkslistan [R2] anges.

Bestäm typ av kodverksanvändning

Efter att ha bestämt vilket kodverk som ska användas behöver det utredas om en specifik version av kodverket ska användas för attributet i frågan (statisk kodverksanvändning) eller om koderna som skickas snarare bör härstamma från den senaste versionen av kodverket (dynamisk kodverksanvändning). Nedan anges när respektive typ av kodverksanvändning kan vara aktuellt.

  • Statisk kodverksanvändning

    • främst aktuellt när det ska byggas logik på koderna som skickas, på producent-, resp. konsumentsidan. T.ex. statuskoder.

    • ange kodverkets version som ska användas i beskrivningen för attributet codeSystemVersion

    • om ett begränsat antal koder ingår i kodverket, lägg till dessa som enumerations i XML-schemat

    • lägg in codeSystem, codeSystemName (om den finns) och codeSystemVersion som fixed values i XML-schemat

  • Dynamisk kodverksanvändning

    • främst aktuellt för kodverk som uppdateras regelbundet, som t.ex. Snomed och ICD-10 och där koderna från den senaste versionen av kodverket ska visas upp på konsumentsidan.

    • i beskrivningen för attributet som är av typ CVType, ange efterföljande information: “Kodverket kan komma att kompletteras över tid vilket medför att konsumenter av kontraktet behöver vara förberedda på att nya koder kan tillkomma utan att versionen på kontraktet uppdateras.” alt för urval “Urvalet kan komma att kompletteras över tid vilket medför att konsumenter av kontraktet behöver vara förberedda på att nya koder kan tillkomma utan att versionen på kontraktet uppdateras.”

    • lägg in codeSystem som fixed value i XML-schemat (behöver inte göras för urval som hanterar koder från flera kodverk)

    • varken kontroll av koder eller version med hjälp av schematron-validering anses vara tillämpbart i detta scenario.

Hantera urval med koder från ett eller flera kodverk

I vissa tillämpningar ska urval från ett eller flera kodverk hanteras. I dessa fall ska det anges i TKB:ns beskrivning för attributet vilket urval som används. För codeSystem ska det skickas kodverkets identifierare, inte urvalets. När ett urval innehåller koder från två eller flera kodverk ska detta tydliggöras i beskrivningen genom att ange följande: “Urvalet innehåller koder från flera kodverk. Under codeSystem ska det anges identifieraren för det kodverket som koden som skickas tillhör. Detta medför att det kan skickas olika identifierare under codeSystem, beroende på vilket kodverk den skickade koden tillhör.“

En mall för att skapa urval finns på kodverkslistan [R2].

Tillämpningsexempel

Exempel #1 - statisk kodverksanvändning

Nedan ges ett exempel på hur CVTypen kan tillämpas för attributet careContactCode. Exemplet illustrerar en statisk kodverksanvändning. Exemplet omfattar hur attributet ska beskrivas i TKB:n samt i XML-schemat.

Enligt Generella regler för tillämpning av datatyper ska, vid tillämpning av en datatyp alla attribut som ingår i datatypen listas i fältregeltabellen i TKB:n. Det är tillåtet att konkretisera attributens beskrivningar, vilket har gjorts i nedanstående exemplet i form av de gul-markerade texterna. Datatypens icke-obligatoriska attribut får ändras till att vara obligatoriska om tillämpningen kräver det, vilket har gjorts för attributet displayName i nedanstående exemplet.

Namn

Dokument

Kommentar

Länk

Namn

Dokument

Kommentar

Länk

R1

Kodverkslista

Finns på Webben

https://inera.atlassian.net/wiki/spaces/KINT/pages/3615655

Namn

Typ

Beskrivning

Multiplicitet

Namn

Typ

Beskrivning

Multiplicitet

../../careContactCode

CVType

Kod som anger på vilket sätt vård- och omsorgskontakten är planerad att ske, alternativt skedde. Kodverket “Kv vårdkontakttyp” ska användas, se referens [R1]. Det är koderna från version 2.0 som ska skickas.

0..1

../../../code

string

Kod eller uttryck definierad enligt kodverket.

1..1

../../../codeSystem

string

Kodverket som definierar koden. OID:en för Kv vårdkontakttyp ska anges, dvs “1.2.752.129.2.2.2.25”

1..1

../../../codeSystemName

string

Kodverkets namn i klartext, dvs. “Kv vårdkontakttyp”.

0..1

../../../codeSystemVersion

string

Versionsangivelse som har definierats specifikt för det givna kodverket, dvs “2.0”.

0..1

../../../displayName

string

Den läsbara representationen (klartext) av koden eller uttrycket som definierat av kodverket.

1..1

../../../originalText

string

Texten så som sedd och/eller vald av användaren som har matat in den, och som representerar användarens avsedda betydelse.

0..1

Nedan presenteras hur tillhörande XML-schemat ska vara utformat.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 <xs:complexType name="careContactCode"> <xs:complexContent> <xs:restriction base="CVType"> <xs:sequence> <xs:element name="code" type="xs:string" /> <xs:element name="codeSystem" type="xs:string" fixed="1.2.752.129.2.2.2.25" /> <xs:element name="codeSystemName" type="xs:string" fixed="Kv vårdkontaktyp" minOccurs="0" /> <xs:element name="codeSystemVersion" type="xs:string" fixed="2.0" minOccurs="0" /> <xs:element name="displayName" type="xs:string" /> <xs:element name="originalText" type="xs:string" minOccurs="0" /> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType>

Exempel #2 - dynamisk kodverksanvändning

Nedan ges ett exempel på hur CVTypen kan tillämpas för attributet careContactCode när ett urval med koder från ett kodverk används. Exemplet illustrerar en dynamisk kodverksanvändning. Exemplet omfattar hur attributet ska beskrivas i TKB:n samt i XML-schemat.

Enligt Generella regler för tillämpning av datatyper ska, vid tillämpning av en datatyp alla attribut som ingår i datatypen listas i fältregeltabellen i TKB:n. Det är tillåtet att konkretisera attributens beskrivningar, vilket har gjorts i nedanstående exemplet i form av de gul-markerade texterna. Datatypens icke-obligatoriska attribut får ändras till att vara obligatoriska om tillämpningen kräver det, men detta har inte varit aktuellt i nedanstående exemplet.

Namn

Typ

Beskrivning

Multiplicitet

Namn

Typ

Beskrivning

Multiplicitet

../../careContactCode

CVType

Kod som anger på vilket sätt vård- och omsorgskontakten är planerad att ske, alternativt skedde. Medlemmar i 58181000052100 |urval kontaktsätt| från kodverket Snomed CT SEs ska användas, se referens [R1].

Urvalet kan komma att kompletteras över tid vilket medför att konsumenter av kontraktet behöver vara förberedda på att nya koder kan tillkomma utan att versionen på kontraktet uppdateras.

0..1

../../../code

string

Kod eller uttryck definierad enligt kodverket.

1..1

../../../codeSystem

string

Kodverket som definierar koden. OID:en för Snomed CT SE ska anges, dvs “1.2.752.116.2.1.1”

1..1

../../../codeSystemName

string

Kodverkets namn i klartext, dvs. “Snomed CT SE”.

0..1

../../../codeSystemVersion

string

Versionsangivelse som har definierats specifikt för det givna kodverket.

0..1

../../../displayName

string

Den läsbara representationen (klartext) av koden eller uttrycket som definierat av kodverket.

0..1

../../../originalText

string

Texten så som sedd och/eller vald av användaren som har matat in den, och som representerar användarens avsedda betydelse.

0..1

Nedan presenteras hur tillhörande XML-schemat ska vara utformat.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 <xs:complexType name="careContactCode"> <xs:complexContent> <xs:restriction base="CVType"> <xs:sequence> <xs:element name="code" type="xs:string" /> <xs:element name="codeSystem" type="xs:string" fixed="1.2.752.116.2.1.1" /> <xs:element name="codeSystemName" type="xs:string" fixed="Snomed CT SE" minOccurs="0" /> <xs:element name="codeSystemVersion" type="xs:string" minOccurs="0" /> <xs:element name="displayName" type="xs:string" minOccurs="0" /> <xs:element name="originalText" type="xs:string" minOccurs="0" /> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType>

Alternativ användning vid tillämpningen

Det är giltigt att använda CVTypen för att bara lagra den text som användaren matat in eller yttrade. I denna situation kommer originaltexten att existera utan kod. I en situation där koden tilldelas någon gång efter att texten matats in är originaltexten den text eller fras som använts som grund för att tilldela koden. Att tillämpa CVType på det sättet bör enbart göras i undantagsfall och ska hanteras enligt beskrivning under Gör avsteg.

I vissa fall kan det vara omöjligt eller oönskat att binda ett kodverk eller urval till ett attribut i tjänstekontraktet, t.ex. eftersom kodverket anses kunna variera i olika tillämpningar. Det är då tillåtet att lämna information om kodverket tomt. Avsteget bör dokumenteras och motiveras i enlighet med beskrivning under Gör avsteg.

Tillämpning av IIType

Datatypen IIType ska användas för att skicka identifierare. Beskrivningen av datatypen och dess schema finns på defacto-sidan [R1]. Vid tillämpningen av IIType ska Generella regler för tillämpning av datatyper samt nedanstående anvisningar om val av identifierare följas.

Välj identifierare

När datatypen IIType används behöver det väljas/pekas ut en identifierare. I befintliga tjänstekontrakt används olika identifierare som finns sammanställt på listan över identifierare [R3].

Följ nedanstående steg för att bestämma om en identifierare kan användas för ett attribut inom det tjänstekontrakt som du arbetar med:

  • bekanta dig med de identifierare som finns på på länkad sammanställning

  • avgör om någon av de befintliga identifierare som listas kan tillämpas för attributet i frågan

    • om någon av de befintliga identifierare kan användas, så ska den refereras till i enlighet med datatypens utformning.

    • om ingen av de befintliga identifierare kan användas för attributet i frågan kan det vara aktuellt att

      • använda sig av andra etablerat identifierare. Kontakta kodverksförvaltningen för att utreda om identifieraren ska tas med i sammanställningen.

I dokumentationens referenslista ska alltid referens till lista över identifierare [R3] anges.

Tillämpningsexempel

Nedan ges ett exempel på hur IIType kan tillämpas för attributet personId. Exemplet omfattar hur attributet ska beskrivas i TKB:n samt i XML-schemat.

Enligt Generella regler för tillämpning av datatyper ska, vid tillämpning av en datatyp alla attribut som ingår i datatypen listas i fältregeltabellen i TKB:n. Det är tillåtet att konkretisera attributens beskrivningar, vilket har gjorts i nedanstående exemplet i form av de gul-markerade texterna. Datatypens icke-obligatoriska attribut får ändras till att vara obligatoriska om tillämpningen kräver det, vilket har gjorts för attributet extension i nedanstående exemplet.

Namn

Dokument

Kommentar

Länk

Namn

Dokument

Kommentar

Länk

R1

Lista över identifierare

Finns på Webben

https://inera.atlassian.net/wiki/spaces/KINT/pages/468746902

Namn

Typ

Beskrivning

Multiplicitet

Namn

Typ

Beskrivning

Multiplicitet

../../personId

IIType

Person- eller samordningsnummer.

1..1

../../../root

string

En identifierare som i sig själv eller tillsammans med värdet för extension är universellt unik. Om extension anges är root en unik identifierare av namnrymden för värdet som anges i extension. För personnummer ska OID ”1.2.752.129.2.1.3.1” anges, för samordningsnummer OID ”1.2.752.129.2.1.3.3”.

1..1

../../../extension

string

En identifierare som tillsammans med värdet för root är universellt unik. Används om värdet på root inte är universellt unikt. Personens faktiska personnummer eller samordningsnummer ska anges, t.ex. “191212121212”

1..1

Nedan presenteras hur tillhörande XML-schemat ska vara utformat.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <xs:complexType name="personId"> <xs:complexContent> <xs:restriction base="IIType"> <xs:sequence> <xs:element name="root" type="personIdRoot" /> <xs:element name="extension" type="xs:string" /> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:simpleType name="personIdRoot"> <xs:restriction base="xs:string"> <xs:enumeration value="1.2.752.129.2.1.3.1" /> <xs:enumeration value="1.2.752.129.2.1.3.3" /> </xs:restriction> </xs:simpleType>

Gör avsteg

Om avsteg görs från rådande anvisningar, resp. beskrivningar som finns i föreliggande dokumentet ska beslutet dokumenteras och motiveras i tjänstedomänens arkitekturella beslut (AB).