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

2
DDV / Ændring af Audience på DDV IDWS snitfladen
« on: 2019-01-30 15:39:48 »
I forbindelse med anvendelse af DDV IDWS snitfladen har det været sådan at anvendersystemer skulle specificere https://fmk som Audience i AudienceRestriction delen i IDWS headeren, som vist i eksemplet her:

    ...
    <saml2:Conditions NotBefore="2014-09-21T19:57:15.309Z" NotOnOrAfter="2014-09-22T03:57:15.309Z">
        <saml2:AudienceRestriction>
            <saml2:Audience>https://fmk</saml2:Audience>
        </saml2:AudienceRestriction>
    </saml2:Conditions>
    ...

Det er besluttet at kald til DDV fremover skal ske med audience https://ddv. Anvendersystemer bør derfor sikre sig følgende:
  • Anvendersystemer der benytter STS til billetomveksling og udstedelse af IDWS security tokens skal whitelistes til anvendelse af https://ddv som Audience. Proceduren er at man opretter en supporthenvendelse via formularen på nspop.dk (https://www.nspop.dk/display/resources/Supporthenvendelse). Vælg forretningsservice STS.
  • Nødvendige kodemæssige ændringer, så kald sker med https://ddv som Audience.
Valideringen aktiveres i første omgang på Test1, hvilket vil ske i løbet af denne uge. Dermed bliver det muligt at teste eventuelle rettelser op imod Test1.

Information om aktivering på Test2 og i Prod meldes ud på et senere tidspunkt.


3
DDV / Administration af whitelisting for DDV på Test1
« on: 2019-01-17 16:13:54 »
Der er indført en række forbedringer og opstramninger i forhold til whitelisting af systemer på DDV. Ændringerne er i første omgang slået til på Test1, og kan for enkelte anvendersystemer medføre at requests bliver afvist på grund af manglende systemautorisation.

Problemerne vil som hovedregel kunne løses ved at logge på FMK Online på Test1 med en bruger der har administrative rettigheder, og verificere anvendersystemets whitelistings ("Administration" knappen). Det er som noget nyt nemlig blevet muligt også at tilføje DDV systemer her. Hvis denne indsats mod forventning ikke løser problemerne bør der oprettes en supportsag på nspop.dk.

Opstramningerne at whitelisting reglerne vil blive aktiveret på Test2 primo februar, og det er samme opskrift her hvis der skulle opstå problemer.

I forhold til produktion vil der de kommende uger være en dialog med leverandørerne, så vi sikrer at ingen lukkes ude når ændringerne træder i kraft.

På DDV teamets vegne,

Michael Berg

4
DDV / Lav trafik på testsystemerne
« on: 2019-01-14 10:42:41 »
Vi er i DDV teamet opmærksomme på at der på testsystemerne generelt, og på Test1 i isærdeleshed, er meget lidt trafik fra anvendersystemerne.

Test1 er første trappetrin på vej mod produktion, og vores første mulighed for at identificere problemer med en ny release. Samtidig er det jeres første chance som leverandører og slutbrugere for at teste ny funktionalitet samt verificere at supportsager er løst som forventet og uden utilsigtede følgefejl.

Det er derfor vigtigt at testsystemerne modtager trafik fra anvendersystemerne så vi bliver opmærksomme på eventuelle problemer så tidligt som muligt. Dette kunne for eksempel ske via automatiske integrationstests eller ved at inddrage vaccinationsregistret når der alligevel testes FMK funktionalitet - i det omfang det er muligt.

Så hermed et opråb om, at vi hjælper hinanden med at holde testserverne varme - til gavn for alle.

På DDV teamets vegne,

Michael Berg


5
Ved angivelse af doseringsenhed på en dosering anvendes UnitText(s) elementet (af typen DosageQuantityUnitText(s)Type). Elementet giver mulighed for at angive en kilde (source) samt en dato:
  • <UnitText source="Doseringsforslag">stk</UnitText>
  • <UnitText source="Medicinpriser" date="2016-10-01">stk</UnitText>
  • <UnitText source="Local">grønne plastbægre</UnitText>
Elementets indhold er ikke en reference eller en kode, men blot en tekstuel værdi hvor enheden angives direkte. Klientsystemerne er altså ikke indbyrdes afhængige af at kunne slå værdien op i stamdata eller andre registre, og derfor er source og date attributterne i praksis ikke nødvendige.

FMK kunne i princippet bruge værdierne til at validere indsendte data, men da klientsystemerne typisk har valgt at eksponere feltet som fritekst sker dette ikke, da da lægen ikke skal afvises blot fordi hun skriver "styk" i stedet for "stk". Det er derfor besluttet at udfase source og date attributterne på <UnitText> og <UnitTexts> elementerne. Denne ændring implementeres Extension E2 og nyere snitflader (1.4.4.E2 samt 1.4.6.E2 p.t.).

På tidligere snitflader er det endvidere besluttet at returnere værdien Local i source attributten, samt at udelade datoen, uagtet hvad klientsystemet oprindeligt har indsendt. Begrundelsen herfor er at man alligevel ikke kan stole på, at elementets værdi kan henføres til den angivne source, da den som beskrevet ovenfor i praksis bør fortolkes som ikke-valideret fritekst.

Det vil blive annonceret senere hvornår ændringen kan testes på testsystemerne.

Klientsystemer der af forskellige årsager gør brug af source attributten på UnitText(s) elementer bør allerede nu undersøge om ændringen får uhensigtsmæssige konsekvenser og i givet fald indmelde dette snarest muligt.

Med venlig hilsen

FMK-teamet


6
Hej,

Skema- og wsdl filer med de varslede rettelser ift dosisdispensering, privatmarkering på ordinationer og recepter, IsInvalid på GetNewOrders og ReportedBy på recepter er nu tilgængelige på Github.

Der er tale om version 1.4.4.16 og filerne kan downloades fra GitHub her.

Med venlig hilsen
FMK Teamet

7
Hej,

Det har vist sig nødvendigt med endnu et par ændringer i 1.4.6. snitfladen. Ændringerne er nødvendige for at gøre apoteksleverandørerne i stand til at leve op til certificeringskravene:
  • I svaret fra GetNewOrders tilføjes pr. patient et element IsInvalid, der indikerer om patientens medicinkort er markeret ugyldigt og derfor kan indeholde fejlagtige data.
  • I svar fra services, der returnerer recepter, vil Prescription elementet nu inkludere et IsPrivatePrescription hvis den tilhørende lægemiddelordination er privatmarkeret af patienten.
Derudover strømlines navngivningen i forhold til privatmarkering af recepter og ordinationer:
  • I DrugMedication strukturen omdøbes HasNegativeConsent elementet til IsPrivateDrugMedication
  • I services GetMedicineCard, GetDrugMedication, SearchEffectuations samt SearchWithdrawnDrugMedications omdøbes response elementet DrugMedicationWithNegativeConsent til PrivateDrugMedication
Skemaændringerne vil blive publiceret snarest muligt.

Med venlig hilsen
FMK Teamet

8
Hej Lisbet,

Enig, anvendelsen af deadline vil blive beskrevet på dokuWiki.

Vi afventer lige om der kommer reaktioner på udmeldingen her, og publicerer derefter WSDL filerne snarest muligt.

Mvh Michael

9
Efter dialog med forskellige parter omkring funktionaliteten i 1.4.6, og specifikt omkring den nye dosiskort funktionalitet, foreslås følgende justeringer i skemaerne til 1.4.6 snitfladen:
  • Der indføres et ReportedBy element på apoteksudleveringer (i lighed med øvrige elementer i FMK snitfladen). Dette sker af hensyn til arbejdsgange hvor apoteksudleveringer opsamles i en periode og derefter sendes ind af en enkelt apoteksansat.
  • Ved indrapportering af DD udleveringer udgår feltet ProductionDay. Feltet er vurderet til ikke at have nogen reel praktisk betydning i FMK sammenhæng.
  • Til gengæld indføres et Deadline felt til indrapportering af DD udleveringer. Feltet anvendes for den aktuelle DD periode til at indmelde den dato hvor indholdet i dosisrullerne blev fastlåst eller forventes fastlåst, og dermed hvilken deadline lægen skal betragte som seneste dato for ændringer i ordinationer til dosisdispensering.
  • Felterne ExpectedFirstDosageDate/ExpectedLastDosageDate omdøbes til FirstDosageDate/LastDosageDate, idet disse fremover også tænkes anvendt ved indrapporteringer i forhold til den aktuelle DD doseringsperiode.
  • DoseDispensing feltet i DoseDispensedType omdøbes til CurrentDoseDispensing og suppleres af et nyt felt ved navn NextDoseDispensing i forbindelse med ekspedition. Feltet benyttes til indrapportering af forventninger til den næste dosisperiode. Eks. Deadline er vigtig at få indberettet allerede på dette tidspunkt.
Ændringerne forventes implementeret og gjort tilgængelige med FMK release 1.4.4.16, der er planlagt til release på Test1 i starten af januar 2017.

Venligst meld hurtigt tilbage hvis I har indvendinger til disse ændringer.

Med venlig hilsen
FMK-teamet

10
Hej Tom, mange tak for vedhæftningen.

Det giver os lige et par nye opgaver kan jeg se.. :-)

11
Hej Ellen,

Er der mulighed for at vi kan få et preview af den nye version af doseringsenhederne?

Med venlig hilsen

Michael Berg
Developer, Healthcare | CGI Denmark
Margrethepladsen 4, 8000 Aarhus C | Danmark | www.cgi.dk

Pages: [1]