Goddag,
Som en del af et større oprydnings-projekt internt i FMK har vi været igennem en større del af den funktionalitet som i øjeblikket er styret internt i FMK med properties, og som i øjeblikket ikke er aktiveret, fordi det i sin tid skabte problemer for et eller flere klientsystemer.
Dette er dog noget vi gerne vil i gang med at tænde for igen, og beder derfor alle leverandører af klient-systemer om nøje at læse de følgende 5 punkter igennem, da det typisk vedrører ældre funktionaliteter som vi meget gerne vil have lukket for.
Vi forventer at tænde for disse 5 funktionaliteter i Test1 og Test2 om 3 måneder, med henblik på at få dem i produktion 6 måneder herefter. Dette håber vi er en rimelig tidshorisont, for at alle klientsystemer har mulighed for at sikre sig mod at ændringerne lukker/ødelægger funktionalitet i jeres systemer.
Herunder beskrives de 5 funktionaliteter, hvad der præcis er tale om, og hvad der sker når vi tænder for funktionaliteten. I er velkomne til at stille spørgsmål hvis der skulle være uklarheder, idet nogle ting vil være ret tekniske i deres natur.
Edit: Funktionalitet forventes enablet i Test1+Test2 medio September 2020, Forventes enablet i produktion medio April 2021Edit 2: Funktionalitet 1, 3, 4 og 5 forventes enablet i produktion 15. April 2021. punkt 2 udskydes til medio Juni1: Fjernelse af “UseNewSuspension” fra response-header.UseNewSuspension er en property som er synlig i response-headerens’ konfigurationsangivelse:
https://wiki.fmk.netic.dk/doku.php?id=fmk:generel:konfigurations-angivelse_i_response_header.
NewSuspension blev oprettet i forbindelse med skiftet fra den gamle løsning med ”suspendering” af medicinkortet ved indlæggelse til den nuværende funktionalitet hvor medicinkortet markeres ”ikke ajourført”.
Denne property har været sat til værdien “True” igennem længere tid, og skal ikke ændres yderligere. Derfor mener vi også det vil være en god ide at fjerne denne funktionalitet helt, men det skal sikres at alle systemer som benytter sig af denne, ikke fejler/skifter tilbage til gammel funtionalitet pga. den ændringen. Alle systemer bør derfor sikre sig at de kan overleve at ”NewSuspension” vil mangle fra konfigurationsangivelsen, og at systemet stadig opfører sig, som om det antages at denne værdi altid vil være ”True” fremover.
Herunder et eksempel på hvordan denne værdi står i et af de nuværende svar fra FMK:
<medicinecard20150101:FMKConfigurationList xmlns:medicinecard20150101="http://www.dkma.dk/medicinecard/xml.schema/2015/01/01">
<medicinecard20150101:KeyValuePair>
<medicinecard20150101:Key>UseNewSuspension</medicinecard20150101:Key>
<medicinecard20150101:Value>true</medicinecard20150101:Value>
</medicinecard20150101:KeyValuePair>
<medicinecard20150101:KeyValuePair>
<medicinecard20150101:Key>PausePeriodEnabled</medicinecard20150101:Key>
<medicinecard20150101:Value>true</medicinecard20150101:Value>
</medicinecard20150101:KeyValuePair>
</medicinecard20150101:FMKConfigurationList>Det er altså det keyValue pair med UseNewSuspension, som vi ønsker at fjerne.
2. Validering mod ændring af behandlings-slut på udløbne ordinationer.Tilbage i 2015 indførte FMK en validering mod at brugeren rettede på behandlingsslut-datoen for ordinationer, hvor behandlings-slut allerede var overskredet. Dette skabte dog problemer for flere systemer, og valideringen blev herefter slukket indtil systemerne kunne håndtere fejlen. Valideringen har desværre været glemt længe, og derfor mener vi også det er på høje tide at vi får sat gang i den igen.
Hvordan fungerer valideringen? Ved forsøg på at ændre behandlingsslut-datoen tjekker FMK, om den nuværende slut-dato ligger i fortiden. Hvis dette er tilfældet vil FMK fejle og returne en fejlkode med nummer 425. Bemærk at dette kan være fordi ordinationen er blot er udløbet som normalt, eller hvis den er blevet seponeret. Det vil stadig være muligt at af-seponere ordination, hvilket vil genoprette den tidligere slutdato. Bemærk dog at hvis denne også er udløbet, vil der stadig ikke kunne ændres på denne herefter.
Det anses generelt som en fejl at lægen ”genopliver” ordinationen som allerede er udløbet, frem for at gøre det rigtige og oprette en ny behandling (ny ordination). Dette vil FMK nu gerne forsøge at tage hånd om.
Når vi tænder for funktionaliteten vil alle fremtidige kald til opdatering at lægemiddelordinationen, hvor der ændres på behandlings-slutdatoen efter denne er udløbet, fejle. Brugeren vil få en fejl 425 der fortæller, at deres ændring af behandlingsslut-datoen ikke er gyldig.
Vi opfordrer samtidig til, at alle systemer indfører en upfront validering til at hjælpe lægen med i stedet at oprette en ny behandling.
3. Ændring i fejl-response namespaceI forbindelse med FMK’s oprydning af 1.4.0 snitfladen, fandt vi en fejl i hvordan FMK valgte namespaces for fejl-responses. Dette gjorde at alle namespaces til og med 1.4.4.E1 valgte namespacet for 1.4.0 snitfladen, hvorimod alle fra 1.4.4.E2 og opefter fik namespacet fra den snitflade servicen var kaldt på.
Dette er noget vi gerne vil have rettet op på, og gøre tingene lidt mere robuste overfor eventuelle fremtidige extensions. Vores ændring gik derfor ud på at man ændrede namespacet til det nærmest namespace som ikke var en extension. Dvs 1.4.4E1,E2,E4,E5 ville alle sammen have namespacet 1.4.4 i deres fejl-response (mere præcis værdien
http://www.dkma.dk/medicinecard/xml.schema/2015/01/01) , det samme gælder 1.4.6 og extensions hertil.
Et eksempel på en fejl som det vil se ud på 1.4.6.E3 snitfladen.
<soapenv:Fault>
<faultcode>soapenv:Client</faultcode>
<faultstring xml:lang="en">SOME ERROR</faultstring>
<detail>
<medcom:FaultCode>555</medcom:FaultCode>
<medicinecard20150601E3:FaultText xmlns:medicinecard20150601E3="http://www.dkma.dk/medicinecard/xml.schema/2015/06/01/E3">SOME TEXT</medicinecard20150601E3:FaultText>
<medicinecard20150601E3:FaultDetails xmlns:medicinecard20150601E3="http://www.dkma.dk/medicinecard/xml.schema/2015/06/01/E3">
<medicinecard20150601E3:KeyValueSet>
<medicinecard20150601E3:Key>ElementPath</medicinecard20150601E3:Key>
<medicinecard20150601E3:Value>XXX</medicinecard20150601E3:Value>
</medicinecard20150601E3:KeyValueSet>
<medicinecard20150601E3:KeyValueSet>
….
</medicinecard20150601E3:KeyValueSet>
</medicinecard20150601E3:FaultDetails>
</detail>
</soapenv:Fault>Når vi tænder for funktionaliteten vil 1.4.6.E3 blive reduceret til 1.4.6 basis snitfladen, og response vil derfor indholde følgende namespaces i stedet.
<soapenv:Fault>
<faultcode>soapenv:Client</faultcode>
<faultstring xml:lang="en">SOME ERROR</faultstring>
<detail>
<medcom:FaultCode>555</medcom:FaultCode>
<medicinecard20150601:FaultText xmlns:medicinecard20150601="http://www.dkma.dk/medicinecard/xml.schema/2015/06/01">SOME TEXT</medicinecard20150601:FaultText>
<medicinecard20150601:FaultDetails xmlns:medicinecard20150601="http://www.dkma.dk/medicinecard/xml.schema/2015/06/01">
<medicinecard20150601:KeyValueSet>
<medicinecard20150601:Key>ElementPath</medicinecard20150601:Key>
<medicinecard20150601:Value>XXX</medicinecard20150601:Value>
</medicinecard20150601:KeyValueSet>
<medicinecard20150601:KeyValueSet>
….
</medicinecard20150601:KeyValueSet>
</medicinecard20150601:FaultDetails>
</detail>
</soapenv:Fault>Det anbefales at systemerne gør sig uafhængige af hvilket namespace et eventuelt fejl-svar kommer tilbage i, hvor muligt, eventuelt lave håndtering at begge tilfælde indtil alt er sikret i produktion.
4. Fjern mulighed for at benytte gammelt OnBehalfOf-Namespace.Assistenter til læger har typisk ikke samme rettigheder som lægen, men kan stadig udføre dele af en læges arbejde på vegne af lægen. Dette er også beskrevet på dokuwiki:
https://wiki.fmk.netic.dk/doku.php?id=fmk:generel:aktorer_pa_fmk. Når dette gøres benyttes OnBehalfOf i headeren på et request. I forbindelse med oprydningen af 1.4.0 snitfladen slettede vi også muligheden for at benytte dette og 1.4.2’s namespaces for OnBehalfOf elementet. Dette fandt vi dog ud af nogle systemer stadig benytter, og vi indførte derfor en midlertidig løsning således at man stadig kunne benytte disse gamle namespaces.
For at færdiggøre fjernelsen af de gamle fmk-sniftflader mangler vi dog at kunne fjerne denne funktionalitet, og vi beder derfor alle som stadig benytter OnBehalfOf med enten 1.4.0 eller 1.4.2’s namespaces til at benytte 1.4.4’s namespace i stedet.
Når vi fjerner muligheden for at benytte disse gamle namespaces i OnBehalfOf elementet, vil alle som overtræder dette fremover få en fejl med fejlkode 4003, og beskeden ”Sosi xml fejl: Fejl i OnBehalfOfElement”.
5. Validering mod angivelse af ordinationsid på opret recept i forbindelse med oprettelse af lægemiddelordination.Vi har i FMK igennem længere tid observeret, at flere systemer ser ud til at sætte et ordinations-id på et opret-recept element, selv om dette opret-recept element er bundet sammen med et opret lægemiddelordination’s element. Dette er en fejlagtig anvendelse, som FMK i øjeblikket løser ved at fjerne ordinations-id’et igen. Her kan der dog skjule sig en potentiel fejl, hvor klientsystemet har placeret opret-recept elementet forkert, og det var meningen at recepten skulle oprettes på en anden ordination.
FMK indførte derfor en ikke aktiveret validering, hvor der dengang blev gjort opmærksom på, at dette var et problem vi håbede klientsystemerne ville få løst, således at FMK kunne aktivere valideringen. Vi har dog holdt øje med hvordan dette udviklede sig, men kunne ikke se en tilstrækkelig ændring til, at vi følte det var sikkert at aktivere valideringen uden videre.
Et eksempel kunne være (namespace fjernet):
<CreateDrugMedicationRequest>
<PersonIdentifier>00000000</PersonIdentifier>
<MedicineCardVersion>1</MedicineCardVersion>
<CreatedBy>
….
</CreatedBy>
<DrugMedication>
<BeginEndDate>
..
</BeginEndDate>
<Indication>
..
</Indication>
<RouteOfAdministration>
..
</RouteOfAdministration>
<Drug>
...
</Drug>
<Dosage>
..
</Dosage>
<SubstitutionAllowed>true</SubstitutionAllowed>
<CreatePrescriptionMedication>
<DrugMedicationIdentifier>111111</DrugMedicationIdentifier>
...
</CreatePrescriptionMedication>
<ReimbursementClause>klausulbetingelse opfyldt</ReimbursementClause>
</DrugMedication>
</CreateDrugMedicationRequest>Et DrugMedicationIdentifier element burde slet ikke indsættes i dette tilfælde. Når valideringen aktiveres vil FMK fremover returnere en fejlkode 474, hvis dette sker.
Show Posts