FMK Teknik

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

Kære Alle

FMK Styregruppen har godkendt en central aktivering af Udvidet validering 10016 – Behandlingsslutdato på ATC J, P og S01A.

Plan
•   Valideringen idriftsættes tirsdag d. 12. marts 2024 kl. 10:00
•   Systemer der mener, at de ikke skal modtage valideringen kan kontakte AAGS@sundhedsdata.dk inden d. 1. marts 2024. Eksisterer en lignende validering i systemet, kan FMK
        valideringen slås fra.

Validering 10016

Besked: "Ordinationen på {DrugName} bør have en behandlingsslutdato."

Hvis det angivne lægemiddel på ordinationen har en af de valgte ATC-koder J, P og S01A. Så skal der på ordinationen angives en behandlingsslutdato, med mindre man aktivt vælger at overrule denne validering.

Baggrund
FMK kvalitetsstatistik har været særdeles bidragende til at konkretisere behovet for validering ved ingen behandlingsslutdato for ATC-gruppen J, P og S01A. Der har ved ordinationer med disse ATC-koder kun været taget stilling til behandlingsslutdato i 4,5% af tilfældene.
FMK idriftsatte denne validering i januar 2023 som anvendersystemer kunne vælge at implementere. Det opleves dog at systemleverandørerne ikke nødvendigvis implementerer disse gode tiltag blot fordi de er blevet udviklet og FMK klinisk brugergruppe efterspørger derfor, at det bliver et krav. Som sædvane kan parterne blive undtaget, såfremt denne validering allerede findes i deres system.
FMK kvalitetsstatistik vil fremadrettet følge hvor mange nye ordinationer der bliver oprettet med og uden behandlingsslutdato.

Mvh
Åse Grønborg Sørensen
Faglig koordinator Fælles Medicinkort

Hej Helle

fejlen vil typisk vise sig ved en fejlbesked der indeholder følgende besked:
"Certificate has an unknown CRL url: http://ca1.cti-gov.dk/oces/root/cri/root.crl".

Som vi ser fejlen, er den typisk permanent over en periode og forsvinder så igen i en periode. Vi taler typisk om en time eller mere hver gang.

Hvis det ikke matcher ovenstående beskrivelse, er det nok en god ide at lave en support sag :-).

Vh
Søren

Hvordan opleves fejlen?
Vi har igennem lang tid haft problemer med at tilgå Test2 og ved ikke om det skyldes en fejl hos jer eller en fejl hos os. Derfor vil vi gerne vide hvordan fejlen vises. Hos os er det ikke kun sporadisk men hele tiden - Måske skal jeg oprette en sag til jer i stedet
Mvh Helle

Hej Pia

ja, udd og prodtest miljøerne er også ramt af samme fejl.

Vh
Søren

Hej Søren, kan samme fejl give problemer for UDD miljøet?
Vi får fejl, når vi har angivet kode fra ID middel.

Der opleves p.t. sporadiske problemer med billetomveksling i test miljøerne.
Problemet ligger i efter alt at dømme i NSP STS komponenten og bliver behandlet af NSP teamet.

Hej Pia,
Der er ikke noget i vejen for fortsat at benytte den gamle dump/restore-klient. Det er de samme FMK/DDV dump/restore snitflader, der benyttes. Der er dog flere, der har haft problemer med at bruge den gamle klient, da den kræver en lokal java-installation, og ikke alle organisationer tillader dette.