Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Michael Berg

Pages: 1 2 [3] 4 5
31
DDV version 3.1.0 blev d. 4/1 2021 released til PROD.

Der er udelukkende tale om intern funktionalitet til understøttelse af den nationale COVID-19 vaccinationsindsats. Der er ingen fejlrettelser eller ny funktionalitet der påvirker anvendersystemerne.

På DDV teamets vegne,

Michael Berg



32
DDV version 3.0.29 er i dag released til produktion.

Der er tale om en mindre maintenance release med følgende indhold:
  • DDV-1375 - Udfør auditlogning og minlog registrering baseret på information fra Whitelisting headeren i stedet for SOSI ID kortet
  • DDV-1399 - Rettet fejl i håndtering af påmindelsesfravalg, der betød at barnets forældre i mange tilfælde blev påmindet i e-Boks på trods af et fravalg
  • DDV-1139 - Mindre justeringer i logning ifm. identifikation af brugerens organisation
På DDV teamets vegne,

Michael Berg

33
DDV version 3.0.29 er i dag released til TEST1 samt TEST2.

Der er tale om en mindre maintenance release med følgende indhold:
  • DDV-1375 - Ændre MinLog Organisation til OrgUsingName
  • DDV-1399 - Rettet fejl i håndtering af påmindelsesfravalg, der betød at barnets forældre i mange tilfælde blev påmindet i e-Boks på trods af et fravalg
  • DDV-1139 - Mindre justeringer i logning ifm. identifikation af brugerens organisation
På DDV teamets vegne,

Michael Berg

34
DDV / Enabling af detaljer i fejlende kald (prod)
« on: 2020-10-28 13:37:34 »
Kære alle,

Vi enabler i dag en feature i produktion der gør, at fejlende kald til DDV snitfladen vil returnere en del mere information om hvad der gik galt - herunder fejlkode samt et stacktrace der kan være nyttigt i forbindelse med eventuelle supporthenvendelser. Se følgende posting for en komplet beskrivelse af fejlrettelsen.

Det er tidligere forekommet at systemer har oplevet problemer i forbindelse med, at et response indholder flere elementer end tidligere. Det forventer vi ikke sker i denne omgang, men ellers hører vi naturligvis gerne om det via nspop.

35
DDV version 3.0.28 er i dag released til produktion. Vi kan i denne omgang byde på følgende:

Ny funktionalitet
  • Automatisk effektuering sker nu kun hvis barnet vaccineres højest tre måneder før den planlagte dato (DDV-1388)
  • Krav om minimumsalder og -intervaller slækkes så et "slip" på op til 4 dage tillades. Et barn der møder op 4 dage før sin 3-måneders fødselsdag betragtes således som 3 måneder gammel og vil derfor være kandidat til automatisk effektuering hvis lægen glemmer at gøre tingene på den rigtige måde. (DDV-1392)
  • I responses på fejlende kald returneres nu også den specifikke årsag (bl.a. fejlkode) til at kaldet fejlede (enables senere) (DDV-1387)
Rettelser
  • En fejl har forhindret læger i at effektuere anbefalede vaccinationer oprettet af ydere, der ikke længere er gyldige. Den fejl er nu rettet. (DDV-1390)
  • Rettet fejl der i visse tilfælde forhindrede autoeffektueringens regel 4 (DiTeKiPol revaccination/booster) i at træde i kraft.​ (DDV-1394)
God fornøjelse!

36
Det er en gentagende gene for vores support funktion, at de ikke i mindst testmiljø kan simulere drift, og jeg har efterspurgt det siden projektets start. FMK arbejder med drifts medicinstamdata (vist på nær UDD), og det gør support utroligt nemt.

Forskellen på FMK og DDV er i den sammenhæng at DDV føder stamdata mens FMK kun "forbruger" stamdata. Der findes således ikke nogen "test takst", der er kun den rigtige takst der også bruges i produktion. De miljøer der arbejder med taksten vil derfor altid afspejle produktionsdata og man vil derfor altid kunne finde de samme lægemidler i alle miljøer. Det er nyttigt i test- og supportsammenhæng det er vi helt enige i.

I DDV har vi til hvert miljø et særligt stamdatasæt som er etableret bl.a. med henblik på at kunne teste kode, der opretter, ændrer eller sletter stamdata. Hvis testmiljøerne arbejder med stamdatasættet fra produktion betyder det vi er nødt til at finde en ny arbejdsgang for at teste stamdatavedligehold.

Et andet problem er at der i testmiljøerne i dag findes en række kliniske data (vaccinationer, anbefalede vaccinationer m.v.) der henviser til stamdata der findes i netop dette miljø. Eksempelvis kan en vaccination henvise til en vaccine ved hjælp af en VaccineIdentifier som tilfældigvis ikke findes i stamdatasættet i produktion. Det betyder at vi ikke har mulighed for at udskifte stamdatasættet med det tilsvarende sæt fra produktion, idet dette vil blive blokeret af integritetskontrollen i databasen som bl.a. sikrer at der findes records til alle identifiers. En mulig løsning herpå er at vi simpelthen sletter alle vaccinationer og anbefalede vaccinationer i testmiljøerne og "starter forfra", men det kræver jo at I som leverandører er med på det.

Jeg vil prøve at spørge Åse Grønborg Sørensen fra SDS om emnet eventuelt kan blive vendt på det kommende teknikermøde d. 28/10.

37
Er test-miljøerne nogen sinde kommet over på et opdateret sæt stamdata?

Jeg kan se at der senest er sket indholdsopdateringer af vacciner på Test1 d. 31/8 i år. Ovenstående tilføjelse af Trivalent er derfor ikke sket endnu på testsystemerne.

Vaccinationsregistrets stamdatasæt vedligeholdes i de forskellige miljøer af Serum Instituttet, men da det kun sjældent forekommer at der er behov for at teste anvendersystemerne med specifikke vacciner prioriteres det ikke at holde testmiljøerne synkrone med produktion - hvis det er det du efterspørger.

Stamdata replikeringen kører hver 18. minut på Test1 og knap så ofte på Test2, dog mindst én gang i timen.

Hvis der er behov for at teste med specifikke vacciner eller hvis der på anden vis er uhensigtsmæssigheder i DDV stamdatasættet i testmiljøerne, så er det hurtigste nok at gå gennem supporten på nspop.dk.


38
Influenzasæsonen 2020/21 er i fuld gang og der er i klinikkerne derfor et øget behov for indberetning af influenzavaccinationer.

Der gives i år mange vaccinationer med Trivalent High Dose, og der er i den sammenhæng flere brugere, der oplever, at de ikke kan finde Trivalent når de søger på vaccinen i deres lægesystem. I stedet findes Fluzone, hvilket har givet anledning til en række supporthenvendelser til Serum Insitituttet, da brugeren ikke altid er klar over at der er tale om samme vaccine i to forskellige produkter.

For at afhjælpe dette problem har Serum Insituttet i fredags (d. 9/10) oprettet Trivalent som en selvstændig vaccine i DDV stamdatasættet, hvorfor produktet nu også burde dukke op i søgninger efter Trivalent. Det kræver dog at man i anvendersystemerne har replikeret stamdata siden i fredags.

I kan som leverandører hjælpe jeres brugere ved at sikre, at der sker en daglig replikering af DDV stamdatasættet. Dermed kan brugerne indberette influenzavaccinationer lettere, og presset på Serum Instituttets support reduceres.

Bemærk i denne sammenhæng følgende opsang fra Sundhedsdatastyrelsen d. 21/2 2020: http://www.fmk-teknik.dk/index.php?topic=1717.0

Ligeledes har det stor betydning at der anvendes et opdateret Stamdatasæt for vaccinationer. En daglig opdatering anbefales for alle anvendersystemer, og er et certificeringskrav fra og med snitfladeversion 1.4.0.E1.

39
Til orientering:

Som beskrevet i posting her på FMK Teknik d. 12/5 er der i DDV indført en automatik, der omsætter vaccinationsoprettelser til en effektueringer af anbefalede vaccinationer for børnevaccinationsprogrammet, når visse betingelser er opfyldt.

Regelsættet, der er besluttet af SSI, har haft en positiv effekt på antallet af anbefalede vaccinationer der fejlagtigt fremstår som ikke effektuerede, og en tilsvarende betydelig reduktion af vaccinationspåmindelser, der udsendes til forældrene på denne baggrund. Der er dog identificeret enkelte scenarier hvor reglerne utilsigtet effektuerer anbefalede vaccinationer, som barnet derfor ikke bliver indkaldt til senere. Det gælder specielt børn, der er tilmeldt 4-års vaccinationsprogrammet.

Derfor indfører SSI nu en generel justering af reglerne, idet en anbefalet vaccination kun effektueres automatisk såfremt den er planlagt indenfor de nærmeste 3 måneder. Hvis barnet dukker op hos lægen som 2-årig og modtager en MFR vaccination, så vil den anbefalede vaccination på MFR der ligger i 4-års programmet derfor ikke længere blive effektueret. Hvis barnet i stedet møder op hos lægen i en alder på 3 år og 9 måneder så vil MFR vaccinationen blive effektueret automatisk.

Bemærk at disse regler som tidligere nævnt er indført for at hjælpe sundhedsfaglige, der af forskellige årsager kommer til at oprette en ny vaccination i stedet for at effektuere en eksisterende, anbefalet vaccination. Der skal igen lyde en opfordring til leverandørene om at implementere tiltag i anvendersystemerne, der understøtter arbejdsgangen omkring vaccinationer i børnevaccinationsprogrammet. Dette kan eksempelvis gøres ved at tilføje advarsler når der oprettes vaccinationer med vacciner, der allerede indgår i et af borgerens tilknyttede vaccinationsforløb. Inspiration kan i denne sammenhæng hentes fra FMK Online.

Ændringerne er indført i DDV release 3.0.28, der p.t. findes på Test1. Release til produktion er ikke endelig fastlagt endnu, men vil formentlig ske indenfor de kommende 14 dage.

SSI vil i forbindelse med deres kommende nyhedsbrev orientere lægerne om ændringerne til den automatiske effektuering.


40
DDV / Retur af SOAP Faults fra DDV
« on: 2020-09-17 13:52:18 »
Kære alle,

Fejlende kald til DDV snitfladerne returnerer i dag et response med forholdsvis begrænsede detaljer om årsagen. For eksempel:

Code: [Select]
<SOAP-ENV:Body>
    <SOAP-ENV:Fault>
        <faultcode>SOAP-ENV:Server</faultcode>
        <faultstring xml:lang="en">Person med CPR-nr. 1234561111 kunne ikke findes!</faultstring>
    </SOAP-ENV:Fault>
</SOAP-ENV:Body>

DokuWiki findes en bruttoliste over hvilke fejl man kan få tilbage i forbindelse med kald til DDV. Hver fejl har sin egen fejlkode, som eksempelvis "4000   Person med CPR-nr. {0} kunne ikke findes!". Problemet er at koden "4000" ikke returneres i fejlsvaret. Der burde være et <detail> element inkluderet med oplysninger om fejlkoden og øvrige detaljer om årsagen, som det bl.a. kendes fra FMK. En fejl har dog indtil nu forhindret at dette element blev inkluderet i svaret.

Det retter vi nu op på, så det dermed bliver muligt at reagere på specifikke fejl uden at skulle parse fejlteksten. Et fejlende kald vil således returnere følgende volumiøse svar:

Code: [Select]
<SOAP-ENV:Body>
    <SOAP-ENV:Fault>
        <faultcode>SOAP-ENV:Client</faultcode>
        <faultstring xml:lang="en">Vaccinationsforløb kunne ikke findes!</faultstring>
        <detail>
            <medcom:FaultCode xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">VaccinationPlanNotFound</medcom:FaultCode>
            <ddv:errorcode xmlns:ddv="http://vaccinationsregister.dk/schemas/2010/07/01">4010</ddv:errorcode>
            <ddv:stacktrace xmlns:ddv="http://vaccinationsregister.dk/schemas/2010/07/01">
            dk.vaccinationsregister.ddvshared.shared.exceptions.ValidationException: Vaccinationsforløb kunne ikke findes!
            at dk.vaccinationsregister.server.services.commands.serverintern.GetVaccinationPlanForSubscriptionActionHandler.execute(GetVaccinationPlanForSubscriptionActionHandler.java:28)
            at dk.vaccinationsregister.server.services.commands.serverintern.GetVaccinationPlanForSubscriptionActionHandler.execute(GetVaccinationPlanForSubscriptionActionHandler.java:18)
            ...afkortet...
            at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
            at java.lang.Thread.run(Thread.java:748)</ddv:stacktrace>
        </detail>
    </SOAP-ENV:Fault>
</SOAP-ENV:Body>

Bemærk det nye <detail> element som indeholder både en errorcode samt en faultcode. Errorcode henviser her direkte til fejlkoderne, der er beskrevet på DokuWiki.

Der returneres også et stacktrace, som kan benyttes i forbindelse med oprettelse af supportsager. Det er ikke noget vi forventer blot noget der kan gøre fejlsøgning lidt lettere i visse situationer.

Grunden til denne serviceoplysning er, at vi tidligere har oplevet at anvendersystemer af forskellige årsager er løbet ind i problemer hvis responset indeholder elementer, der ikke tidligere har været sendt ud. Derfor håber vi at I vil være med til at teste funktionaliteten, som p.t. er enabled på Test1. I alle andre miljøer, herunder PROD, er funktionaliteten slået fra og her får man kun det "korte" fejlsvar tilbage.

Test kan eksempelvis udføres ved at lave opslag på personer der ikke findes (CPR nummer ikke fundet) ændring eller sletning af identifiers der ikke findes - osv. Verificer, at det nye <detail> element ikke har uønskede sideeffekter i jeres løsninger.

Hvis ikke der indløber protester så håber vi at kunne slå det udvidede fejl-respons til i produktion 1/10 2020.


41
DDV version 3.0.25 er i dag released til TEST1 samt TEST2.

Der er tale om en maintenance release der primært indeholder fejlrettelser og mindre forbedringer. Det handler for eksempel om:

  • Fjernelse af GWT kode der ikke længere er i brug
  • Forbedringer af logning samt error/retry-rubusthed i integrationen til e-Boks og Strålfors
  • En stribe rettelser til håndtering af historik på planlagte vaccinationer samt automatisk forløbstilskrivning
  • Klargøring til etablering af fuld historik på forløbstilknytninger
  • Dependency opdateringer aht stabilitet, sikkerhed og licensforhold​


Den fulde liste kan ses på nspop.dk, under 'FMK Releaseplan'.

42
Minihøringen er nu afsluttet. Der er ikke kommet indvendinger eller alternative forslag til den foreslåede løsning.

Vi sætter derfor opgaven klar til implementering snarest muligt.

43
DDV / Minihøring: Justering til DDV 1.4.0 extension E1
« on: 2020-05-12 12:33:18 »
I snitflade til DDV, 1.4.0 extension E1 er der med servicen GetUnsubscriptions mulighed for at hente en liste over borgerens fravalgte forløb. De fravalgte forløb returneres med et id og et navn, samt modifikatorstrukturer på opretter og indberetter af de enkelte forløbsfravalg.

Udover disse oplysninger er der ønske om også at få den årsagsangivelse, der eventuelt ligger til grund for fravalget, med retur. Det er ikke altid at årsagen er kendt da muligheden for at indberette en sådan først er indført i snitflade 1.4.0.E1, men i de tilfælde hvor den kendes kan det have klinisk relevans for lægen. Det giver derfor god mening at systemerne kan spørge på værdien.

Det der konkret foreslås er følgende:
  • Udvidelse af request til GetUnsubscriptions med en anmodningsindikation (<IncludeStatus/>), som tillægges den betydning, at systemet ønsker at få en status (årsag) returneret.
  • Udvidelse af svaret fra GetUnsubscriptions med en Status, svarende til den årsagsangivelse, der indberettes med fx. DeletePlannedVaccination. Værdien vil have minOccurs=0 og kun blive returneret når der anmodes om den, og hvis årsagen kendes.
Til orientering kan status p.t. antage føglende værdier:

Code: [Select]
<simpleType name="PredefinedPlannedVaccinationStatusType">
<restriction base="vaccinationcard20131201e1:UndefinedPlannedVaccinationStatusType">
<enumeration value="Planlagt"/>
<enumeration value="Effektueret"/>
<enumeration value="Fejlregistrering"/>
<enumeration value="Slettet på borgers anmodning"/>
<enumeration value="Slettet af lægefaglige årsager"/>
</restriction>
</simpleType>

Vær opmærksom på at request elementet til GetUnsubscriptions p.t. kun ligger i 1.4.0 snitfladen. Derfor vil ovenstående forslag teknisk set medføre ændringer i både 1.4.0 og 1.4.0.E1, selvom funktionaliteten spærres for anvendersystemer på 1.4.0 snitfladen.

Den foreslåede ændring kan gennemføres uden umdidelbare konsekvenser for nuværende anvendere af både 1.4.0 og 1.4.0.E1 snitfladerne. Ikke desto mindre hører vi selvfølgelig gerne forslag eller eventuelle forbehold omkring den foreslåede udvidelse.

Benyt gerne dette forum til at poste forbehold og øvrige tilkendegivelser. Der gives frist til slutningen af måneden (fredag d. 29/5) hvorefter ændringerne vil blive implementeret.

44
Der er nu tændt for automatisk effektuering af anbefalede vaccinationer på Test1.

Læs mere om funktionaliteten her og hvad I som leverandører kan gøre for at kvalitetssikre.

45
DDV / Automatisk effektuering af anbefalede vaccinationer
« on: 2020-05-12 10:08:42 »
I forbindelse med deployment af version 3.0.23 på Test1 og Test2, er der indført ny funktionalitet der i visse tilfælde vil omsætte en vaccinationsoprettelse til en effektuering af en anbefalet vaccination.

Baggrunden for den nye automatik skal findes i påmindelsesordningen til børnevaccinationsprogrammet, hvor borgere får besked i deres e-boks og NemSMS når anbefalede vaccinationer er nært forestående eller eventuelt overskredet i forhold til den planlagte vaccinationsdato. Påmindelserne udsendes med udgangspunkt i barnets anbefalede vaccinationer, og disse anbefalede vaccinationer er således centrale for påmindelsesordningen.

Desværre sker det ret ofte at en vaccination hos lægen ender med at den sundhedsfaglige opretter en enkeltstående vaccination i stedet for at effektuere den tilhørende, anbefalede vaccination som barnet har liggende. Dermed kan påmindelsesordningen ikke se at vaccinationen er givet, og vil derfor udsende en reaktiv påmindelse til forældrene efter 30 dage - med stort påstyr til følge naturligvis. Der er p.t. slukket for alle reaktive påmindelser af denne årsag.

Den ideelle løsning er selvfølgelig at leverandørerne gør det lettere for den sundhedsfaglige at "gøre det rigtigt", eventuelt ved at advare lægen om planlagte vaccinationer, på samme måde som FMK Online gør det. Indtil det sker indføres der nu funktionalitet i DDV, der efter specifikke regler automatisk omsætter vaccinationsoprettelser til effektueringer. Automatikken er med i release 3.0.23 der er deployed på Test1 og Test2.

Reglerne for automatisk effektuering er som beskrevet nedenfor:

Nr.HandlingAutomatik
1Der oprettes en DiTeKiPolHibHvis barnet er over 3 måneder kobles til den tidligste anbefalede vaccination af DiTeKiPolHib.
2Der oprettes en pneumokokvaccination konjugeret (PVC)Hvis barnet er over 3 måneder kobles til den tidligst anbefalede vaccination af pneumokokvaccination konjugeret
3Der oprettes en MFR vaccinationHvis barnet er 12 måneder eller derover kobles med den tidligst anbefalede MFR vaccination
4Der oprettes en DiteKiPol-revaccinationDer parres med en anbefalet DiTeKiPol revaccination hvis minimumsinterval til 3. Di-Te-Ki-Pol-Hib er overholdt (4 år)
5Der oprettes en HPV vaccinationHvis barnet er over 12 år parres den med den første anbefalede HPV vaccination

Sådan kan funktionaliteten testes

Konsekvensen bør være minimal for anvendersystemerne, men leverandørerne opfordres ikke desto mindre til at teste systemernes opførsel for at sikre, at brugerne ikke mødes af fejldialoger eller anden uhensigtsmæssig opførsel. Det er specielt i forhold til den uventede ændring i de anbefalede vaccinationer at systemerne bør afprøves. Følg nedenstående procedure:
  • I anvendersystemet åbnes vaccinationskortet for et barn - vælg et barn der er over 3md gammelt. Hvis barnet ikke allerede er tilmeldt børnevaccinationsprogrammet så gøres dette - benyt det program der på Test1 blot hedder "Børnevaccinationsprogrammet".
  • Kontroller at der på barnet ligger 11 anbefalede vaccinationer
  • Opret en vaccination på barnet, på DiTeKiPolHib.
I anvendersystemet bør der nu være en vaccination på DiTeKiPolHib (som normalt). Den bør dog fremstå som værende effektueret i børnevaccinationsprogrammet, hvilket er en konsekvens af den automatiske effektuering. Samtidig bør den første DiTeKiPolHib være forsvundet fra listen af anbefalede vaccinationer under børnevaccinationsprogrammet.

Skulle der ske alvorlige fejl i anvendersystemet så benyt som altid supportformularen på nspop. Funktionaliteten er på vej i produktion lige om lidt, så vi har selvfølgelig ekstra fokus på eventuelle henvendelser der omhandler den nye automatik.


Pages: 1 2 [3] 4 5