search

HL7Norway / innrapportering-helseregister

Innrapportering helseregister
2 stars 0 forks source link

Søkemuligheter på informasjon i Composition #3

Open thomiz opened 3 years ago

thomiz commented 3 years ago

Vi har lite erfaring med søk etter informasjon i en Composition Bundle. Søkemulighetene på innholdet i en Composition Bundle virker begrensede. Dette er ikke så viktig for selve innrapporteringen, men hvis IG også skal beskrive brukstilfeller for å finne tak i tidligere registreringer på pasient/gjort av helseperson etc., så bør IG skissere noen løsninger for dette.

I det hele tatt bør vi ha en oversikt over de viktigste brukstilfellene, forslag:

linnbrandt commented 3 years ago

@thomiz Hvor leste du dokumentasjon om søkemulighetene i Composition? Bra usecases. Fint å tenke på det fra start

Et annet use case: Det går ann å definere alle variablene i et registerskjema/pakke slik at man skal kunne lage et spørreskjema ut av det. Slik de har gjort det med Arketype-templater. Så det er forskjell på selve innrapporteringen, og definisjoner og informasjon man trenger til å generere spørreskjemaet. Hvordan ville det sett ut om man brukte FHIR? Questionnaire som spørreskjema? Selv om det er rene datapunkter der? Composition der også?

thomiz commented 3 years ago

Hei igjen @linnbrandt leste meg litt opp på Bundle og Composition ressursene, samt en diskusjon på Chatten: https://chat.fhir.org/#narrow/stream/179167-hapi/topic/Bundle.20search.20using.20composition.20attributes

Er litt usikker på hvilke praktiske konsekvenser dette vil få for søk. Hvis man har en ren REST basert tilnærming vil man typisk benytte en referanse til en eksisterende person ressurs og alle innrapporteringer vil da kunne referere til samme ressurs noe som gjør det enkelt å finne alle resultater for en bestemt subject, eller lagt inn av en bestemt helseperson. MEN man oppnår bare dette hvis produsentene faktisk refererer til de samme Patient/Organization/Practitioner-ressursene.

Hvis du bygger dokumenter og sender disse inn inkluderer du typisk alle nødvendige ressurser (PAtient, Practitioner og Organization) inn i Composition bundle, og benytter interne referanser (som bare gjelder i det spesifikke dokmentet) for å henvise til disse ressursene. Da blir det i praksis umulig å finne alle dokumenter sendt inn fra samme organisasjon eller forfattet av samme helseperson ved hjelp av et søk.

MEN jeg har ikke forsøkt dette i praksis, og jeg er usikker på om det har betydning for de brukerhistoriene vi forsøker å svare ut her?

rockphotog commented 3 years ago

Litt av trikset er hvordan FHIR fungerer som en REST-fasade (også for dokumenter), hvordan man lagrer informasjonen i en database (mange metoder), og hvordan man skiller mellom APIer som har med skriving/henting av dokumenter og mer detaljerte queries.

Går dokumentene inn i en database kan man spørre på databasen. Men for å finne ut hvilket dokument som var kilde for den enkelte opplysning (la oss si en diagnose) må det følgelig være en relasjon mellom den enkelte opplysning og dokumentet. Databasedesign ligger utenfor FHIR-scope, men det vil være en "smal sak" å designe en slik tjeneste, da FHIR stiller sterke krav til referanser - det må bare gjøres i flere steg.

Brainstorm (K = klient, S = server) (Ikke samme use case som Thomas skriver i OP)

K: Finn pasienter med diagnose X OG der diagnosen er registrert mellom 2012 og 2019 OG er menn over 65 (REST er fantastisk!) S: Returnerer liste med pasienter K: Finn dokumenter av typen A (f.eks. et komplett utfyllt skjema til et register) koblet til pasientene i forrige svar S: Returnerer liste med dokumenter K: Gjør eventuelt et utvalg basert på dokumentlisten, og ber om å hente ett og ett dokument fra den S: Returnerer dokument(er)

Man søker altså ikke mot selve dokumentet. Det er "uendelige" muligheter, og det er opp til serveren med tilhørende database og FHIR REST API som bestemmer hva som er mulig og hvor enkelt det kan være. Det er også mulig å lage operations for å forenkle mye brukte queries.

Uansett må man lage gode use case/anvendelser, som er helt nødvendige innspill til hele arkitekturen, ikke bare FHIR-fasaden.

Litt tilbake til dokumentdeling

Dokumentdeling type XDS og FHIR documentReference er to sider av samme sak. Ofte må man tilbys en liste av dokumenter basert på hva som er lov, hente ned en dokumentliste med metadata om dokumentene, gjøre ytterligere valg, og dermed be om dokumentet. Potensiell hit and miss.

F.eks. for XDS er det viktig at man IKKE kan søke på f.eks. diagnoser, da dette vil kunne gjøre dokumentregisteret (som inneholder metadata, ikke selve dokumentene) til et behandlingsrettet register, og dermed ha helt spesielt (skjerpede) krav til tilgangskontroll.

Jeg antar at de som får tilgang til (anonyme) helsedata for forskning uansett vil være under særdeles god tilgangskontroll, og tjenestene kan designes annerledes (les: mer brukervennlige enn tradisjonell dokumentdeling).

Ok, det var dagens noe usammenhengende post, men summa summarum: Vi må se på hele arkitekturen.

thomiz commented 3 years ago

Ja, dette er riktig, men bare HVIS server tar FHIR dokumentene, pakker disse opp OG gjør personinformasjonen tilgjengelig for søk som du beskriver. Jeg gjetter ut fra diskusjonen på Chatten at endel standard FHIR servere IKKE gjør dette og at det er funksjonalitet som må utvikles spesielt. Dokumentasjonen for Bundles sier dette: A bundle is a collection of resources that can have an independent existence - for example, they might also be accessed directly using the RESTful API

Det som bekymrer meg er can og might, det står ikke noe SHALL og MUST her.

thomiz commented 3 years ago

Eksempel fra Hapi.fhir.org http://hapi.fhir.org/baseR4/Bundle/1624983

Pasienten finnes ikke med søk på Patient: http://hapi.fhir.org/baseR4/Patient?identifier=4711 http://hapi.fhir.org/baseR4/Patient?family=Musterfrau

Det siste søket gir treff, men ikke på "vår" Musterfrau. Altså på denne FHIR serveren kan vi ikke gjøre disse søkene for å finne alle dokumenter som handler om denne pasienten. Så da må vi ha en annen funksjonalitet implementert på server, eller bruke et Composition type søk for å finne dokumenter som omhandler pasienter vi er interessert i.

Det kan være greit å spesifisere hvordan vi mener FHIR tjenesten skal fungere for å støtte denne type søk. Og her er det flere muligheter:

rockphotog commented 3 years ago

Ja, dette er riktig, men bare HVIS server tar FHIR dokumentene, pakker disse opp OG gjør personinformasjonen tilgjengelig for søk som du beskriver

Jepp, HAP trenger dette, men det er en annen use case - her er det vel snakk om å få tilgang til egne innrapporterte data/dokumenter?

Da tror jeg det er viktig å samle alle use case først som sist for å se hva som må være krav til registrene, som

...så får man ta det over en lang en å ønske at det også er mulig å søke på data inne i dokumentene, men som sagt tror jeg det er mest nærliggende for forskere/konsumenter mot HAP, og ikke f.eks. EPJ mot kvalitetsregister.

thomiz commented 3 years ago

Helt enig, det viktigste use-caset her er antakelig å opprette ny innrapportering som inneholder komplett informasjon, og i størst mulig grad kunne gjenbruke informasjon fra kildesystemet direkte inn i en strukturert form.

Så kan det være opp til klienten å sørge for at de ikke oppretter mer enn en versjon og hvis oppdatering av innrapporteringen, kan man stille krav til at det er klienten som må ha riktig dokument-id for oppdatere. Mange registre vil antakelig ikke godta oppdatering av innrapporteringer uansett kanskje.

Det er antakelig også viktig å synliggjøre at HVIS systemet skal støtte litt mer avanserte funksjoner for innrapportering og søk i innrapporterte data, så må systemeier sørge for at dette støttes og det vil ikke alltid komme som standardfunksjonalitet ut av FHIR-boksen.

rockphotog commented 3 years ago

Jepp. Overgangsarkitekturer og beskrivelse av mulighetene blir derfor viktig. Noen kan lage en så enkel (men fullt funksjonell) løsning, andre kan "ta den helt ut", med lagring av kladder, oppdateringer av tidligere innsendte oppgaver etc.

linnbrandt commented 3 years ago

Jeg la utkast til use-case-ene, krav og eksempler på en Wiki, så er de samlet. De må redigeres videre. https://github.com/HL7Norway/innrapportering-helseregister/wiki/Use-case-FHIR-for-Innrapportering-til-helse-kvalitetsregistre