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 - Steven A. Sørensen

Pages: 1 [2] 3 4
16
Ekstraordinært  er receptmodulet i dag 19-05-2022 blevet opdateret til version 1.38.9.

Der er tale om et hotfix release

Liste over ændringer findes her: https://www.nspop.dk/display/Web3/Trifork+FMK+Releaseplan

Mvh
FMK Teamet

17
Jvf. releaseplanen er receptmodulet i dag 11-05-2022 blevet opdateret til version 1.38.6.

Liste over ændringer findes her: https://www.nspop.dk/display/Web3/Trifork+FMK+Releaseplan

Mvh
FMK Teamet

18
Version 1.38.6 af receptmodulet deployes på test1 og test2 d.d.

Følgende rettelse er indeholdt:
- FMK-7166 Lukning af recepter under behandling skal ske 5 dage efter udløb
- FMK-7182 AbortEffectuation reetablerer ikke bestilling
- FMK-7207 ReceptModul, Bedre validering i "Opret effektuering på recept" (ASCP00133364)

Udrulningsplanen kan ses på https://www.nspop.dk/display/Web3/Trifork+FMK+Releaseplan

19
Kære alle,

I mange år har man kunne hente en PDF udgave af medicinkortet fra FMK. Denne har altid være tiltænkt en udskrift til patienten, således at denne kunne få et overblik over hans/hendes medicin.
Når PDF'en bliver dannet hos FMK indeholder den derfor et lille stykke java-script kode, som hos de fleste systemer automatisk skal åbne vinduet omkring udskrift, når dokumentet åbnes.

I de senere år er der dog blevet fundet flere og flere problemer med indlejret javascript i PDF-dokumenter, og mange af de standard programmer som benyttes til at åbne PDFer med er begyndt automatisk at blokere for det. At systemet automatisk har blokeret for java-script kan så i sig selv give problemer, hvis ikke brugeren får mulighed for at navigere videre i dokumentet.

Vi har sammen med SDS derfor taget det valg at det fremover vil være bedre at FMK får fjernet det lille stykke javascript kode fra medicinkort pdf'en.

Dette vil have den indflydelse at de systemer/programmer hvor javascript er accepteret, vil der ikke længere automatisk blive vist vinduet omkring udskrift når dokumentet åbes.
Til gengæld vil det give en bedre understøttelse af PDF'en hos de systemer/programmer hvor javascript ikke er understøtte eller er blokeret som standard. Dette gælder bl.a. også mindre devices såsom tablets og smartphones (hvor udskrift normalt ikke er en mulighed).

I første omgang fjernes javascript fra medicinkort PDF'en på Test1 og Test2. Dette gøres fra i dag (17-1-2022).
Efter en ikke nærmere fastsat periode fjernes javascript fra medicinkort PDF'en i PROD, det kan i først omgang forventes omkring medio 2022.

Systemer som typisk anvender PDF'en bør i denne periode sikre sig at dette ikke har en større negativ effekt på deres system. Vi forventer ikke der bør være de store problemer, men skulle der mod forventning være store konsekvenser hos et eller flere systemer, hører vi gerne fra jer, da det kan have indflydelse på hvornår det endeligt skal slippes løs i produktion.

Siden her opdateres løbende når vi kommer tættere på en fastsat deadline for fjernelsen i produktion.

Mvh,
FMK Teamet

Edit: Indsat korrekt dato

20
Kære alle,

Vi gør opmærksom på at der i Minlog er en grænse på 25 tegn for system-navnet. Så hvis jeres system ønsker at få et kaldenavn til Minlog, må det højest være på 25 tegn, alt herover vil blive skrabet væk hos Minlog.

Mvh,
FMK teamet

21
Goddag,

Da vi endnu ikke har fået grønt lys fra alle klient-systemer omkring punkt 2, udskydes den til Medio August, hvis vi får grønt lys før dette tidspunkt vil det blive udmeldt her.

Mvh,
Steven A. Sørensen, Trifork.

22
Jeg får en fejl når jeg prøver at tjekke dette.
Fejlen skyldes at jeg forventer at der er et KeyValueSet med en Key der hedder DrugMedicationIdentifier og dette mangler.
Jf. https://wiki.fmk.netic.dk/doku.php?id=fmk:generel:udvidet_validering#udvidet_validering
<KeyValueSet>
   <Key>DrugMedicationIdentifier</Key>
   <Value>2190751217130</Value>
</KeyValueSet>

Hvis det er meningen at dette element er valgfrit så er det gået min næse forbi.

Min fault ser ellers fint ud jf.
[[XML fjernet for læslighed]]

Hej Peter,

Det er egentlig et valg vi tog da valideringen blev oprettet. Da valideringen både finder sted ved oprettelse og opdatering. Ved oprettelse har ordinationen jo ikke fået et ID, så der ville ikke være et gyldigt ID at sætte ind i "DrugMedicationIdentifier" KeyValue. Hvis du kigger i dokumentationen af fejlkoder som blev linked til i tidligere post kan du også se hvilke KeyValue sæt vi sender med for den pågældende fejlkode.

Når det så er sagt så kan vi godt se at den Key er til stede ved alle de andre udvidede valideringer som findes for ordinationer.

Vi har den mulighed at vi ved oprettelse kunne sende en standard værdi med, og ved opdatering kunne vi så sætter den korrekte identifier ind. Det ville så kræve noget nærlæsning af dokumentationen af den enkelte udvidede validering hvis der er specielle regler omkring KeyValue Sæt.

Ville det være tilstrækkeligt?

Mvh,
Steven A. Sørensen, Trifork.

23
Goddag,

Punkt 1, 3, 4 og 5 er nu aktiveret i produktion. Vi holder øje med situationen.

Mvh,
Steven A. Sørensen, Trifork.

25
Goddag,

Da vi nu er ved at nærmes os medio April, kommer der her en opdatering.

Efter feedback fra klient-systemerne har vi fået go for punkt 1, 3, 4 og 5. Så disse vil blive aktiveret i produktionen efter planen den 15. April med mindre vi hører andet.

Punkt 2: "Validering mod ændring af behandlings-slut på udløbne ordinationer." udestår for nu, da vi har fået tilkendegivet at enkelte systemer endnu ikke er helt på plads med en understøttelse af dette, så aktiveringen af denne udskydes i første omgang til medio Juni

Mvh,
Steven A. Sørensen, Trifork.

26
Hej Steven

Det er en anelse sent at sende denne info ud . Det havde været fint at få den info før I planlægger at slå en ny validering til. Det er ret uholdbart, at skulle opdage det ved et tilfælde.

Når vi tester en leverance som Systematic leverer, tester vi 'kun' tingene éen gang og ikke løbende i hele leverancens løbetid. Ved et tilfælde opdager vi så at local source åbenbart bliver anvendt forkert. Vi skal sætte leverancen i drift næste weekend, så hvis noget fejler nu er det et kæmpe problem.

Det er trods alt godt at høre at I ikke slår det til i drift før der fra andre leverandørers side er 'ryddet' op. Er der en tidsfrist på denne rettelse?

Vh Helle

Goddag Helle,

Jeg beklager at det ikke var meldt ud inden valideringen blev slået til, det er en fejl fra min side at det ikke blev gjort.

Der er endnu ikke en tidsfrist for at tingende skal være rettet i produktionen, men vi kommer til at holde øje med de systemer hvor fejlen optræder, og forventer at tage fat i disse i løbet af året med henblik på at finde en løsning.

Som nævnt tidligere er dette ikke en kritisk validering da FMK retter på de forkerte source når de indmeldes. Men for at sikre mod at der skulle ske fejl, hvor brugeren måske har forventet noget andet, arbejder vi os langsom hen mod at det gerne skulle være korrekt inden det sendes til FMK.

Det skal måske også igen pointeres at selvom den forkerte source har været angivet, har FMK altid valideret det som om det var medicinpriser. Dvs. hvis ikke de valgte data optrådte i medicinpriser ville FMK alligevel ikke acceptere disse, så de systemer
 som anvender forkerte source burde kun skulle rette på sourcen, da det valgte data var fint.

Håber det besvarer dine spørgsmål.

Mvh,
Steven A. Sørensen, Trifork.

27
Goddag,

I forbindelse med et oprydnings-projekt på FMK har vi igennem længere tid arbejdet med at få repareret for forkert brug af source="local" på elementer hvor der aldrig skulle have været support for brugen af denne source.

Ved en fejl har FMK igennem længere tid accepteret brugen af denne source på elementerne:
  • Administrationsvej (RouteOfAdministration)
  • Indikation (Indication)
  • ATC
  • Lægemiddel Form (DrugForm)
  • Pakkestørrelsesenhed (PackageSizeUnitCode)

Selvom der aldrig har været korrekt support for source local, samt de har altid været valideret som var der angivet source=Medicinpriser.

Dette ønsker vi at rette op på, så igennem længere tid har FMK udført reperation af disse forkerte sources når de sendes til FMK, men dette ser vi ultimativt som en uholdbar løsning, hvor vi i stedet ønsker at bruger-systemerne i stedet benytter sig at de korrekte sources når de sender data til FMK.

Vi udførte en reparation af samtlige forkerte source "Local" i FMK i prod i begyndelsen af December 2020, samme reparation har været kørt flere gange i både Test1 og Test2.

Den 11-1-2021 slog vi en validering til i Test1 og Test2 som giver fejl hvis man forsøger at benytte source=local på elementer hvor det ikke er supporteret. Samme validering forventer vi at enable i produktion så snart vi kan konstatere at der ikke længere sker yderligere tilfælde af misbrug.

Venlig hilsen
FMK teamet


28
Valideringen er nu blevet aktiveret

29
Goddag,

Vi har observeret at vi i FMK har tilladt at der er oprettet strukturerede doseringer hvor det største dag-nummer er større end det angivende iterations-interval. Denne form for doseringer er i princippet forkert og potentielt farlige da det nemt kan misforstås. FMK kan heller ikke automatisk rette disse, da vi ikke ved hvor i doseringen fejlen er. Vi har derfor afgjort at vi bliver nødt til at indføre en validering mod at doseringer med denne type fejl oprettes, dvs doseringen tjekkes for denne fejl både ved oprettelse og opdatering af ordinationer på FMK.

Eksempeler kunne være:
1 Tablet morgen dag 1
1.5 Tablet aften dag 2
Iterations-interval = 1
Eller
1 Tablet morgen dag 7
Iterations-interval = 6

Vi forventer at valideringen træder i kraft i løbet af i dag (21-10-2020), jeg opdatere når vi har bekræftet valideringen er aktiv.

Med venlig hilsen
FMK Teamet

30
Mulighed for at benytte gammelt OnBehalfOf-Namespace (Punkt 4) er blevet reintroduceret i Test1 og Test2 efter ønske fra det sidste system vi umildbart kan se benyttede sig af det.

Det forventes at vi fjerner muligheden igen i midt december, efter aftale med det pågældende system.

Skulle der være spørgsmål til dette, eller andet, er i velkommene til at skrive enten her i tråden eller en besked direkte til mig.

Pages: 1 [2] 3 4