Uppdatering av hantering av ID

[GoogleCodeExporter]

I flera av domänerna finns det ett gemensamt problem med hur identiteter 
hanteras. Detta issue gäller för samtliga kontrakt där greenCDA används.

Identiteter anges med endast en sträng, där det anges att strägen ska vara 
unik. I NPÖ-implementationer har man skapat unika ID genom att konkatenera 
organisationens HSA-id med lokalt unikt ID. Den metoden kan ge ID som är 
icke-unika.
I fall där identiteter är HSA-id anges endast HSA-id.
För att öka säkerheten bör ett id anges som en II (insansidentiferare) med 
dels en root och en exension. Detta underlättar även i transformeringen till 
CDA där identiteter allid anges med II.

Original issue reported on code.google.com by fredrik....@mawell.com on 30 Aug 2013 at 12:36

[GoogleCodeExporter]

I CDA/HL7 har man en HL7-typ som heter "II" (Instance Identifier). Den är 
uppbyggd av två delar: en OID för ID-koceptet som används och värdet på 
identiteten. Dessa båda fält ska tillämpas så att de sammantaget ger en 
globalt unik identitet. I de gröna (förenklade) tjänstekontrakten (de som 
publiceras på Google Code) är identiteter lokala - dvs unika inom repsektive 
källsystem. För att man ska kunna skapa unik identifierar finns även 
journalsystemets HSA-id alltid med i meddelandet. Detta gäller t.ex. 
documentId i GetCareDocumentation och careContactId GetCareContacts och 
GetCareDocumentation (här som "främmande nyckel"). Eftersom alla dokument som 
returneras av journalhistorik-kontrakten (de vi utvecklar inom gruppen) även 
ska kunna levereras som HL7 CDA-dokument, kompletteras kontrakten med 
transformeringsskript som översätter meddelanden från dokumentformatet i 
respektive tjänstekontrakt och motsvarigheten enligt HL7 CDA. Det betyder att 
skriptet skapar ett globalt unikt värde för II-strukturens värdedel genom 
att sammanfoga id-fältets värde (t.ex. DocumentId i GetCareDocumentation) och 
HSA-id för källsystemet. Värdet för OID-fältet sätts alltid till samma 
OID - OID:en för "lokalt ID-concept". Konkateneringen behöver ske på ett 
sätt som kan reverseras. Problemet uppstår om ett system använder ett 
standardicerat ID-concept. Det finns då ingen möjlighet att (utan 
systemspecifik anpassning) använda XSLT-skriptet "som det är" och samtidgt 
få med den riktiga OID:en och det ursprungliga ID:t i den II-typ-instans som 
skickas till CDA-konsumenten (det är bara när det finns en CDA-konsument som 
problemet uppstår). Vi identifierade ett par handlingsalternativ för detta 
specifika fall (Vi har en CDA-konsument och producent-systemet använder grönt 
format men har stöd för ett standardiserat ID-koncept och vill att det ska 
förmedlas intakt till CDA-mottagaren):

a) Att behålla nuvarande gröna format enligt ovan. I de fall specialfallet 
ovan uppstår får tjänsteproducentens utvecklare göra en modifiering av 
XSLT-skriptet som följer med RIVTA-kontraktet, genom att ersätta logiken som 
bygger upp en II genom sammanslagning + lokal-OID:en med  logik som sätter 
rätt OID och hoppa över sammanslagningen.

b) Att vi ändrar alla id-fält i alla tjänstekontrakten till att ange en full 
II-struktur istf en enkel sträng. Samt komplettera dokumentationen med 
kravskrivning om att producenterna själva ska göra sammanslagningen och 
sätta lokal-OID:en (förutom de som är II-anpassade enligt ovan).

Beslut: Frågan är viktig, men prioriteringen för detta är lägre än vissa 
andra saker som behöver göras. Sätts till "Won't fix", men kan väckas till 
liv igen.

Original comment by jo...@eltesconsulting.se on 1 Sep 2013 at 6:40

• Changed state: WontFix