Hurtig minihøring vedr. skemavalideringsfejl

[Ulrik Skyt]

I FMK opleves i øjeblikket visse skemavalideringsfejl, som opstår internt i FMK når der genereres responses ud fra receptdata.
Vi arbejder på højtryk med at lave et hotfix, men vil gerne forsøge parallelt at indsamle kommentarer til de løsninger vi
har tænkt os at implementere. Hvis nogen synes, at en anden løsning ville være bedre hører vi meget gerne fra Jer.

IndicationCode '000000' hvor IndicationCodeType kræver værdier mellem 1-9999999.

Der er tilfælde hvor receptdata indeholder en indikationskode '000000', hvilket ikke er en tilladt værdi i skemaet.
I tilfælde hvor feltet er valgfrit vil vi udelade feltet.
I tilfælde hvor feltet er obligatorisk vil værdien '9999999' blive anvendt i stedet.

HospitalOrganisationIdentifier som ikke har formatet '[0-9A-Z]{4}|[0-9A-Z]{6}|[0-9A-Z]{7}'

Der er tilfælde hvor receptdata indeholde identifiers som ikke er valide SKS koder.
I tilfælde hvor feltet er valgfrit vil vi udelade feltet.
I tilfælde hvor feltet er obligatorisk vil værdien 'ZZZZ' blive anvendt i stedet.

ContactName blev fundet hvor StreetName eller PseudoAddress var forventet.

Dette er sandsynligvis en fejl i FMK's skemadefinition af DeliveryStructureType, hvor en choice mellem
StreetName og PseudoAddress burde have været valgfri og i stedet er blevet obligatorisk. I receptserverens
tilsvarende definition af Delivery er den tilsvarende choice valgfri.

Hvis vi mangler en adresse skrives "Ingen adresse" i PseudoAddress.

TelephoneNumberIdentifier som ikke har formatet '(\+)?[0-9]{3,20}'

Der forekommer telefonnumre som ikke umiddelbart har dette format, fx "12345678/1234" eller "12 34 56 78".
Først fjernes spaces (dette er ikke nyt). Hvis et prefix af det angivne telefonnummeret derefter har et korrekt format anvendes dette som telefonnummer.
Fx bliver "12345678/1234" til "12345678".
Hvis man ikke kan udlede et korrekt telefonnumer udelades feltet, hvis det er valgfrit, og ellers anvendes "000000".

ReceiptDosageText er længere end de 70 tilladte tegn

Når teksten er for lang trunkeret den til 70 tegn, som ender med "...".


PriceListVersionDate som ikke er på formatet for PriceListVersionDateType

Dette skyldes en forkert navngivet takstversion, og vi vil tage op med PEM Support hvordan der bedst kan rettes op på det.

FreeTradePackageSizeText fundet hvor PackageNumerIdentifier var forventet

Dette problem skal undersøges nøje. Pakkenummeret er essentielt for en recept. Hvis det ikke findes
er der noget rigtig galt. Vi bliver nødt til at vide hvor problemet ligger og hvis det er på
receptserveren må de rette op på denne mangel.

[Tom Arleth - CompuGroupMedical]

Hejsa.

Jeg synes alle de forslåede tiltag er fine. Jeg vil bare lige slå til lyd for at der under alle omstændigheder bliver sendt et medicinkort i stedet for kun at sende en fejlbesked (jeg får de beskrevne fejl i forbindelse med GetMedicineCard.) Så må fejlen komme med som en advarsel eller lign - fx i PrescriptionServerError feltet.

[Ulrik Skyt]

Vi kommer ikke til at sende medicinkort XML ud som ikke lever op til skema-definitionerne!
Det ville I som brugere af interfacet heller ikke kunne leve med.

Men det er selvfølgelig ikke acceptabelt, at der kommer skemavalideringsfejl "indefra" når et response skal genereres.

Det er en problemstilling som skal håndteres, så det ikke kommer til at ske.

[Tom Arleth - CompuGroupMedical]

Nej selvfølgeligt skal I ikke sende noget ud som ikke skemavaliderer, det var ikke det jeg mente.

Det jeg mente var at èn recept, der ikke validerer, ikke må spærre for at hele medicinkortet med alle dets ordinationer og andre recepter bliver sendt. Dem vil jeg have sammen med en advarsel om at der var noget I ikke kunne sende pga skemavalideringsfejl.

[aoerbaek]

Hej,

Sådan rent teknisk er det da fine løsningsforslag, men det ville være rart, hvis I i en sådan udmelding forsikrer om, at løsningerne er godkendt af klinikere, LMS, "medicinpoliti" og andre parter, der har mere end syntaksmæssige holdninger. Bare lige to eksempler:

Eksempel 1. Trunkering af receptdoseringsteksten:
Præcis den anførte trunkering er IKKE acceptabel i forbindelse med oprettelse af en recept ud fra en lægemiddelordination da MEGET vigtig data kan blive skåret af. (her refererer jeg bla. til en snak vi havde i forbindelse med certificering, hvor vi snakkede om defaultudfyldning af receptdoseringsfeltet).
Derfor kan det undre mig, at det er godt nok her, hvor brugere f.eks. skal bruge data fra en recept og oprette ordination ud fra det. Hvis de i den situation kun kan se halvdelen af doseringen er det bare ikke godt nok og muligvis værre end hvis de f.eks. så "dosering efter skriftlig anvisning".
Men igen - hvis det er godkendt af nogen, der har forstand på det og ikke bare af os teknikere, så er jeg helt med på den.

Eksempel 2. IndicationCode 000000 erstattes med 9999999:
Igen helt ok forslag, hvis det kan garanteres, at 9999999 aldrig vil blive brugt til noget, der gør, at indikationskoden kan blive misforstået.

Mvh. Astrid