Sökning på ordinations-id ej möjligt (GMH)

[GoogleCodeExporter]

Ärende inkommit via mejl:

[När jag tittar] på prescriptionID, så noterar jag att det inte finns med 
som sökparameter. Är det ett medvetet design-beslut? [[Som i så fall borde 
dokumenteras?]]

[[ Ordinations-ID (prescriptionID) är i det här tjänstekontraktet synonymt 
med ”documentId”. Egentligen förstår jag inte alls vitsen, med att ha 
begreppen ”dokument-ID”, ”dokument-titel” med här alls. Ser ut som 
någon slags rest ifrån pappersjournal tänk… ]]

Om man utgår ifrån relationer, så torde det ju vara möjligt att i andra 
tjänstekontrakt som brukas för NPDi, att referera till en viss ordination. 
Men när man sedan önskar slå upp just ett visst ordinations-ID, så går det 
ju inte, eftersom sökparametern saknas. 

Finns det något implicit krav på att dylika relationer enbart får peka ut 
ordinationskedje-id? Detta så att relationen går att slå upp, därför att 
denna finns som sökparameter? I så fall – var finns detta dokumenterat?

Original issue reported on code.google.com by bjorn.ge...@gmail.com on 8 Mar 2015 at 10:49

[GoogleCodeExporter]

Frågan, såsom jag förstår den, är egentligen ställd som följer: "det 
finns möjlighet att söka efter ordinationer på ordinationskedje-id men inte 
ordinations-id, varför det?"

Att inte ordinations-id går att söka efter är helt symmetriskt med övriga 
NPÖ2-kontrakt, där dokument-id (eller motsvarande id). Att det däremot är 
möjligt att göra sökningar på ordinationskedje-id är tillkommet efter 
önskemål från NOD-projektet. Detta kan tyckas vara bristfälligt 
dokumenterat, och jag ska ta upp det i TK-gruppen på nästa möte.

Vad anbelangar relationskonceptet: som nämndes ovan så saknar övriga 
NPÖ2-kontrakt också möjligheten att söka på dokument-id, men även dessa 
informationsmängder kan relateras till. Att inte ha möjlighet att söka på 
specifika id:n var ett generellt inriktningsbeslut som togs för länge sedan, 
och som inte har omprövats, eller åtminstone ändrats, sedan dess. Anser 
någon att detta är ett stort bekymmer så bör den generella frågan lyftas 
till TK-gruppen.

Och som sidonotering kan också nämnas att "dokument-id", "dokument-titel" 
osv. är begrepp som också förekommer helt symmetriskt med andra 
NPÖ2-kontrakt. I vissa kontrakt passar begreppen bättre, och i andra något 
mindre bra.

Original comment by bjorn.ge...@gmail.com on 8 Mar 2015 at 11:11

[GoogleCodeExporter]

Relationskonceptet (som frågan tycks ha sin grund i) har genomgått 
kvalitetssäkring som del av den generella kvalitetssäkringsaktiviteten för 
NI-kontrakten (GetObservations, GetActivities) som pågått sedan December i en 
lite bredare gruppering än TK-gruppen. Det arbetet har resulterat i en del 
ändringar som slår "över hela linjen". Dessa ändringar kommer att 
remitteras i integratörsgruppen innan den fastställs. Just nu förbereds 
underlagen. I korthet kan förslaget sammanfattas så här:

1. Relationskonceptet kommer att använda VG istf källsystem som bas för 
externt id (orsak: nationella arkitekturen bygger på principen om att 
ändringar i systemlandskapet inte får ha dominoeffekter på integrerande 
parter. En konsekvens av det är att källsystems identiteter inte kan lagras i 
andra huvudmäns system).

2. Relationskonceptet avgränsas till att enbart finnas för observationer och 
aktiviteter, dvs de kliniska, kontextfria informationsmängderna i NI-modellen. 
Relationer kommer bara att kunna uttryckas mellan instanser av dessa båda 
klasser. De mer kontextfulla klasserna/tjänstekontrakten som modellerats på 
NPÖ:s och NOD:s -RIV-specifikationer kommer istället att få nya (frivilliga) 
element för att identifiera respektive kontextfullt objekts kontextfria 
representation. För GMH-kontraktet innebär det att elementet activityId 
tillkommer (givet att ordinationer i NI-modellen faller under Aktivitet, annars 
Observation). Och att man kan ange activityId som sökparameter till GMH. Man 
använder alltså GetObservations och GEtActivities för att bena ut 
relationer. Om en Activity är av typen Ordination, kan man hämta dess 
GMH-inkarnation genom att göra GetMedicationHistory(activityId). Och 
motsvarande för t.ex. GetLaboratoryOrderOutcome(observationId). 

Just (till på tisdag) undersöks konsekvenser av en sådan omställning för 
befintliga kontrakt och intressenter. 

Original comment by jo...@eltesconsulting.se on 8 Mar 2015 at 11:30

[GoogleCodeExporter]

En liten sidokommentar för den intresserade: det är tveksamt om ordinationer 
kommer att falla under vare sig aktivitet eller observation i NI. Ett 
begreppsområde som har stor potential att svälja begreppet ordination är 
"beslut". Det är ett begreppsområde som Socialstyrelsen ännu inte har 
börjat arbeta med, så denna kommentar är av delvis spekulativ karaktär.

Alldeles oavhängigt detta är essensen i Johans kommentar ovan oförändrad.

Original comment by bjorn.ge...@gmail.com on 8 Mar 2015 at 12:03

[GoogleCodeExporter]

På samma tema (som först inkomna mejl) har följande mejl också inkommit:

För sökfältet ”prescriptionChainId” står det:
”Ordinationskedje-id. Används för att endast ge poster avseende en viss 
ordinationskedja. Om producenten har stöd för kedjor, så returneras senaste 
ordinationsposten i kedjan med angiven status aktiv/inaktiv. Om producenten 
saknar stöd för kedjor, så returneras alla poster med angiven status (och 
som möter övriga sökvillkor)”

Jag förstår inte varför detta beteende specificeras? Följande formulering 
hade jag förstått mig på:
”Om producenten har stöd för kedjor, så returneras alla ordinationsposten 
i kedjan …” eller ”… så returneras enbart ordinationsposter ur kedjan 
…”
”Om producenten saknar stöd för kedjor, så… beaktas inte denna 
sökparameter. 
  I detta fall bör ett ”INFO” meddelande biläggas svaret, vilket anger att ’stöd för sökning på ordinations-kedjor saknas’.”

Att ha en sökparameter som begränsar till senaste post i kedjan, tycks mig 
avvika från hur sökparametrar i allmänhet brukar uppträda. Den här typen 
av parametrar fungera ju som ”filter”, men inte som absoluta ”ID” 
sökvillkor där man bara ska få ett svar.

Original comment by bjorn.ge...@gmail.com on 8 Mar 2015 at 2:26

[GoogleCodeExporter]

Och svaret på detta är också "önskemål från NOD". Men det låter inte vid 
omläsning såhär ett år senare som att det är den absolut mest logiska 
implementationen. Jag ber att få återkomma om det här ämnet efter att jag 
har tagit upp det i TK-gruppen.

Original comment by bjorn.ge...@gmail.com on 8 Mar 2015 at 2:28