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

Issue #301 resolved
Former user created an issue

Ä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?

#####Originally written by bjorn.genfors on code.google.com

Comments (7)

  1. Former user Account Deleted

    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.

    #####Originally written by bjorn.genfors on code.google.com

  2. Former user Account Deleted

    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.

    #####Originally written by johan [eltesconsulting.se] on code.google.com

  3. Former user Account Deleted

    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.

    #####Originally written by bjorn.genfors on code.google.com

  4. Former user Account Deleted

    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.

    #####Originally written by bjorn.genfors on code.google.com

  5. Former user Account Deleted

    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.

    #####Originally written by bjorn.genfors on code.google.com

  6. Björn Genfors

    Sökning på ordinations-id är fortsatt ej möjligt.

    Formuleringen/beteendet rörande sökningar på ordinationskedje-id är nu ändrat till det mer naturliga: de ordinationer som motsvarar sökvillkoret (har ett givet ordinationskedje-id) ska returneras.

  7. Log in to comment