GLOO v4, PQ.unit obligatoriskt men enhet saknas i källsystemet
Issue #409
resolved
I GLOO v4 är PQ.unit obligatoriskt. För vissa provsvar saknas dock enhet i källsystemet, finns alltså enbart ett värde. Hur ska vi hantera detta fall? Samma problem gäller även IntervalPQ.
För jämförelse så är motsvarande fält i GLOO v3 (outcomeUnit) inte obligatoriskt. Finns det något skäl att detta ändrats till GLOO v4?
Reference.interval.unit är också obligatoriskt och ska hanteras på samma sätt som pq.unit och intervalPQ.unit. D.v.s. att elementet tillåts vara tomt, men måste anges eftersom det är obligatoriskt i schemat.
Comments (28)
-
-
Hej Daniel!
Första frågan är om det är en korrekt avsaknad av enhet eller inte? Det kan ju vara så att det är ett dimensionslöst mätvärde (exempelvis ett antal har ju ingen enhet). Det är ju inte lätt för er att lösa men i NPU-kodverket finns det en enhetsangivelse som är den korrekta enhet som labbet förväntas mäta i (t.ex mmol/liter) för att uppfylla kontraktets krav. Om det nu är så att de fall ni hittar där enhet saknas faktiskt inte ska ha någon enhet så är det inte mer komplicerat än att pq.unit anges som en tom sträng
-
reporter
Om vi returnerar en tom sträng i pq.unit så får vi dock fel i schemavalideringen (tomma fält är ju inte tillåtna). Och utelämnar vi fältet helt (som vi gör nu) så bryter vi också mot schemat pga att fältet är obligatoriskt.
-
reporter
Frågan om det är en korrekt avsaknad av information - där kan vi, som du säger, inte göra någonting på vår sida. Informationen i provsvaret kommer helt och hållet från labbet, och vi har ingen möjlighet att göra annat än att förhålla oss till informationen så som den ser ut.
-
Aha. Då skulle jag säga att det är fel i schemavalideringen, men jag måste dubbelkolla om varför det inte förekommit tomma enheter hittills. cc:ar dig på mail Daniel.
-
reporter
Jag utgick från att det kommer bli fel om vi returnerar en tom sträng, eftersom det inte tillåts någon annan stans (finns en generell regel att tomma element inte får förekomma). Har inte testat just det här. Men känns konstigt om det skulle vara tillåtet på just detta fält, men inte någon annanstans.
-
Jag har också som jag skrev i mailet en simpel lösning som är att vi utnyttjar ucum standarden och ni får ange enheten 1 i de fall då enhet saknas. Kräver dock en textuell förändring i tkb och att NPÖ/Journalen förstår att siffran 1 ska ersättas men tom sträng.
-
Man undrar vad det är för informatik-talibaner som inte tycker om tomma strängar
-
Jag är osäker på om att ange 1 i de fall enhet saknas är ett alternativ enligt arkitektursektionen. Vi har haft ett liknande fall nyss där domen blev att det inte är okej att göra på det sättet. Men vi kan ju invänta besked om schemavalideringen så kan vi ta det vidare därifrån.
-
Just för PQ.unit? Enligt specifikation är det tillåtet idag:
Dvs det står att man ska följa UCUM och den standarden säger explicit att 1 är en giltig dimensionslös enhet. Om det inte ska vara tillåtet måste defactosidan ändras, men det är lite konstigt att göra inskärningar på standarden.
-
Jaha, där ser man. Never mind
-
reporter
I nuläget går det att komma förbi problemet genom att returnera en tom sträng i PQ.unit. Att detta fungerar beror dock på en brist i kontrollen av tomma strängar, och borde inte vara tillåtet, jfr ärende
#410.Vi skulle kunna ange 1 som är ett giltigt värde, men kräver som konstaterades ovan att NPÖ/Journalen då behöver hantera det som ett specialfall.
Kan tycka att det mest rimliga vore att ändra kardinaliteten för PQ.unit till 0..1, eftersom det uppenbarligen ska kunna förekomma enhetslösa värden.
-
PQtype är dock baserade på våra de-factodatatyper varför dessa i så fall skulle behöva ändras också https://bitbucket.org/rivta-domains/best-practice/wiki/De facto-konventioner för datatyper.md#markdown-header-pqtype. Jag ska ta upp problematiken på vårt möte med TK-förvaltningen imorgon för att få inspel från resten av gruppen.
-
Hej! Håller inte med Daniel. Enligt UCUM-standarden och ISO 21090 är det ok med en tom sträng så det måste vara detta i PQ-typen också, precis som datatypen är definierad. En sån ändring i GLOO4 skulle också vara icke-bakåtkompatibel. Däremot borde man se till att CV_CV.code och codesystem inte är tomma strängar om de är angivna. Denna kontroll saknas i GLOO4 upptäckte Daniel.
-
reporter
Rättningen i ärende
#410gör att det inte kommer gå att ange tom sträng i PQ.unit. Det är en generell kontroll som tittar på tomma värden i samtliga fält i kontraktet.Blir lösningen då ändå att ange 1 som enhet i de här fallen?
-
@Torbjörn Dahlin ?
-
Vi diskuterar detta internt just nu. Jag återkommer när vi har något besked.
-
Här kommer besked från arkitektursektionen och Arvid Thunholm:
“UCUM ska följas och att då värdet 1 ska användas för mätvärden som saknar enhet. Sen bör aktuella tjänstekonsumenter notifieras om detta även om det står även dom fritt att läsa UCUM.”
Lösningen är således att ange 1.
-
- changed status to resolved
Se senaste kommentaren.
-
Hej igen Daniel,
Vi har fortsatt att diskutera detta och landat i att vi kommer tillåta tomma stränga för pq-unit i alla fall. Det innebär även att vi kommer inrätta schematronvalidering så att de inte går att skicka tomma strängar i övrigt.
Hälsningar,
Tobias
-
reporter
Jaha, så ni öppnar upp för tomma strängar bara för dessa fält specifikt då (både PQ och IntervalPQ)? Blir ju ett lite inkonsistent beteende mot alla andra tjänster, men men…
Innebär detta att ni kommer göra samma förändring för t.ex. GetObservations då (som ju också har PQ), dvs tillåta tomma enheter även där?
Om man tittar på TKB för GetObservations så pekar man ju där specifikt ut att man ska hämta enhet från kolumnen c/s i UCUM - men i den kolumnen finns såvitt jag kan se inte några tomma enheter någonstans, så det kanske inte är något problem i praktiken för GetObservations…
Tillbaka till GLOO4 - vilken kolumn i UCUM är det som det är tänkt att man ska använda för enheter i det kontraktet? Borde väl vara c/s även där? Och i så fall - var finns det i så fall något exempel där man har en tom enhet?
-
Ja det borde nog ändras för alla ställen där PQ används på sikt. Att tillåta tomma strängar är som sagt en anpassning till standarden som PQ-datatypen pekar på. När GetObservations togs fram så var vi helt enkelt inte tillräckligt pålästa på ucum.
I GLOO4 finns enheterna ihop med NPU-standarden. Det finns en pågående utredning hos Equalis för att titta på om det finns några skillnader mellan de enheter som är angivna och ucum och hur det ska hanteras men tillsvidare antar vi att de är ekvivalenta. För vissa labbanalyser är svaret enhetslöst och då skickas de enhetslösa ut via GLOO4.
När du implementerar så ska du alltså anta att det som kommer som enhet via labbsvaret kan klistras rakt in i PQ.unit. Det är labbets ansvar att skicka korrekta enheter.
Om det faller på dig att implementera ett labbsystem i Millenium också så är tilläggssvaret att nationellt är det korrekta sättet att använda NPU-kodverket för att representera analyser ihop respektive angiven enhet.
-
reporter
@Tobias Blomberg @Jan Söderman
Undantaget i constraints.xml som ska tillåta tomma strängar i unit-fältet fungerar inte korrekt. Schematron-assert:en i SoapUI failar fortfarande när unit är tom. Felet ligger i att man gör en kontroll av name()=”urn1:unit”, men värdet som returneras av name() är bara “unit”. Dessutom saknas motsvarande undantag för intervalPQ/unit i regeln - jag utgår från att samma regelverk måste gälla även för intervalPQ.
<iso:pattern id="Verify non-empty elements"> <iso:rule context="soapenv:Body/urn:GetLaboratoryOrderOutcomeResponse//*[not(name()='urn1:unit') or not(name(..)='urn1:pq')]"> <iso:assert test="normalize-space(.)">Element <iso:name/> is included but empty. All elements included in the response must have valid values.</iso:assert> </iso:rule> </iso:pattern>Följande regel borde fungera bättre (notera även “and” istället för “or” så man explicit kollar bara kombinationen pq/unit resp. intervalPQ/unit):
<iso:rule context="soapenv:Body/urn:GetLaboratoryOrderOutcomeResponse//*[not(name()='unit' and name(..)='pq') and not(name()='unit' and name(..)='intervalPQ')]">
-
- changed status to open
Jag öppnar ärendet igen eftersom det finns en del oklarheter fortfarande.
-
Jag har rättat constraints.xml för PQ enligt Daniels tips, men avvaktar beslut om intervalPQ ska behandlas på samma sätt:
<!-- No empty elements allowed except pq.unit --> <iso:pattern id="Verify non-empty elements"> <iso:rule context="urn:GetLaboratoryOrderOutcomeResponse//*[not(local-name()='unit' and local-name(..)='pq')]"> <iso:assert test="normalize-space(.)">Element <iso:name/> is included but empty. All elements included in the response must have valid values.</iso:assert> </iso:rule> </iso:pattern> -
- edited description
-
intervalPQ behandlas på samma sätt som PQ enl. anteckningen ovan. Ärendet stängs.
-
- changed status to resolved
- Log in to comment
Hej Daniel,
Jag ska höra med @Torbjörn Dahlin som är insatt i GLOO 4 om han kan svara på hur det resonerats kring detta.
/ Tobias Blomberg