Rammeverk/arkitektur for terminologi og Volven-kodeverk (Var: Bruk av OID for Volven-kodeverk)

[mikree]

Bør man gå bort i fra bruk av OID for Volven-kodeverk i nasjonale profiler?

Spørsmålet kom opp i forbindelse med profilering av Organization i Helse Sør-Øst.

[rockphotog]

Ja, det må være et mål.

Men inntil videre har vi ingen måte å forvalte CodeSystem/ValueSet med Volven-kodeverk, utenat de finnes her og der som en del av profiler/implementasjonsguider. OID'ene "resolver" jo ikke, men det er altså ikke så mye å resolve mot ennå.

Det ønskelige er en (felles) terminologiserver, f.eks. basert på HAPI/Snowstorm der man kan få tilgang til alle kodeverk. Dette bør trolig være en del av felles grunnmur/grunndata.

Direktoratet for e-helse har en terminologiserver for forvaltning av kodeverk (alt fra ICD-10, SNOMED CT til Volven), men det er ikke planlagt noen tjenester for å få runtime tilgang til disse for "sluttbrukere" såvidt jeg vet - publisering er stort sett ut mot portal og andre terminologibaser (som i HSØ).

[oaassv]

Hei Mikal, ut fra samtalene vi har hatt så mener jeg det er prinsipielt riktig å bevege oss bort fra bruk av OID-er for identifikasjon av Volven-kodeverk. Spørsmålet er hvilke avhengigheter som eventuelt eksisterer til andre Volven-referanser som hittil har blitt identifisert med OID-er. Hva er eventuelt problemet med at ny identifikasjonsmåte blir benyttet for dette kodeverket i Organization (dette er er binding til et kodeverk som ikke er benyttet tidligere for ressursen tidligere og ikke er i no-basis?

Hvis ok - er URL-en foreslått av HSØ ok? http://ehelse.no/volven/8624?

Noen innspill på hva som er utfordringene med å gjøre denne overgangen suksessivt vs knyttet til en mer helhetlig overgang og opprydning i eksisterende bruk av Volven-kodeverk? @thomiz, @rockphotog, @kennethmyhra

[rockphotog]

Så lenge URL'en uansett ikke resolver gir det egentlig ikke mening med ny praksis (utover det estetiske).

Overgangen må som nevnt over være knyttet til en faktisk forvaltning/terminologitjeneste. Det kan jo være mulig å tenke seg enklere publisering fordi volumet er lavt (antall Volven-kodeverk man trenger i første omgang til FHIR), men jeg tror overgangen kanskje bare gjør vondt verre.

[oaassv]

@rockphotog - hva mener du i tilfelle er hovedproblemet med å begynne å ta i bruk URL-er i stedet for OID for Volven nå? Når vi får terminologiserver må vi uansett endre til URL-er ….

[kennethmyhra]

Vi burde lage ValueSet, noen ganger ut i fra use-case der man kombinerer flere Volven kodeverk, andre ganger kun ett kodeverk.

Disse kan resolves så lenge de er tilgjenglig for validatoren, slik man oppnår ved å installere pakken fra simplifier.net eller ha de tilgjenglig via annen måte. Det er ingen forskjell på det å resolve et ValueSet vs StructureDefinition. Fint med en terminologiserver, men det er ikke et krav for å kunne resolve ValueSet/CodeSystem.

I DocumentReference og Composition profilene så ble det laget et ValueSet med koder fra Volven: https://github.com/HL7Norway/basisprofiler-r4/blob/master/ValueSet/no-basis-documentreference-type.valueset.xml

[rockphotog]

@oaassv Fordi vi allerede har en måte å gjøre det på for Volven-kodeverk. Å innføre enda en midlertidig praksis når vi ikke har noen god forvaltning gir ingen gevinst -- nettopp fordi vi må endre URL senere uansett.

@kennethmyhra Jeg tenker mest på terminologitjeneste ut fra et forvaltningperspektiv. Det er en fordel at vi har en master, spesielt hvis det kan oppstå dialekter av CodeSystem/ValueSet for det samme Volven-kodeverket.

[oaassv]

@rockphotog - vil det ikke være mulig for en terminologitjeneste å "simulere" stammen i URL-en, slik at vi kan bruke gode URL-navn a la ehelse.no/ som stamme selv om terminologiserveren kanskje hører hjemme i NHN? Ellers blir et en stor jobb å revidere alle profilene når vi en gang får en terminologiserver. Hvis mulig - uansett bra om de som lager noe frem til ta tar utgangspunkt i en fast ULR-struktur - og forslaget fra HSØ kan kanskje være et bra alternativ?

[kennethmyhra]

Et ValueSet som tilhører no-basis burde etter mitt syn forvaltes i dette GitHub-repo og legges ved IG/spesifikasjon slik ValueSet tilhørende FHIR-spesifikasjonen gjør. Laster du ned FHIR definisjonene http://hl7.org/fhir/downloads.html så får du med deg alle ValueSet i tillegg til StructureDefinitions definert i basespesifikasjonen

En canonical base til en terminologiserver som vil være resolvable over HTTP senere burde vi kunne komme opp med, det kan f.eks være http://terminology.ehelse.no/ eller http://terminology.hl7.no/

Følgende canonical benyttet jeg i det ValueSet som jeg referte til over, så det er bra at dette kommer opp så vi kan gjøre et valg rundt dette allerede nå: https://github.com/HL7Norway/basisprofiler-r4/blob/ccea862ff4ac2915dd341329781c1eab0b227a0d/ValueSet/no-basis-documentreference-type.valueset.xml#L4

[thomiz]

@kennethmyhra Bør ikke både ValueSet og CodeSystems egentlig forvaltes på en terminologiserver? Det er jo relativt stor sannsynlighet for at kodeverk og ValueSet's har en annen oppdateringstakt enn profiler?

Beskrivelsen av en FHIR terminolgy service tyder på det: "A FHIR terminology service is simply a set of functions built on the definitions provided by a collection of CodeSystem, ValueSet and ConceptMap resources, with additional inherently known terminologies providing support."

[thomiz]

Forslag til skisse for enkel arkitektur for FHIR terminologi:

Jeg ser for meg at både kodeverk og valueset's kan forvaltes på forskjellige nivåer av arkitekturen altså både nasjonalt, sentralt og i virksomheten. Litt som profiler, det avhenger av brukerhistorien som skal svares ut med ValueSet'et er det kun for intern bruk blir det virksomheten selv som må forvalte ValueSet'et.

[thomiz]

@rockphotog @oaassv Det er vel et poeng i Øyvind sitt spørsmål at vi strengt tatt kan bestemme oss for en URL nå som vi definerer i ValueSet/NamingSystem idag, og oppretter infrastruktur for å forvalte og resolve disse URL'ene en gang i fremtiden?

Har vi ikke egentlig gjort noe av det samme for StructureDefinitions? Vi bruker jo canonicals som :

• http://ehelse.no/fhir
• http://hl7.no/fhir

Ingen av disse resolver jo idag, men vi har vel ambisjoner om at de skal resolve en gang i fremtiden?

[thomiz]

@oaassv Fordi vi allerede har en måte å gjøre det på for Volven-kodeverk. Å innføre enda en midlertidig praksis når vi ikke har noen god forvaltning gir ingen gevinst -- nettopp fordi vi må endre URL senere uansett.

Vi må jo strengt tatt ikke endre URL senere? Det er vel bare å bygge en tjeneste for at dette skal resolve på den adressen vi har definert, det burde jo ikke være helt umulig, men jeg er fremdeles usikker på om vi får det til.

[oaassv]

Gode innspill på terminologiserver, men det er vel fortsatt et stykke frem før vi har en avklaring på det. Kenneth har tatt i bruk en stamme på DocumentReference http://hl7.no/fhir/ValueSet/no-basis-documentreference-type", mens forslaget fra HSØ er å bruke http://ehelse.no/volven/8624. Hva tenker Direktoratet om bruk av ehelse vs hl7.no for kodeverkene (Direktoratet forvalter de). Er det eventuelt en ide å skille mellom ValueSet og kodeverk i den anledning? (jeg tenker hvis vi blir enige om navngivingspolicy må satse på at vi greier å resolve de en gang i fremtiden hva nå endelig løsning blir)

[kennethmyhra]

@thomiz slik jeg leser spesifikasjon er ValueSet kontekstavhengig / use-case spesifikt og henger sammen med en versjon av en IG. At den kan resolve til en terminologi-server er vel det ultimate end-game, men jeg er ikke enig i at de burde forvaltes utenfor IGen, hvis jeg forstår deg rett. Et ValueSet med et predefinert sett med koder fra et eller flere kodeverk burde forvaltes i kontekst av en IG og det settet med koder man har bestemt at det ValueSet skal inneholde burde være låst til en spesifikk versjon av IGen. Når man slipper en ny versjon av IGen kan man legge til eller fjerne koder.

CodeSystem burde forvaltes utenfor en IG, slik som SNOMED CT, LOINC, osv. Usikker på om man har bestemt seg for at Volven er ett eller flere kodeverk (CodeSystem). Om Volven skal være ValueSet er jeg usikker på hvordan vi kan gjenbruke disse inn i ValueSet igjen, det kan godt være man vil hente inn koder fra flere Volven-kodeverk i et ValueSet som benyttes i en profil (StructureDefinition).

Når det gjelder canonical url, for at vi skal være sikre på at vi kan benytte den URLen vi blir enige om så ville jeg sikret meg ved å benytte et sub domain slik som for eksempel http://terminology.hl7.no. http://hl7.no peker vel allerde i dag på en server som hoster nettsidene til HL7 Norge, samme gjelder forøvrig også http://ehelse.no

[thomiz]

@kennethmyhra godt poeng med kontekstavhengigheten for ValueSet's taler for å knytte ValueSet til en IG. Samtidig som det kan hende det finnes noen fordeler med å forvalte ValueSet's (ihvertfall de vi er omforent om nasjonalt) på en nasjonal terminologiserver? Her tror jeg vi må se litt mer på fordeler og ulemper med de forskjellige fremgangsmåtene. Det finnes jo noen ulemper med å sitte å skrive ValueSet's og CodeSystem's for hånd slik vi i praksis må gjøre nå :-)

[kennethmyhra]

@thomiz no-basis er vel det vi er nasjonalt omforent om på et kjernenivå, uavhengig om det er ValueSet eller StructureDefintion (profiler/extensions)? Mulig det finnes unntak, men de vil jeg tro er i mindretall

[thomiz]

@kennethmyhra Enig

[thomiz]

Møte mikal, kenneth, thomas og øyvind

Bakgrunn: Ønsker å kommer riktig i gang med designet på API. Vanskelig å rekonfigurere i ettertid.

Konklusjon: OID er korrekt metode for Volvenkodeverk p.t.

Andre saker: ValueSet lever i kontekst av en IG/profil, og i noen tilfeller lever nå noen kodeverk som en del av no-basis (i FHIR sammenheng) ValueSet'et kan referere til et Volvenkodeverk identifisert med en oid.

Det er for tidlig å gjøre om navngivningen på kodeverk fra Volven nå. Vi må være forsiktige med å definere koder som en del av no-basis enten det er som valueset eller codesystem, siden dette fører til DOBBELT FORVALTNING av kodeverkene i forbindelse med bruk av koder i kodeverk.

[thomiz]

Lukker denne, vi må jobbe videre med infrastruktur og arkitektur for terminologi. Trenger også en infrastruktur for å få til ressursdefinisjonene som vi publiserer på SIMPLIFIER til å bli resolvable. Tyskerne får det til: http://fhir.de/CodeSystem/dimdi/alpha-id http://fhir.de/StructureDefinition/address-de-basis

[rockphotog]

For the record: Jeg mener Volven-kodeverkene er selvstendige CodeSystem. De er vidt forskjellige, og eies av mange - og tilhører som regel en anvendelse der de ble definert (som en meldings-implementasjonsguide, helseregister etc.). Som oftest vil det være et 1:1-forhold mellom CodeSystem og ValueSet her.

Selv om vi ikke får en sentral terminologitjeneste med det første må vi tegne opp forvaltning av Volven/administrative kodeverk ut fra et FHIR-ståsted, og diskusjonen må tas i samarbeid med avdeling kodeverk og terminologi, NHN og andre program som kan være med å finansiere en slik arkitektur og tjeneste - felles grunnmur og helhetlig samhandling. Dette ligger så langt ikke i 2021-planer.

[thomiz]

@rockphotog Det er vel ingen uenighet rundt dette slik jeg ser det. Spørsmålet er slik du skriver hvordan forvalter og distribuerer vi Volvenkodeverk (og andre kodeverk/ValueSet's) i forbindelse med samhandling med FHIR. Jeg tror dette er med i VP for 2021, men på et mer generelt nivå kanskje og antakelig ikke spisset mot FHIR. Kom gjerne med konkrete innspill til skissen for kodeverk/valueset arkitektur.

[thomiz]

Luker ikke denne men bare renamer den så vi ikke glemmer dette, så kan vi diskutere infrastruktur Arkitektur her istedenfor.

[rockphotog]

Jepp - vi (jeg) må rentegne arkitekturskissene for terminologi og FHIR slik at vi kan ta med disse i det videre arbeidet. Vi kommer ikke unna "suboptimale løsninger", men overgangsarkitekturer bør være så gode som mulig. Vi må i samme omgang tenke på både de store (ICD-10, SNOMED CT) og de små, og om det er nødvendig med én, to eller flere mønstre.

[thomiz]

@rockphotog Har vi et felles repo? Mine ligger på VPonline. Det er også en fane med vanligste use-case der.

[rockphotog]

Har laget et repo for områdeprofiler på VP online, vi kan samle det der sp lenge -- men det burde vel kanskje vært laget et felles for terminologi?