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.


Topics - Michael Berg

Pages: 1 2 [3] 4
31
Info omkring FMK produktion / Ny version af DDV (3.1.0) på produktion (udført)
« on: 2021-01-12 16:32:25 »
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
Info omkring FMK produktion / Release af DDV 3.0.29 til produktion (udført)
« on: 2020-11-04 16:13:10 »
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
Fælles test- og uddannelsesmiljøer / Ny version af DDV (3.0.29) på TEST1 og TEST2 (udført)
« on: 2020-11-03 10:01:45 »
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
Info omkring FMK produktion / Release af DDV 3.0.28 til produktion (udført)
« on: 2020-10-21 13:14:17 »
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
DDV / Indberetning af Trivalent High Dose influenzavaccination
« on: 2020-10-12 12:57:09 »
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.

37
DDV / Justering af automatisk effektuering af anbefalede vaccinationer
« on: 2020-09-24 12:38:10 »
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.


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

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


39
Fælles test- og uddannelsesmiljøer / Ny version af DDV (3.0.25) på TEST1 og TEST2 (udført)
« on: 2020-06-22 15:27:42 »
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'.

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

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


42
Fælles test- og uddannelsesmiljøer / Ny version af DDV (3.0.21) på TEST1 og TEST2 (udført)
« on: 2020-02-18 12:57:32 »
DDV version 3.0.21 er i dag released til TEST1 og TEST2.

Releasen giver bl.a. behandlerfarmaceuter adgang til DDV, hvilket ikke tidligere har været muligt. Derudover fejlrettelser, bl.a. til påmindelsesudsendelsen.

Den fulde oversigt over indholdet i releasen kan ses på nspop.dk, under 'FMK Releaseplan'.

43
DDV / Minihøring: Ny service til hentning af påmindelsesfravalg
« on: 2020-02-12 15:12:25 »
Der er i DDV snitflade 1.4.0.E1 indført en service med navnet GetNotificationUnsubscriptions, der giver lægen mulighed for at forespørge på en borgers aktuelle påmindelsesfravalg - det vil sige, om borgeren ønsker at modtage vaccinationspåmindelser i sin e-Boks og på NemSMS.

Servicen tager borgerens CPR nummer og returnerer et ja/nej svar, som indikerer det aktuelle fravalg. I relation til børn omfatter fravalget implicit også forældrene.

Servicen er senere justeret, så der også kan forespørges på indiviuelle modtagere. Hermed kan forældrene have hver sin præference ift. vaccinationspåmindelser.

Som servicen er udformet lægges der op til en arbejdsgang, hvor lægen slår op på barnet for at administrere påmindelsesfravalg. Dette kan dog medføre uhensigtsmæssige MinLog registreringer, hvis eksempelvis den fraskilte forælder sidder i konsultation hos lægen og beder om ikke at modtage vaccinationspåmindelser om et fælles barn. Her kan lægens opslag på barnet medføre en MinLog registering på den anden forælder. Samtidig er der mulighed for at lægen fejlagtigt kommer til at slå påmindelser fra for begge forældre, eftersom de i lægesystemet sandsynligvis optræder i en samlet liste.

Det er derfor besluttet at DDV skal tilbyde en service, der returner hvilke børn en forælder har et påmindelsesfravalg for. På den måde understøttes en alternativ arbejdsgang, hvor lægen slår op på forældren i stedet for barnet.

Det er teknisk set muligt for anvendersysterne at implementere tilsvarende funktionalitet ved at hente barn-forælder relationer fra stamdata, og via kald til den nuværende service for hver af børnene at identificere, om forældren har et påmindelsesfravalg for dette barn. Men dette medfører mange servicekald og en uforholdsmæssig tung logik på klientsiden, og da DDV jo er kendetegnet ved at være smidig, hurtig og en fornøjelse at kode op imod, så tilbyder vi selvfølgelig en ny service til formålet - det manglede bare.

Eftersom der formelt set er tale om en ændring af snitfladen afholdes derfor en minihøring hvor leverandører og andre interessenter har mulighed for at gøre opmærksom på eventuelle problemer og fremsætte ændringsønsker til det foreslåede. Da der er tale om en ny service er der ingen konsekvenser for nuværende anvendere af E1 snitfladen. Der er ligeledes heller ikke krav om recertificering.

Vi forestiller os at servicen vil have følgende request og response udformning:

Service navn: GetRecipientNotificationUnsubscriptions

Request

Code: [Select]
<sequence>
<element name="RecipientPersonIdentifier" type="cpr:PersonCivilRegistrationIdentifierType" />
</sequence>
Response
   
Code: [Select]
<element name="RecipientPersonIdentifier" type="cpr:PersonCivilRegistrationIdentifierType" />
<element name="Unsubscription" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="Created" type="vaccinationcard20131201:CreatedType"/>
<element name="PersonIdentifier" type="cpr:PersonCivilRegistrationIdentifierType" minOccurs="0"/>
</sequence>
</complexType>
</element>
Servicen ligner meget den aktuelle service men tager udgangspunkt i modtageren og ikke borgeren selv (barnet).

Kommentarer og ændringsforslag modtages gerne i høringsperioden, som løber fra dags dato frem til udgangen af februar (fredag d. 28/2 2020).

44
DDV / Minihøring vedr. justeringer til DDV 1.4.0 extension E1
« on: 2019-08-30 15:12:24 »
Den nyeste snitflade til DDV, 1.4.0 extension E1 tilføjer services, der gør det muligt for anvendersystemer at oprette og slette påmindelsesfravalg – det vil sige at tilgodese ønsker fra borgere om ikke at modtage vaccinationspåmindelser i deres e-Boks.

Snitfladens ibrugtagning af bl.a. FMK Online har imidlertid identificeret et behov for at kunne præcisere påmindelsesfravalg i forhold til forældre og børn. I dag gælder et påmindelsesfravalg begge barnets forældre, og det er således ikke muligt at etablere et fravalg der kun gælder én forælder. Der er udarbejdet et løsningsforslag, der via en justering i snitfladen gør det muligt at oprette, hente og slette påmindelsesfravalg for en individuel forælder/værge, gældende for individuelle børn. Ændringerne implementeres på en måde så de ikke påvirker de anvendersystemer, der allerede har taget extension E1 i brug. Der er ikke planlagt nye certificeringskrav i relation til det udvidede påmindelsesfravalg.

Udover påmindelsesfravalget er der ønske om en forbedring i forhold til hentning af forløbsfravalg. I snitflade 1.4.0 kaldes GetUnsubscriptions således for at hente en liste over aktuelle forløbsfravalg, men i svaret er det ikke muligt at se hvem der har oprettet fravalget. Det foreslås derfor at servicen introduceres i 1.4.0.E1, med et udvidet response, der returnerer en modifikatorstruktur med opretteren. Anvendersystemer, der benytter 1.4.0, vil ikke opleve nogen ændringer, og de systemer, der har taget extension E1 I brug, kan tage den nye service I brug efter behov. Der medfølger ikke nye certificeringskrav i relation til modifikator på forløbsfravalg (selvom systemerne selvfølgelig opfordres til at vise informationen hvis den er tilgængelig).

Denne minihøring har til formål at afdække om der blandt leverandørerne er et ønske om at henlægge de beskrevne justeringer til en ny extension E2, eller om vi kan indføre ændringerne som beskrevet ovenfor, i den eksisterende extension E1. Benyt gerne dette forum til at poste forbehold og øvrige tilkendegivelser.

På DDV teamets vegne,

Michael Berg

45
Fælles test- og uddannelsesmiljøer / Ny version af DDV (3.0.10) på TEST1
« on: 2019-03-07 15:57:41 »
DDV teamet har i dag fornøjelsen af at kunne annoncere version 3.0.10 på TEST1.

Denne release indeholder mindre rettelser og interne forbedringer, herunder bl.a.:

    * [DDV-986] Datoer for planlagte vaccinationer genberegnes ikke altid korrekt
    * [DDV-1036] Påmindelser: PDF design justeringer
    * [DDV-1077] Påmindelser: Afsender i e-boks fremstår nu som Statens Serum Institut
    * [DDV-1069] DumpRestore: Delvis manglende support for InternalPersonId (cpr-skift/juridisk kønsskifte)
    * [DDV-1078] Opgradering af Spring fra 3.1.x til 3.2.x

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

På DDV teamets vegne,

Michael berg

Pages: 1 2 [3] 4