FMK oprydning: Genetablering af slukkede validering og anden funktionalitet

[Steven A. Sørensen]

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 2021

Edit 2: Funktionalitet 1, 3, 4 og 5 forventes enablet i produktion 15. April 2021. punkt 2 udskydes til medio Juni

1: 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:

Code Select Expand

<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 namespace
I 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.

Code Select Expand

<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.

Code Select Expand

<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):

Code Select Expand

<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.

[tpendlet]

Goddag,

For #5, does this new validation only apply to CreateDrugMedicationRequest messages?  For instance, will this also apply if there is a CreatePrescriptionMedication within a CreateDrugMedication element?  Is it okay to include the DrugMedicationIdentifier if a CreatePrescriptionMedication is sent without a create drug element?

Thanks,
Tiffany Pendleton

[Steven A. Sørensen]

Goddag,

For #5, does this new validation only apply to CreateDrugMedicationRequest messages?  For instance, will this also apply if there is a CreatePrescriptionMedication within a CreateDrugMedication element?  Is it okay to include the DrugMedicationIdentifier if a CreatePrescriptionMedication is sent without a create drug element?

Thanks,
Tiffany Pendleton

Hi Tiffany,

That's correct, this only applies when creating a new drugmedication, when doing so it's possible to at the same time create a prescription for this new DM. Howeever we have observed some systems also set a DrugMedicationIdentifier within the CreatePrescriptionMedication element when creating a new DM, which doesn't make sense since the DM hasen't been created yet (and therefore doesn't have an identifier yet). So currently FMK is removing the DrugMedicationIdentifier, but we'd rather see this also be resolves on the opposite end, to avoid this causing confusion.

Best regards,
Steven A. Sørensen, Trifork.

[HSKRegH]

Hej Steven
Tak for oplysningerne vedr. ovenstående funktionalitet.
Jeg har fået tilbagemelding fra vores leverandør af klientsystem som oplyser at de kan levere løsning for ovenstående med implementering til produktion April 2021. Det håber jeg der kan tages hensyn til.

Venlig hilsen

Henrik Kristensen
Application coordinator
+45 29422631

Center for It, Medico og Telefoni
Sektion Medicin - FMK

Borgervænget 7
2100 København Ø
Hovednummer Tlf: 38 64 80 00
Web: www.regionh.dk

[Steven A. Sørensen]

Hej Steven
Tak for oplysningerne vedr. ovenstående funktionalitet.
Jeg har fået tilbagemelding fra vores leverandør af klientsystem som oplyser at de kan levere løsning for ovenstående med implementering til produktion April 2021. Det håber jeg der kan tages hensyn til.

Venlig hilsen

Henrik Kristensen
Application coordinator
+45 29422631

Center for It, Medico og Telefoni
Sektion Medicin - FMK

Borgervænget 7
2100 København Ø
Hovednummer Tlf: 38 64 80 00
Web: www.regionh.dk

Hej Henrik,

Syntes det er lidt trist, men vi kan sagtens efterkomme det ønske.
For at være på den sikre side, er der tale om start eller udgangen af April 2021?

Mvh,
Steven A. Sørensen, Trifork.

[HSKRegH]

Hej Steven
Vores udviklingshorisont er normalt 18 måneder på ændringer der vedrører brugergrænsefladen. Valideringen mod ændring af behandlings-slut, kræver ændring af vores ordinationsbillede. Vi har lagt os i selen for at få ændringen til produktion hurtigst muligt, men der er mange hensyn. Dels er det feriesæson, der skal allokeres tid til klinisk validering, der er hensyn til release managements planlagte opgraderingsvinduer, osv. Jeg var stolt af at vi kun overskrider den udstukne tidshorisont med én måned.
Der er tale om start April, med forbehold for uforudsete hændelse.

Venlig hilsen
Henrik Kristensen

[Steven A. Sørensen]

Hej Steven
Vores udviklingshorisont er normalt 18 måneder på ændringer der vedrører brugergrænsefladen. Valideringen mod ændring af behandlings-slut, kræver ændring af vores ordinationsbillede. Vi har lagt os i selen for at få ændringen til produktion hurtigst muligt, men der er mange hensyn. Dels er det feriesæson, der skal allokeres tid til klinisk validering, der er hensyn til release managements planlagte opgraderingsvinduer, osv. Jeg var stolt af at vi kun overskrider den udstukne tidshorisont med én måned.
Der er tale om start April, med forbehold for uforudsete hændelse.

Venlig hilsen
Henrik Kristensen

Hej Henrik,

Det er noteret, vi udskyder enabling af alle de overstående funktioner til medio April for en sikkerheds skyld.

Mvh,
Steven A. Sørensen, Trifork.

[Steven A. Sørensen]

Edit: Funktionalitet forventes enablet i Test1+Test2 medio September 2020, Forventes enablet i produktion medio April 2021

Til info tændes der for de nævnte funktionaliteter kl 15:00 idag (14-09-2020) i Test1 og Test2.

Mvh,
Steven A. Sørensen, Trifork.

[Steven A. Sørensen]

Funktionaliteten er nu tændt i Test1 og Test2

Mvh,
Steven A. Sørensen, Trifork.

[Steven A. Sørensen]

Mulighed for at benytte gammelt OnBehalfOf-Namespace (Punkt 4) er blevet reintroduceret i Test1 og Test2 efter ønske fra det sidste system vi umildbart kan se benyttede sig af det.

Det forventes at vi fjerner muligheden igen i midt december, efter aftale med det pågældende system.

Skulle der være spørgsmål til dette, eller andet, er i velkommene til at skrive enten her i tråden eller en besked direkte til mig.

[Steven A. Sørensen]

Goddag,

Da vi nu er ved at nærmes os medio April, kommer der her en opdatering.

Efter feedback fra klient-systemerne har vi fået go for punkt 1, 3, 4 og 5. Så disse vil blive aktiveret i produktionen efter planen den 15. April med mindre vi hører andet.

Punkt 2: "Validering mod ændring af behandlings-slut på udløbne ordinationer." udestår for nu, da vi har fået tilkendegivet at enkelte systemer endnu ikke er helt på plads med en understøttelse af dette, så aktiveringen af denne udskydes i første omgang til medio Juni

Mvh,
Steven A. Sørensen, Trifork.

[Steven A. Sørensen]

Goddag,

Punkt 1, 3, 4 og 5 er nu aktiveret i produktion. Vi holder øje med situationen.

Mvh,
Steven A. Sørensen, Trifork.

[Steven A. Sørensen]

Goddag,

Da vi endnu ikke har fået grønt lys fra alle klient-systemer omkring punkt 2, udskydes den til Medio August, hvis vi får grønt lys før dette tidspunkt vil det blive udmeldt her.

Mvh,
Steven A. Sørensen, Trifork.

[Claus Hemberg Jørgensen]

Alle klientsystemer har nu givet grønt lys til, at vi kan aktivere valideringen mod ændring af behandlingsslut på udløbne ordinationer (pkt. 2 i listen). Aktiveringen vil foregå i løbet af onsdag den 18. august 2021.

Mvh
FMK Teamet