FMK Teknik

FMK-Online i Test1 og Test2 er opdateret til version 3.35.5.

Denne release indeholder en række mindre fejlrettelser og forbedringer

Fejlrettelser

FMKO-468 Overlap af tekster i LMO-detaljer
FMKO-479 Kald til FMB fejler ved specifikke pausetidspunkter
FMKO-481 Receptens gyldighedsdato i FMK-online
FMKO-485 Fejl ved redigering af lægemidler uden behandlingsstart
FMKO-486 Fjern ubrugt FMKU-modul fra FMK-Online
FMKO-487 Behandlingsperiode slutdato opdateres ikke med startdato-værdi
FMKO-492 Fejlbesked om 0 i feltet gives først efter forsøg på oprettelse af ordinationen
FMKO-501 Ansættelsessted fastholdes ved skift imellem apoteksrolle og autorisationsbaseret rolle
FMKO-503 Infotekst vedr. Forældremyndighed, værge og fuldmagt nævner NemID - bør være MitID
FMKO-505 Tilbageknap i Opret LMO wizard mangler enabling
FMKO-506 Effektueringsdato/tid ved ekspedition af recept (apoteker) gemmes/sendes ikke
FMKO-508 Valideringen af Dosis-tidspunkt i avanceret dosering vises for tidligt
FMKO-513 Remotelogging skal angive encoding
FMKO-514 Oprettelse af flere recepter på samme ordination - både DD og alm. recepter
FMKO-515 Nyoprettet recept vises ikke/oprettes ikke
FMKO-516 Medhjælpstype bliver ikke korrekt overført ved sikker browseropstart
FMKO-523 Optimering af minimumsdatoer i datofelter
FMKO-528 Advarsel vedr. ukendt organisation ved SBO-login genindføres
FMKO-536 Burgermenuen scroller ikke med
FMKO-538 Bedre baggrundsfarve når mus holdes over uvalgt tab
FMKO-541 Behandlingsstartdato sættes til d.d. efter aktivering af ukendt start
FMKO-542 Medtag logning af stacktrace ved exceptions
FMKO-545 ASCP00139749 Dosering kan ikke vælges for Dicloxacillin
FMKO-559 Det er ikke muligt at indsætte behandlingsslutdato på VKA ordination

Forbedringer

FMKO-98 Påsætning eller rettelse af en behandlingsslutdato i FMK-online kræver stillingtagen til DD-recept
FMKO-390 Tilpasning af tekst for medicinkort med lutter privatmarkerede LMO'er
FMKO-406 Skal dosisdispenseres checkbox skal være på Trin 1
FMKO-412 Trin 3 dosering - ændring næste rulle eller akut
FMKO-480 FMB opdateringer
FMKO-482 Receptens gyldighedsslutdato i FMK-online
FMKO-483 Opdater gammel dependency til fmk-online-bem-api
FMKO-489 SBO login: Tag rolle fra idkort, hvis SBO parameter requestedRole ikke er sat
FMKO-494 Indførsel af max-værdi for opstarts/justeringsskema i VKA
FMKO-499 Fjern check af CVR-relation for apoteks-brugere fra frontend
FMKO-510 Forbedring af advarselstekst ved VKA-ordinationer
FMKO-512 Kalenderen for valg af kontroldato skal kun være åbne for fremtidige dage
FMKO-526 Byg med Java 17 som compile target
FMKO-529 Sorter info panelerne i lægemiddel oversigten efter alvorlighed
FMKO-554 Håndter at STS nu returnerer status kode 500 ved fejl


På FMK-klient teamets vegne
/Ole Bak Jensen

Ovennævnte validering er nu aktiveret i hhv. test1, test2 og udd.

Mvh FMK Teamet

TEST2 Opdateret

DDV i TEST2-miljøet er i dag opdateret og kører nu med ovenstående feature enabled.
Hvis der opleves problemer eller udfordringer med de berigede responses, hører vi naturligvis stadig gerne fra jer.

På DDV teamets vegne
Pierre Jakobsen

Kære Alle

Som forberedelse til central aktivering af udvidet validering 10016, Behandlingsslutdato på ATC J01, P01 og S01A i produktion d. 12. marts 2024 aktiveres denne validering i testmiljøerne d. 5. marts 2024 kl. 10.

De systemer, der har bedt om undtagelse for denne validering i produktion, vil få den samme opsætning i testmiljøerne.

Læs evt. mere her,https://www.fmk-teknik.dk/index.php?topic=2328.0 

På vegne af FMK-teamet.
Åse Grønborg Sørensen
Faglig koordinator, Fæles Medicinkort

FMK opdateres i dag mandag den 04.03.2024 til version 1.4.6.62.f. Opdateringen foretages uden nedetid.

Opdateringen indeholder kun en opgradering af interne tekniske komponenter, d.v.s. der er ingen funktionelle ændringer.

Mvh FMK Teamet

Der har fra anvendersystemer været fremsat ønske om, at visse stamdata-informationer blev inkluderet i diverse responses, eftersom snitflade-skemaet rent faktisk tillod disse detaljer.
Featuren blev udviklet før pandemien og har levet et stille liv på NSP TEST1, hvor den har været aktiveret gennem længere tid. Ændringen efterspørges stadig, derfor fortsættes udrulningen nu.

Berigelsen af responses påvirker i princippet alle services, som returnerer svar med elementer af typen "VaccinationType" (namespace=http://vaccinationsregister.dk/schemas/2013/12/01).
Dvs. svar fra både  læse- og skrive-services er berørt:

• GetVaccinationCard
• GetVaccinationCardIfUpdated
• GetVaccinationHistory
• CreatePreviousVaccination
• CreateVaccination
• DeleteVaccination
• EffectuatePlannedVaccination
• MultiUpdate
• UpdateVaccination

Hvad er ændret?
Den ekstra stamdataberigelse omfatter tilføjelse af følgende elementer:

• Information om "Indikation/forebyggelse mod" ("Disease")
• Søgeord tilknyttet vaccinen ("VaccineKeywordsText")

Derudover returneres information fra den seneste opdatering/version af de enkelte DDV stamdata elementer. Det er begrænset, hvor stor impact dette har på response-xml'en, da selve strukturen ikke ændres. Derimod vil indholdsmæssige/tekstuelle rettelser kunne forekomme.
Se herunder for eksempler på begge ændringer.

Eksempler
For teknisk illustration af ændringerne henvises til de to vedhæftede XML-filer med response fra "GetVaccinationCard"-servicen, hvor TEST1-response.xml er med de ekstra berigelser, mens TEST2-response.xml er uden.
Mest signifikant er nok tilføjelsen af `Disease` element(er):

<ns2:Disease>
  <ns2:DiseaseIdentifier>10</ns2:DiseaseIdentifier>
  <ns2:DiseaseName>Tetanus</ns2:DiseaseName>
  <ns2:DiseaseNameDK>Stivkrampe</ns2:DiseaseNameDK>
  <ns2:ATC>
    <ns2:Code>J07AM</ns2:Code>
    <ns2:Text>Tetanus vacciner</ns2:Text>
  </ns2:ATC>
</ns2:Disease>
<ns2:Disease>
  <ns2:DiseaseIdentifier>4</ns2:DiseaseIdentifier>
  <ns2:DiseaseName>Diphteria</ns2:DiseaseName>
  <ns2:DiseaseNameDK>Difteri</ns2:DiseaseNameDK>
  <ns2:ATC>
    <ns2:Code>J07AF</ns2:Code>
    <ns2:Text>Difteri vacciner</ns2:Text>
  </ns2:ATC>
</ns2:Disease>

^{Snippet fra TEST1-response.xml}

Ændring til udlæsning af nyeste stamdata bliver bla. synlig, når ATC-klassifikationen ændres efter registrering af vaccination.
Covid-vaccinerne er eksempler herpå:

<ns2:GetVaccinationCardResponse xmlns:ns2="http://vaccinationsregister.dk/schemas/2013/12/01">
<ns2:Vaccination>
    ...
   <ns2:Vaccine>
     <ns2:VaccineIdentifier>32115518136</ns2:VaccineIdentifier>
     <ns2:VaccineName>Moderna/Spikevax Covid-19 0,5 ml</ns2:VaccineName>
      ...
     <ns2:ATC>
       <ns2:Code>J07BN01</ns2:Code>
       <ns2:Text>Covid-19, rna-baseret vaccine</ns2:Text>
     </ns2:ATC>
   </ns2:Vaccine>
    ...
</ns2:Vaccination>
<ns2:Vaccination>
    ...
   <ns2:Vaccine>
     <ns2:VaccineIdentifier>32115517138</ns2:VaccineIdentifier>
     <ns2:VaccineName>Comirnaty Covid-19 vaccine</ns2:VaccineName>
      ...
     <ns2:ATC>
       <ns2:Code>J07BX03</ns2:Code>
       <ns2:Text>Covid-19 vacciner</ns2:Text>
     </ns2:ATC>
   </ns2:Vaccine>
    ...
</ns2:Vaccination>
</ns2:GetVaccinationCardResponse>

^{Snippet fra TEST1 - (ATCKode var på oprettelsestidspunkt "J07BX" for begge vacciner)}

<ns2:GetVaccinationCardResponse xmlns:ns2="http://vaccinationsregister.dk/schemas/2013/12/01">
<ns2:Vaccination>
    ...
   <ns2:Vaccine>
     <ns2:VaccineIdentifier>32115580980</ns2:VaccineIdentifier>
     <ns2:VaccineName>Pfizer BioNTech Covid-19 vacc</ns2:VaccineName>
     <ns2:ATC>
       <ns2:Code>J07BX</ns2:Code>
       <ns2:Text>Andre virale vacciner</ns2:Text>
     </ns2:ATC>
   </ns2:Vaccine>
    ...
</ns2:Vaccination>
<ns2:Vaccination>
    ...
   <ns2:Vaccine>
     <ns2:VaccineIdentifier>32115580981</ns2:VaccineIdentifier>
     <ns2:VaccineName>Comirnaty Covid-19 vaccine</ns2:VaccineName>
     <ns2:ATC>
       <ns2:Code>J07BX</ns2:Code>
       <ns2:Text>Andre virale vacciner</ns2:Text>
     </ns2:ATC>
   </ns2:Vaccine>
    ...
</ns2:Vaccination>
</ns2:GetVaccinationCardResponse>

^{Snippet fra TEST2 - (ATCKode var på oprettelsestidspunkt "J07BX" for begge vacciner og er det fortsat ved udlæsning)}

BEMÆRK Der er intet krav om, at anvendersystemerne viser de ekstra detaljer om stamdata, og opslag i replikerede og aktuelle DDV stamdata anbefales fortsat jvf. certificeringskravene.
De berigede data stilles således til rådighed for anvendersystemer, der midlertidigt ikke har adgang til replikerede stamdata.

Tidsplan
Den beskrevne feature har hidtil kun været aktiveret i NSP TEST1.
Opdatering af de enkelte DDV miljøer forventes at følge nedenstående plan:

• NSP TEST2: I løbet af uge 10 2024
• NSP STAGE+PROD: I starten af uge 16 2024
• NSP UDD+PRODTEST: Kort efter PROD

De berigede svar overholder fortsat DDV-snitfladens schema-definitioner. Vi opfordrer alligevel til, at alle leverandører verificerer, at ændringen ikke har nogle uventede sideeffekter i de pågældende systemer.
Opleves der problemer med behandling af det berigede svar, så meld gerne tilbage hurtigst muligt. Enten som reply på denne post eller ved at melde en support-sag ind på NSPOP.

På DDV teamets vegne
Pierre Jakobsen

FMK opdateres i dag onsdag den 28.02.2024 til version 1.4.6.62.e i produktionsmiljøet. Opdateringen foregår uden nedetid.

For listen over ændringer i denne version henvises til releaseplanen: https://www.nspop.dk/display/Web3/Trifork+FMK+Releaseplan

Mvh FMK Teamet

På mandag d. 4. marts slår vi validering af indre modifikatorer til i prod. Den har været slået til i test-systemerne i et par måneder.

Det betyder at modifikatorer på underelementer af UpdateMedicineCardRequest og UpdateDrugMedicationRequest fremover vil blive valideret efter samme regler som modifikatorer på det overordnede element. F.eks. vil der blive valideret at organisationen er en valid organisation af den angivne type og at det angivne autorisations-id er et validt autorisations-id.

Mvh FMK Teamet

Hej Claus

Det er fint at I indfører en parameter, så anvendersystemet kan foretage en filtrering. Men som standard bør en sådan ændring ikke resultere i en ændret opførsel. Jeg forventer ikke at vores brug bliver påvirket, men udfra teksten kan det ikke afgøres med sikkerhed. Hvis I vender funktionaliteten, så parameteren skal angives eksplicit for at undge kontakter på døde patienter, har vi ingen indvendiger.

Mvh
Claus Åge Breuerbach / Systematic

Der er indkommet et forslag til en mindre ændring af servicen GetPatientOrganisationRelations som blev indført i FMK 1.4.4.E5 for at give mulighed for at hente lister over patient relationer knyttet til en given organisation. Se https://wiki.fmk-teknik.dk/doku.php?id=fmk:extensions:hent_patientrelationer_for_organisation for yderligere detaljer om denne service.

Som servicen er i dag, returneres alle relationer uden hensyntagen til patientens CPR status, d.v.s. der returneres også relationer for afdøde patienter i op til 2 år efter dødsdagen, hvorefter relationen vil blive slettet. Vil vil gerne indføre en ny optionel parameter til kaldet der gør, at kalderen kan afgøre, om relationer hørende til afdøde personer inkluderes i søgeresultatet eller filtreres fra. Vi foreslår desuden, at hvis den nye parameter udelades, er default værdien, at der kun returneres relationer for leverende personer. Bemærk at denne default opførsel vil være en ændring i forhold til den eksisterende service.

Vi indbyder hermed alle interessenter til at kommentere på ovenstående ændring inden fredag den 8. marts 2024. Hvis vi ikke inden denne dato har modtaget indsigelser med blokerende argumenter mod ændringerne, vil implementationen herefter blive igangsat og senere udrullet i de respektive miljøer.

Mvh FMK Teamet