healthcareProfessionalHSAId är obligatoriskt i clinicalprocess:healthcond:description men saknas i många vårdsystem

[GoogleCodeExporter]

tjänstedomän : clinicalprocess:healthcond:description

HSAID saknas i många vårdsystem för vårdpersonal. Element 
healthcareProfessionalHSAId är dock obligatoriskt vilket ställer till problem.

Några alternativ:
- Fältet görs 0...1
- Fälttypen ändras till något annat än HSAID
- codeSystem införs så att man kan ange om det är något annat än HSAID

xpath till aktuellt element:
/*[local-name()='GetCareDocumentationResponse' and 
namespace-uri()='urn:riv:clinicalprocess:healthcond:description:GetCareDocumenta
tionResponder:2']/*[local-name()='careDocumentation' and 
namespace-uri()='urn:riv:clinicalprocess:healthcond:description:GetCareDocumenta
tionResponder:2']/*[local-name()='careDocumentationHeader' and 
namespace-uri()='urn:riv:clinicalprocess:healthcond:description:2']/*[local-name
()='accountableHealthcareProfessional' and 
namespace-uri()='urn:riv:clinicalprocess:healthcond:description:2']/*[local-name
()='healthcareProfessionalHSAId' and 
namespace-uri()='urn:riv:clinicalprocess:healthcond:description:2']

Original issue reported on code.google.com by magnus.o...@amplo.se on 1 Oct 2013 at 7:17

[GoogleCodeExporter]

Vi ändrar fältet till IIType och skriver en beskrivning som motsvarar 
NPÖ-rivspecens beskrivning. Assigna till Johan när det är klart (ju förr 
dess bättre) så gör jag en ny release och skickar ut men fråga om de klarar 
att vå med ändringen. 

Original comment by jo...@eltesconsulting.se on 2 Oct 2013 at 3:38

• Changed state: Assigned

[GoogleCodeExporter]

Under eftermiddagen har Fredrik, Khaled och undertecknad jobbat med den här 
frågan, och vår samlade bedömning är att vi inte vill tillåta andra id:n 
än HSA-id (vi har helt enkelt svårt att se användningsområdet för att 
använda ett lokalt id). Vårt förslag är alltså att göra kardinaliteten 
till 0..1 på healthcareProfessionalHSAId.

Original comment by bjorn.ge...@gmail.com on 3 Oct 2013 at 12:47

[GoogleCodeExporter]

Låter bra.

Original comment by magnus.o...@amplo.se on 4 Oct 2013 at 9:34

[GoogleCodeExporter]

Men då tappar vi bakåtkompatibilitet med NPÖ:s RIVSpec vilket är ett krav 
från beställaren. För att gå vidare med den förenklade lösningen (ändra 
kardinalitet) behöver vi först säkerställa att ett sådant meddelande är 
transformativt kompatibelt med nuvarande NPÖ-tjänst (i dess krav på en 
svarstjänsteproducent). Om inte det kan fastställas för tisdagens (8/10) 
TK-gruppsmöte får vi köra med IIType-lösningen.

Original comment by jo...@eltesconsulting.se on 7 Oct 2013 at 6:35

[GoogleCodeExporter]

Beslut: Enligt ursprungligt förslag. Under antagandet att en NPÖ1-transform 
kan skapa värde som NPÖ tekniskt kan acceptera och att värdet i sig ej har 
betydelse för NPÖ:s funktion.

Original comment by jo...@eltesconsulting.se on 8 Oct 2013 at 2:02

[GoogleCodeExporter]

TKB uppdaterad.

Original comment by bjorn.ge...@gmail.com on 9 Oct 2013 at 7:47

[GoogleCodeExporter]

Fixed and comitted.

Original comment by khaled.d...@callistaenterprise.se on 10 Oct 2013 at 7:50

• Changed state: Closed