FMK Teknik

Hej Mikkel,

FMK har generelt ikke meget med selve certifikaterne at gøre, vi validere dem kun når de kommer til os.

FMK teamet har igennem tiden udviklet en del dokumentation som du kan finde på https://wiki.fmk-teknik.dk/doku.php

Heriblandt finder du en "Kom-godt-i-gang guide" https://wiki.fmk-teknik.dk/doku.php?id=fmk:generel:kom_godt_i_gang Som linker til mange af de steder man finde informationer omkring anvendelsen af FMK, og hvordan man kommer igennem de forskellige ting på NSP'en.

Beklager dette svar ikke tog noget tid, FMK-Teknik benyttes primært til udmeldering fra FMK-teamet, og vi overvåget det ikke for spørgsmål mm. med mindre det er forbindelse med en given udmelding.

Mvh,
Steven A. Sørensen, Trifork.

Edit: Rettelse af stavefejl

FMK vil i perioden 17.07.2024 blive opdateret til version 1.4.6.66. Opdateringen foregår uden nedetid.

For listen af ændringer henvises til FMK releaseplanen på https://www.nspop.dk/display/Web3/Trifork+FMK+Releaseplan

Mvh FMK Teamet

FMK teamet har igennem de seneste par måneder oplevet nogle supportsager omkring DumpRestore med datoforskydninger som "ikke virkede" som tiltænkt.

Dette skyldes at FMKs DumpRestore kun lave datoforskydninger i fulde dage, og for at sikre at det data der blev restoret ikke allerede ville have fremtidige ændringer registreret, skubbede FMK i disse tilfælde alle datoer en dag tilbage.
FMK bedømmer ud fra dumpet et tidspunkt for hvornår det pågældende dump blev lavet, og dermed ved den også om et restore til dags-dato ville resultere i data som først er valide i fremtiden. I disse tilfælde oplevede brugeren at medicinkortet effektivt blev låst, indtil man nåede samme tidspunkt på dagen som ens dump var lavet på. Derfor blev der lavet en ændring som sikre dette ikke skete.

Eksempel:
Dump foretaget 15/3/2024 kl 17:00.
Restore foretages 30/5/2024, kl 12:00.

Førhen: Restores til 30/5/2024 kl 17:00, medicinkortet er nu låst indtil kl 17:00.
Efter ændring: Restore ændres til 29/5/2024 kl 17:00, datoer er ikke som forventet, men medicinkortet er ikke låst.

Efter at have indsamlet kommentarer, og diskuteret situationen med SDS, er vi kommet frem til at denne funktionalitet skal ændres. FMK bør ikke bagom brugeren ændre på det input som er angivet. I stedet skal FMK så afvise at foretage Restore, såfremt det ville føre til at låst medicinkort.

I et kommende release bliver dette derfor indført i FMK, og brugere som benytter DumpRestore, vil i nogle tilfælde opleve en fejl om at Restore ikke kan gennemføres. I fejlbeskeden vil det timestamp FMK har fundet frem til kunne ses, og ud fra dette kan man så enten vælge at foretage restore til en tidligere dato, eller afvente at tidspunktet fra sit dump er tidligere på dagen end når man foretager sit restore.

Med venlig hilsen
FMK Teamet

Til information,

Rettelsen som implementere de ønskede ændringer nævnt ovenfor, er nu blevet lagt på Testmiljøerne Test1 og Test2 i FMK version 1.4.6.64

Rettelsen vil komme i produktion sammen med denne release.

I beder derfor venligst sikre at jeres systemer kan håndtere at ændringerne ikke påvirker jeres systemer negativt. Skulle der være problemer bedes i kontakte os for at aftale nærmere.

Med venlig hilsen
FMK Teamet

FMK opdateres onsdag den 19.04.2024 til version 1.4.6.64.a i test1 og test2 miljøerne. Opdateringen sker uden nedetid.

For listen af ændringer, se releaseplanen på https://www.nspop.dk/display/Web3/Trifork+FMK+Releaseplan

Mvh FMK Teamet

Goddag,

Efterhånden som de fleste systemer har understørrelse af visning af data omkring dosisdispensering i FMK. Har vi nogle ændringer som vi agter at indfører i forbindelse med arbejdet frem mod FMK's 1.6.0 snitflade.

I denne omgang er der tale om 2 ændringer, som specifikt har indflydelse på recepter til dosisdispensering.

Implementeringen af disse ændringer forventer vi vil begynde i starten af 2024, nærmere udmelding vil komme når vi kender en mere præcis timeline.

Fjernelse af StartDate og EndDate fra DD-recepter.

https://wiki.fmk-teknik.dk/doku.php?id=fmk:1.4.4:receptordination#receptordination_til_dosisdispenseret_udlevering
<DoseDispensedPrescriptionDispensing>
<PackageNumber source="Medicinpriser" date="2023-11-16">....</PackageNumber>
        <CopyRequired>false</CopyRequired>
<DosageText>1 tablet morgen og aften ved måltid</DosageText>
        <StartDate>2023-04-11</StartDate>
<EndDate>2025-04-11</EndDate>
</DoseDispensedPrescriptionDispensing>

Elementerne StartDateog EndDate for DD-recepter, har været til brug for Apoteket til at styrer om hvornår DD bør begyndes/stoppes, dette blev brugt fordi apoteket dengang ikke havde adgang til den bagvedliggende Lægemiddelordination.
Værdierne blev fastsat ved receptens oprettelse ud fra den daværende dosering. Der var desværre problemer med at LMO og Recept røg ud af sync, når der lavedes ændringer i ordinationen, uden der blev oprettet en ny recept.

Efter overgangen til DD i FMK, var der en del forvirring, da disse 2 datoer ikke længere var hvad lægen skulle være opmærksom på, hvis de ønskede indflydelse i behandlingen. FMK var overgået til at benytte datoerne fra Doserings-start/slut og Behandlings-start/slut fra LMO'en, samt Gyldighedsperioden fra recepten. Specielt EndDate var der meget mange henvendelser fra læger omkring, da lægerne var vant til at apoteket tog kontakt når denne dato nærmede sig, og at de så der kunne gennemgå alle de ændringer der var nødvendige inden de lavede en ny recept. Dette var dog ikke længere tilfældet, da EndDate ofte var mindre en gyldighedsperioden, kom der ingen kontakt, da apoteket nu styrede alt igennem FMK.

Da der var så meget forvirring omkring hvorfor datoerne nu ikke længere havde samme betydning som før, og på grund af megen support til både FMK og klient-systemer, ændrede FMK det således at datoerne nu ikke længere er endeligt sat ved receptens oprettelse, men beregnet hver gang recepten hentes, ud fra den nuværende dosering/behandlings-datoer fra LMO'en, eller receptens gyldighed hvis ikke LMO'ens datoer er sat. Der var dog allerede dengang tale om at datoerne nok alligevel burde afskaffes, men man ønskede at give lægerne og klientsystemerne tid til at vende sig mere til den måde DD fungere på i dag.

I FMK's kommende 1.6.0 snitflade, er det fastsat at datoerne helt fjernes, og som optakt til dette, ønsker vi også at undlade dem fra alle de nuværende snitflader, da de ikke længere giver værdi, og lægerne i stedet bør holde fokus på LMO'en og receptens gyldighedsperiode.

Elementerne har allerede i dag en MinOccurs=0 på samtlige snitflade, hvilket betyder at det er fuldt ud validt for FMK at undlade at returnerer disse informationer, og klienterne bør understøtte at disse værdier faktisk kan mangle.

Vi laver denne udmelding som optakt til at de systemer, som måske i dag viser eller benytter denne dato til noget, bør være forberedt på at FMK i fremtiden ikke sender disse ud. Dette gælder både for 1.4.4 (LPS/EPJ/EOJ) og 1.4.6 (Apotek) snitfladerne.

"Fjernelse" af CopyRequired

Som set i eksemplet ovenover, har vi i dag en værdi med navnet CopyRequired. Denne var igen tiltænkt at før DD kom ind i FMK, kunne lægen gennem dette element ønske en kopi af dosiskortet tilsendt, således at lægen kunne få indsigt i hvordan DD-pakningen forgik for den individuelle patient.

Vi er ikke bekendt med om hvor meget/lidt denne funktionalitet har været anvendt igennem tiden, men da alle data nu er tilgængelig igennem FMK, og lægen kan til enhver tid selv hente dem igennem sit eget system eller FMK-Online, så mener vi ikke længere der er grund til at dette element benyttes. Og igen forventes dette element helt fjernet i den kommende 1.6.0 snitflade.

Da elementet ikke er optionelt i 1.4.4 snitfladen, vil FMK i fremtiden altid returnere "false" som værdi til dette element, også selvom lægen måske har tilvagt det. På 1.4.6 snitfladen er elementet optionelt, dvs FMK vil ikke returnere elementet. For systemer som anvendet 1.4.4 snitfladen til at oprette recepter, kan de roligt fjerne CopyRequired fra deres UI, og kan sende hvad end værdi de ønsker ind til FMK, som blot vil ignorerer feltet.

Med venlig hilsen
FMK Teamet

Goddag,

Vi har i dag released version 1.4.6.60 til Test1 og Test2. ( https://www.fmk-teknik.dk/index.php?topic=2283.0 )

Vi fik i forbindelse med release af 1.4.6.59, indmeldinger om vi ikke havde givet tilstrækkelig advarsler angående vores nye valdiering af sammenhæng af SOR-nummer og SOR-type. ( https://www.fmk-teknik.dk/index.php?topic=2277.0 )

Derfor denne udmelding, vi fandt endnu et sted hvor denne validering manglede.
Det er i forbindelse med at systemer henter receptanmodninger, da typen anvendes til søgningen, er det vigtigt at denne type faktisk matcher med det nummer man søger på.

Da konsekvensen af at søge med en forkert kombination, betyder lægerne ikke modtager de receptanmodninger der faktisk sendes til organisationen, blev valideringen også indført her. Dette bør dermed sikre at både afsendelsen og modtagelsen af receptanmodninger for SOR, er sikret på begge sider.

Mvh FMK Teamet

Hej Christian,

FMK-Teknik anvendes generelt ikke til denne type henvendelser.

Omkring adgang til NSPs testmiljøer, kan du henter informationer her: https://www.nspop.dk/category/an

henvendelser omkring support tages typisk igennem NSPOP's support: https://www.nspop.dk/category/sup

Mvh FMK Teamet

Quote from: Paul D. Samsig on 2023-09-19 16:42:35
Man kunne argumenterer for, at det er totalt overflødig at skulle angive SOR-type, da det er implicit ud fra SOR-kode, og man kunne også argumentere for, at når SOR-typen (implicit eller eksplicit) er 'Supplerende  oplysninger', så tjekkede FMK selv på om niveauet over, var en valid SOR-type. Det ville have været en meget mindre disruptiv måde, at opnå den samme sikkerhed for 'korrekte' SOR-koder og SOR-typer.

Hej Paul,

Det har aldrig været FMKs første tilgang til problemer, at ændre på hvad klienten indberetter. Gør vi dette, så er chancen stor for det også skaber forvirring når data så kommer ud igen og ikke er ens med hvad der blev indberettet. Det kan sagtens være det i realiteten ikke har den store indflydelse, og de fleste vil nok ikke opdage det, men det skaber noget utryghed at FMK "bare ændre" på hvad folk indberetter, selv hvis det vi ændre det til faktisk vil være det korrekte.

Da OrganisationIdentifierType i skemaet ( https://wiki.fmk-teknik.dk/doku.php?id=fmk:medicinecard-inline_2015_01_01_e4:feltbeskrivelser#OrganisationIdentifierType ) kun har en source og ikke source+date. Har klienten ikke adgang til at informere FMK om hvordan den forventer verden ser ud. Vi har set at Organisationer skifter type, uden at skifte SOR-nummer, fx ved fejlregisteringer.

Så hvis vi implementerede det som du foreslår:
Systemet indberetter Kode X, som har typen "Supplerende oplysninger".
FMK "beriger" på vej ind, finder Kode Y, har typen "Administrativ Enhed". (Blot til eksempel om type som ikke godtages)

Hvad skal FMK returnerer? Vi kan ikke acceptere kode X, vi kan ikke acceptere kode Y. Skulle vi have lavet en anden valideringfejl om at FMK kan ikke finde en gyldig SOR-nummer+Type kombination?

Det samme gør sig gældende hvis vi er ude i en situation hvor organisationen har ændret type. Uden af klientsystemet eller brugeren har kendskab til ændringen. Da i ikke kan angive en SourceDate, vil FMK finde noget andet en hvad klienten havde forventet.

Systemer indberetter Kode X, indtil dagen før havde den typen "Bosted".
FMK "beriger" på vej ind, finde X, men beriger nu typen til den nye værdi "Administrativ Enhed".

FMK smider nu fejlkode 306, "Det er ikke tilladt at anvende en SOR organisations id for typen [Beriget type], kun flg. er tilladte: [Accepterede typer]".

Hvis vi berige på vej ind med en helt anden SOR-nummer end det som blev indberettet, gør også FMKs arbejde med flere typer support mere besværligt. Derudover vil en berigelse på vej ud, ud fra det ændrede sor-nummer, med stor sandsynlighed give nogle helt andre oplysninger end hvad der måske kunne forventes. I supplerende oplysninger angives type nogle helt andre navne på noden, end det som angives på organisations-noden, så hvis FMK fra den ene dag til den anden returnere nogle helt andre oplysninger, uden nogen prompt, kunne vi nok forvente lige så mange supportsager på "Oplysningerne er forkerte, indtil i går var det altid...".

Den simple forklaring må nok være, at valideringen følger FMKs normer for at når der opdages fejl, skal de rettes. i dette tilfælde gøres det efter vores overbevisning bedst, ved at validerer sammenhængende mellem nummer og type på vej ind. Dette giver nogen gener for slutbrugerne, og noget forvirring omkring hvad de nu skal gøre. Vi hjælper forsat gerne med at udrede det support som måtte komme ind, men håber også på at denne post ville hjælpe med at forklarer hvad der er ændret, og hvorfor vi har valgt at gøre det. Når den korrekt kombination af Nummer+Type er fundet og anvendes, er alle parter enige om hvad der forventes på vej ind, og hvad der kan forventes kommer tilbage hos alle systemer når data hentes op igen.

Håber denne forklaring giver mening.

Mvh FMK Teamet

Goddag,

Med release 1.4.6.59.c, som blev released til produktion den 6/9/2023 blev der indført en validering omkring benyttelsen af SOR i FMK. FMK har altid valideret at det anvendte SOR-nummer er gyldigt, og at den SOR-type man angav kunne få adgang.

Problematikken ligger i at FMK ikke validerede sammenhængen mellem SOR-nummer og SOR-type.

Det har derfor været muligt at anvende et SOR-nummer i kombination med en SOR-type som ikke matchede. Det gav anledning til problematisk opførsel i nogen af FMK's services, og anses også som en fejl at dette har været muligt, da FMK er pålagt fra SDS's side kun at godkendte SOR-typer bør have adgang til FMK.

Efter release vil de klienter som ikke angiver en gyldig kombination af nummer+type, opleve en fejl med teksten: "SOR Organisation med id [anvendte SOR-nummer] angivet med den forkerte type: [anvendt SOR-type], opslag i SOR viser følgende type: [verificerede SOR-type]". Vi har sidenhen oplevet en del forvirring og behov for support omkring denne ny validering, og skriver derfor denne generelle udmelding.

Klient-systemer, hvis kunder oplever dette problem, bør guide deres kunder til at i stedet anvende en gyldig SOR-nummer+type kombination. Efter vores oplevelse er der typisk tale om at SOR-nummeret som er anvendt er af typen "Supplerende oplysninger" eller "Privat". Oftest vil det korrekte Nummer+Type faktisk ligge enten niveauet over eller under i SOR.

• For typen "Privat" ligger organisationen i niveauet under.
• For typen "Supplerende  oplysninger" ligger organisationen i niveauet over.

Der er udstillet en kopi af SOR her: https://sorbrowser.sundhedsdatastyrelsen.dk/

SOR vil i det fleste tilfælde være udformet i følgende niveauer.

• Organisations ejer (Privat, Stat, Region, Kommune)
• Organisation(er) (Bosted, Plejehjem, Almen lægepraksis mm.)
• Andre Organisationsoplysninger (Supplerende oplysninger)

Det vil altså oftest være tilfældet at SOR-nummer+Type skal tages fra 2.niveau. Bemærk dog at FMK indtil videre kun accepterer typerne som de kommer fra vores KRS replikering, hvori typen altid er angivet med små bogstaver ("bosted" frem for "Bosted").

Der kan være andre udformninger såfremt organisationen er inddelt med hovedafdeling of underafdelinger.

I skrivende stund accepterer FMK følgende organisations-typer:

• bosted
• center for misbrugsbehandling
• genoptræningsenhed
• handicap- og psykiatrienhed
• handicapenhed
• hjemmeplejeenhed
• hjemmesygeplejeenhed
• plejehjem
• psykiatrienhed
• sundhedscenter
• sundhedsplejen
• sygeplejeklinik
• tandlægepraksis
• tandplejeklinik
• behandlingscenter for stofmisbrugere
• behandlingsenhed i fængsel eller arresthus
• vaccinationsklinik
• hospice
• almen lægepraksis
• speciallægepraksis
• asylcenter
• fertilitetsklinik
• rehabiliteringsenhed
• internetbaseret sundhedsydelse

[EDIT]
Når der slåes op i SOR-browseren: https://sorbrowser.sundhedsdatastyrelsen.dk/ er det vigtigt at det korrekt niveau vælges, således at de korrekt oplysninger ses i informationsvinduet.



[EDIT2]
Findes organisations type ikke i listen over godkendte typer, skal der overvejes 1 af 2 løsninger.

• Organisationstypen er ikke beskrivende nok fx "Anden  sundhedsinstitution" er ikke beskrivende, og er derfor ikke tilladt. Hvis der findes en beskrivende type blandt de godkendte enheder, skal SOR kontaktes med henblik på at få ændret typen.
• Organisationstypen er beskrivende, og bør kunne få adgang. I dette tilfælde skal SDS kontaktes, med henblik på af FMK skal lukke op for den pågældende enhedstype.

Mvh FMK Teamet

FMK er i dag opdateret i produktionsmiljøet til version 1.4.6.59.c. Opdateringen er foregået uden nedetid.

For listen af opdateringer, se FMK releaseplan her: https://www.nspop.dk/display/Web3/Trifork+FMK+Releaseplan

Mvh FMK Teamet

Quote from: Søgaard on 2023-05-16 08:56:00
Hej.

Hvor kan vi finde listen over FMK fejlkoder?

Vi kan ikke få nedenstående links til at virke mere:

https://wiki.fmk.netic.dk/doku.php?id=fmk:generel:fejlhandtering#signalering_af_udvidede_valideringsfejls_pa_requestniveau
https://wiki.fmk.netic.dk/doku.php?id=fmk:generel:elementpat

vh
Birgitte RSD

Hej Birgitte,

FMK's DokuWiki har skiftet adresse.

Den nye er https://wiki.fmk-teknik.dk/doku.php?id=start

Listen med alle fejlkoder: https://wiki.fmk-teknik.dk/doku.php?id=fmk:generel:fejlkoder_og_-tekster

Mvh FMK Teamet

FMKs' PDF modul er fredag den 12. maj 2023 opdateret til version 1.1.24 i produktionsmiljøet. Opdateringen er foregået uden nedetid.

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

Mvh FMK Teamet

FMKs' PDF modul er mandag den 1. maj 2023 opdateret til version 1.1.23 i produktionsmiljøet. Opdateringen er foregået uden nedetid.

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

Mvh FMK Teamet

PDF-modulet er opdateret til hotfix version 1.1.22 i produktionsmiljøet i dag den 28/3. Opdateringen er foregået uden nedetid.

Versionen indeholder flg. rettelse:
FMK-7778 PDF, Fejl i sortering af doseringer mellem 4:00 og 4:59


Mvh FMK Teamet