Validering av kodeverk

[rockphotog]

Tester Torinox for validering (egen branch), og da var det ikke til å komme unna

[WARNING] Terminology service failed while validating code '' (system ''): Cannot retrieve valueset 'urn:oid:2.16.578.1.12.4.1.1.3402' (at Patient.address[0].extension[0].extension[0])

Jeg ser ikke at vi får en fungerende terminologiserver basert på Healthterm og Volven-kodeverkene der med det første, og typiske kodeverk som kommunenummer er nok helt sikkert ikke pri -- kan det være mulighet å se på en enkel midlertidig løsning? Om enn lage et enkelt script som konverterer et Volven-kodeverk til et (CodeSystem+)ValueSet.

Nå som flere og flere tar i bruk f.eks. basisprofilene hadde det vært fint å kunne tilby mulighetene for 100% validering.

[rockphotog]

API for KLASS, som er kilden for 3402: https://data.ssb.no/api/klass/v1/api-guide.html

Eksempel curl 'http://data.ssb.no/api/klass/v1/versions/1160' -i

[thomiz]

En warning på en oid er i prinsippet ikke så viktig. "alle" forstår at en oid ikke kan resolves direkte i FHIR og at man derfor dessverre må behandle disse kodeverkene spesielt.
Ønsker de som ønsker å validere mot kodene i kodeverket må i praksis ha tilgang til kodeverket og konstruere en måte å resolve oid'ene på en kodeverksserver. Det er kanskje mulig å definere opp et NamingSystem som beskriver for FHIR installasjonen hvordan kodeverket skal resolves lokalt. Da kan det også være en ide å bruke navnet på NamingSystem i lokale profiler forsåvidt.

[rockphotog]

Ja, "main issue" er egentlig at Volven er gammelt - og om vi bør gjøre noe ekstra for de Volven-kodeverk som finnes i basisprofiler og etter hvert områdeprofiler.

En relativt enkel terminologiserver-fasade foran Volven på kort sikt burde vært kjekt, men skal det være driftsikkerhet på den må vi involvere NHN - og ta det som den del av grunnmursarbeidet.

Kodeverk forvaltes fortsatt på Volven, selv om det er dratt inn i Healthterm (samtlige Volven-kodeverk er der samme kodesystem -- som nå da må være allerede utdatert).

[thomiz]

Main issue er vel fremdeles at ressursene vi har definert har en canonical som ikke havner noe sted slik at uansett hva vi gjør så får vi 404 på våre canonicals.

Det ville være enklere å lage statiske versjoner som distribueres via GitHub som hjelperessurser for validering av no-basis/områdeprofiler? Kan oppdateres med (ujevne) mellomrom når folk finner feil?
Communityoppgave?

I produksjon må uansett de som implementerer håndtere kodeverk på en mer robust måte.

En statisk versjon er antakelig en mer robust metode som krever mindre vedlikehold enn å spinne opp en uoffisiell terminologiserver?

Ser at HL7 i tyskland har fått mappet fhir.de domene til ressursinstanser på SIMPLIFIER slik at canonicals resolver dit.
Denne: http://fhir.de/ValueSet/versicherungsart-de-basis
Havner her: https://simplifier.net/Basisprofil-DE-R4/versicherungsart-de-basis-duplicate-2

[rockphotog]

Ja, litt script-greier, så hvem som helst kan dra ned og kjøre et "oppdater-value-sett-rett-fra-ssb"-skript og commite nytt ValueSet - under en slags "tools"-fane, så det ikke er normativt i seg selv. Potensielt eget repo - kanskje til og med en hel terminologiserver for forking/nedlasting. Snowstorm er jo f.eks. bare en fork av HAPI med "nokå innhold".

[kennethmyhra]

Slik vi gjorde det for DocumentReference og Composition ved å opprette et ValueSet. Referer vi til ValueSet i StructureDefinition og System i ressursen.

Slik jeg forstår Thomas så er det dette som menes med statiske versjoner?

EDIT: Men dette er kanskje ikke like rett frem når det kommer til identifiers

[rockphotog]

Note to self: ws.geonorge.no/kommuneinfo/v1/kommuner