GLOO4, oklarhet kring kodverk för body/type
Issue #404
resolved
I GLOO4 specificeras att body/type ska använda codeSystem 2.16.840.1.113883.4.642.3.230, med vilket man rimligtvis syftar på följande: Valueset-diagnostic-report-status - FHIR v3.0.2 (hl7.org). I senare FHIR-versioner (4.0.1) har kodverket ersatts av följande: Valueset-diagnostic-report-status - FHIR v4.0.1 (hl7.org) och då fått en ändrad OID 2.16.840.1.113883.4.642.3.235. Detta är inget problem i sig.
Däremot så verkar den ursprungliga OID:en från FHIR v3.0.2 ha återanvänts för ett helt annat kodverk i FHIR v4.0.1. OID 2.16.840.1.113883.4.642.3.230 pekar därför i v4.0.1 istället på följande kodverk: Valueset-repository-type - FHIR v4.0.1 (hl7.org), som har ett helt annat innehåll och syfte.
Det här är ett problem som egentligen helt ligger i FHIR-specifikationen, men det gör ändå gör att det formellt sett blir väldigt otydligt vilket kodverk som faktiskt avses (även om man givetvis kan inse att det är v3-versionen som avses). Men det kan kanske vara lämpligt att förtydliga detta i tjänstekontraktet, exempelvis genom att tydligt beskriva vilken version som avses. Alternativt att man i tjänstekontraktet ändrar till oid för kodverk enligt FHIR v4.0.1, eller tillåter att båda kodverken används.
Comments (9)
-
-
-
assigned issue to
Tobias Blomberg
-
assigned issue to
-
reporter
Så detta innebär att vi i vår implementation bör returnera v4-oiden istället? Dvs 2.16.840.1.113883.4.642.3.235.
-
Måste återkomma. Ska höra med NPÖ/Journalen först om de kan hantera det i nästa release.
-
@Rikard Edgren Vill du kommentera detta ärende också? Vårt förslag är att om ni i er implementation validerar OID justerar ni till att tillåta både
2.16.840.1.113883.4.642.3.235
och
OID 2.16.840.1.113883.4.642.3.230
från producenter.
Specifikationen ändras till att peka på 2.16.840.1.113883.4.642.3.235 för producenter, men Gävleborg returnerar i dagsläget .230
-
Jag tror inte det ska vara något problem, men dubbelkollar med systemleverantören.
Generellt sett så validerar inte Journalen/NPÖ “allt” i kontraktet, utan ser bara till att man har det man måste ha för att kunna visa informationen (om man hade nolltolerans på både schema- och schematronvalidering, så skulle mycket data försvinna).
-
Därmed inte sagt att man inte ska följa schema och schematron, men erfarenheten visar att det är svårt att vara 100%-ig i alla situationer där data ska prodceras.
-
Det följer vår allmänna policy. Vi är stränga mot producenter men uppmanar konsumenter att vara förlåtande mot producentproblem i de fall det är möjligt.
-
- changed status to resolved
OIDen uppdateras i version 4.0.1 an kontraktet
- Log in to comment
Bra hittat Daniel. Olyckligt att vi tittade på v3 när vi tog OID:en. Misstänker att det gick fort och att det inte fanns någon misstanke om att den skulle ha rättats till v4. Jag tror att vi försöker rätta den här också till v4 OIDen. Betyder att jag måste be Gävleborg att uppdatera också, men det undviker problem på sikt tror jag.