FMK Teknik

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

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

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

Receptmodulet opdateres i dag 11-10-2022 til version 1.38.16. Opdateringen foregår uden nedetid.

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

Mvh
FMK Teamet

Onsdag den 08.06.2022 opdateres FMK i produktionsmiljøet til version 1.4.6.51.e. Opdateringen foregår uden nedetid.

Der er tale om et hotfix release.

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

Mvh FMK Teamet

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

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

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

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

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

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

Goddag,

Som en del af et større oprydnings-projekt internt i FMK har vi været igennem en større del af den funktionalitet som i øjeblikket er styret internt i FMK med properties, og som i øjeblikket ikke er aktiveret, fordi det i sin tid skabte problemer for et eller flere klientsystemer.

Dette er dog noget vi gerne vil i gang med at tænde for igen, og beder derfor alle leverandører af klient-systemer om nøje at læse de følgende 5 punkter igennem, da det typisk vedrører ældre funktionaliteter som vi meget gerne vil have lukket for.
Vi forventer at tænde for disse 5 funktionaliteter i Test1 og Test2 om 3 måneder, med henblik på at få dem i produktion 6 måneder herefter. Dette håber vi er en rimelig tidshorisont, for at alle klientsystemer har mulighed for at sikre sig mod at ændringerne lukker/ødelægger funktionalitet i jeres systemer.

Herunder beskrives de 5 funktionaliteter, hvad der præcis er tale om, og hvad der sker når vi tænder for funktionaliteten. I er velkomne til at stille spørgsmål hvis der skulle være uklarheder, idet nogle ting vil være ret tekniske i deres natur.

Edit: Funktionalitet forventes enablet i Test1+Test2 medio September 2020, Forventes enablet i produktion medio April 2021

Edit 2: Funktionalitet 1, 3, 4 og 5 forventes enablet i produktion 15. April 2021. punkt 2 udskydes til medio Juni

1: Fjernelse af "UseNewSuspension" fra response-header.
UseNewSuspension er en property som er synlig i response-headerens' konfigurationsangivelse: https://wiki.fmk.netic.dk/doku.php?id=fmk:generel:konfigurations-angivelse_i_response_header.

NewSuspension blev oprettet i forbindelse med skiftet fra den gamle løsning med "suspendering" af medicinkortet ved indlæggelse til den nuværende funktionalitet hvor medicinkortet markeres "ikke ajourført".

Denne property har været sat til værdien "True" igennem længere tid, og skal ikke ændres yderligere. Derfor mener vi også det vil være en god ide at fjerne denne funktionalitet helt, men det skal sikres at alle systemer som benytter sig af denne, ikke fejler/skifter tilbage til gammel funtionalitet pga. den ændringen. Alle systemer bør derfor sikre sig at de kan overleve at "NewSuspension" vil mangle fra konfigurationsangivelsen, og at systemet stadig opfører sig, som om det antages at denne værdi altid vil være "True" fremover.

Herunder et eksempel på hvordan denne værdi står i et af de nuværende svar fra FMK:
<medicinecard20150101:FMKConfigurationList xmlns:medicinecard20150101="http://www.dkma.dk/medicinecard/xml.schema/2015/01/01">
         <medicinecard20150101:KeyValuePair>
<medicinecard20150101:Key>UseNewSuspension</medicinecard20150101:Key>
<medicinecard20150101:Value>true</medicinecard20150101:Value>
</medicinecard20150101:KeyValuePair>
<medicinecard20150101:KeyValuePair>
<medicinecard20150101:Key>PausePeriodEnabled</medicinecard20150101:Key>
<medicinecard20150101:Value>true</medicinecard20150101:Value>
</medicinecard20150101:KeyValuePair>
</medicinecard20150101:FMKConfigurationList>
Det er altså det keyValue pair med UseNewSuspension,  som vi ønsker at fjerne.

2. Validering mod ændring af behandlings-slut på udløbne ordinationer.
Tilbage i 2015 indførte FMK en validering mod at brugeren rettede på behandlingsslut-datoen for ordinationer, hvor behandlings-slut allerede var overskredet. Dette skabte dog problemer for flere systemer, og valideringen blev herefter slukket indtil systemerne kunne håndtere fejlen. Valideringen har desværre været glemt længe, og derfor mener vi også det er på høje tide at vi får sat gang i den igen.

Hvordan fungerer valideringen? Ved forsøg på at ændre behandlingsslut-datoen tjekker FMK, om den nuværende slut-dato ligger i fortiden. Hvis dette er tilfældet vil FMK fejle og returne en fejlkode med nummer 425. Bemærk at dette kan være fordi ordinationen er blot er udløbet som normalt, eller hvis den er blevet seponeret. Det vil stadig være muligt at af-seponere ordination, hvilket vil genoprette den tidligere slutdato. Bemærk dog at hvis denne også er udløbet, vil der stadig ikke kunne ændres på denne herefter.

Det anses generelt som en fejl at lægen "genopliver" ordinationen som allerede er udløbet, frem for at gøre det rigtige og oprette en ny behandling (ny ordination). Dette vil FMK nu gerne forsøge at tage hånd om.

Når vi tænder for funktionaliteten vil alle fremtidige kald til opdatering at lægemiddelordinationen, hvor der ændres på behandlings-slutdatoen efter denne er udløbet, fejle. Brugeren vil få en fejl 425 der fortæller, at deres ændring af behandlingsslut-datoen ikke er gyldig.

Vi opfordrer samtidig til, at alle systemer indfører en upfront validering til at hjælpe lægen med i stedet at oprette en ny behandling.

3. Ændring i fejl-response namespace
I forbindelse med FMK's oprydning af 1.4.0 snitfladen, fandt vi en fejl i hvordan FMK valgte namespaces for fejl-responses. Dette gjorde at alle namespaces til og med 1.4.4.E1 valgte namespacet for 1.4.0 snitfladen, hvorimod alle fra 1.4.4.E2 og opefter fik namespacet fra den snitflade servicen var kaldt på.

Dette er noget vi gerne vil have rettet op på, og gøre tingene lidt mere robuste overfor eventuelle fremtidige extensions. Vores ændring gik derfor ud på at man ændrede namespacet til det nærmest namespace som ikke var en extension. Dvs 1.4.4E1,E2,E4,E5 ville alle sammen have namespacet 1.4.4 i deres fejl-response (mere præcis værdien http://www.dkma.dk/medicinecard/xml.schema/2015/01/01) , det samme gælder 1.4.6 og extensions hertil.

Et eksempel på en fejl som det vil se ud på 1.4.6.E3 snitfladen.
<soapenv:Fault>
<faultcode>soapenv:Client</faultcode>
<faultstring xml:lang="en">SOME ERROR</faultstring>
<detail>
<medcom:FaultCode>555</medcom:FaultCode>
<medicinecard20150601E3:FaultText xmlns:medicinecard20150601E3="http://www.dkma.dk/medicinecard/xml.schema/2015/06/01/E3">SOME TEXT</medicinecard20150601E3:FaultText>
        <medicinecard20150601E3:FaultDetails xmlns:medicinecard20150601E3="http://www.dkma.dk/medicinecard/xml.schema/2015/06/01/E3">
        <medicinecard20150601E3:KeyValueSet>
        <medicinecard20150601E3:Key>ElementPath</medicinecard20150601E3:Key>
        <medicinecard20150601E3:Value>XXX</medicinecard20150601E3:Value>
        </medicinecard20150601E3:KeyValueSet>
        <medicinecard20150601E3:KeyValueSet>
....
        </medicinecard20150601E3:KeyValueSet>
        </medicinecard20150601E3:FaultDetails>
</detail>
</soapenv:Fault>

Når vi tænder for funktionaliteten vil 1.4.6.E3 blive reduceret til 1.4.6 basis snitfladen, og response vil derfor indholde følgende namespaces i stedet.

<soapenv:Fault>
<faultcode>soapenv:Client</faultcode>
<faultstring xml:lang="en">SOME ERROR</faultstring>
<detail>
<medcom:FaultCode>555</medcom:FaultCode>
<medicinecard20150601:FaultText xmlns:medicinecard20150601="http://www.dkma.dk/medicinecard/xml.schema/2015/06/01">SOME TEXT</medicinecard20150601:FaultText>
        <medicinecard20150601:FaultDetails xmlns:medicinecard20150601="http://www.dkma.dk/medicinecard/xml.schema/2015/06/01">
       <medicinecard20150601:KeyValueSet>
              <medicinecard20150601:Key>ElementPath</medicinecard20150601:Key>
              <medicinecard20150601:Value>XXX</medicinecard20150601:Value>
       </medicinecard20150601:KeyValueSet>
       <medicinecard20150601:KeyValueSet>
....
       </medicinecard20150601:KeyValueSet>
       </medicinecard20150601:FaultDetails>
</detail>
</soapenv:Fault>
Det anbefales at systemerne gør sig uafhængige af hvilket namespace et eventuelt fejl-svar kommer tilbage i, hvor muligt, eventuelt lave håndtering at begge tilfælde indtil alt er sikret i produktion.

4. Fjern mulighed for at benytte gammelt OnBehalfOf-Namespace.
Assistenter til læger har typisk ikke samme rettigheder som lægen, men kan stadig udføre dele af en læges arbejde på vegne af lægen. Dette er også beskrevet på dokuwiki:https://wiki.fmk.netic.dk/doku.php?id=fmk:generel:aktorer_pa_fmk. Når dette gøres benyttes OnBehalfOf i headeren på et request. I forbindelse med oprydningen af 1.4.0 snitfladen slettede vi også muligheden for at benytte dette og 1.4.2's namespaces for OnBehalfOf elementet. Dette fandt vi dog ud af nogle systemer stadig benytter, og vi indførte derfor en midlertidig løsning således at man stadig kunne benytte disse gamle namespaces.

For at færdiggøre fjernelsen af de gamle fmk-sniftflader mangler vi dog at kunne fjerne denne funktionalitet, og vi beder derfor alle som stadig benytter OnBehalfOf med enten 1.4.0 eller 1.4.2's namespaces til at benytte 1.4.4's namespace i stedet.
Når vi fjerner muligheden for at benytte disse gamle namespaces i OnBehalfOf elementet, vil alle som overtræder dette fremover få en fejl med fejlkode 4003, og beskeden "Sosi xml fejl: Fejl i OnBehalfOfElement".

5. Validering mod angivelse af ordinationsid på opret recept i forbindelse med oprettelse af lægemiddelordination.
Vi har i FMK igennem længere tid observeret, at flere systemer ser ud til at sætte et ordinations-id på et opret-recept element, selv om dette opret-recept element er bundet sammen med et opret lægemiddelordination's element. Dette er en fejlagtig anvendelse, som FMK i øjeblikket løser ved at fjerne ordinations-id'et igen. Her kan der dog skjule sig en potentiel fejl, hvor klientsystemet har placeret opret-recept elementet forkert, og det var meningen at recepten skulle oprettes på en anden ordination.

FMK indførte derfor en ikke aktiveret validering, hvor der dengang blev gjort opmærksom på, at dette var et problem vi håbede klientsystemerne ville få løst, således at FMK kunne aktivere valideringen. Vi har dog holdt øje med hvordan dette udviklede sig, men kunne ikke se en tilstrækkelig ændring til, at vi følte det var sikkert at aktivere valideringen uden videre.

Et eksempel kunne være (namespace fjernet):
<CreateDrugMedicationRequest>
    <PersonIdentifier>00000000</PersonIdentifier>
    <MedicineCardVersion>1</MedicineCardVersion>
    <CreatedBy>
        ....
    </CreatedBy>
    <DrugMedication>
        <BeginEndDate>
            ..
        </BeginEndDate>
        <Indication>
           ..
        </Indication>
        <RouteOfAdministration>
            ..
        </RouteOfAdministration>
        <Drug>
            ...
        </Drug>
        <Dosage>
            ..
        </Dosage>
        <SubstitutionAllowed>true</SubstitutionAllowed>
  <CreatePrescriptionMedication>
<DrugMedicationIdentifier>111111</DrugMedicationIdentifier>
...
  </CreatePrescriptionMedication>
        <ReimbursementClause>klausulbetingelse opfyldt</ReimbursementClause>
    </DrugMedication>
</CreateDrugMedicationRequest>

Et DrugMedicationIdentifier element burde slet ikke indsættes i dette tilfælde. Når valideringen aktiveres vil FMK fremover returnere en fejlkode 474, hvis dette sker.

Goddag,

I den seneste tid har FMK teamet haft en del fokus på valideringsfejl, herunder også de udvidede valideringer. Dette har resulteret i en del format-ændringer, både internt i FMK men også hvordan vi dokumentere dette på vores doku-wiki.

Her er nogle highlights af de features vi har arbejdet med

Features der er implementeret og aktive per FMK version 1.4.6.30.b:
1. De udvidede valideringer har fået et ny format. læs mere om dette her: http://www.fmk-teknik.dk/index.php?topic=1702.0 (FMK-5890, Version 1.4.6.30.a)
2. Der er introduceret nye keys til en del fejltekster, bl.a. er DrugName (såfremt dette er tilgængelig) nu inkluderet i en del fejltekster hvor man før kun havde et ID: https://wiki.fmk-teknik.dk/doku.php?id=fmk:generel:fejlkoder_og_-tekster (FMK-5898, Version 1.4.6.30.b)
3. Dokumentationen af hvilke Keys som FMK indsætter i fejlteksten, samt hvilke der optræder i KeyValue listen er nu også dokumenteret, bemærk at alle keys per fejlkode nu er unikke. (FMK-5898, Version 1.4.6.30.b)
4. I forbindelse med punkt 2 og 3 er der også ryddet op i valideringsfejl som ikke benyttes længere, og evt fejl i forhold til de Keys som benyttes. (FMK-5898, Version 1.4.6.30.b)

Features der stadig arbejdes på:
1. Der arbejdes på at lave en automatik omkring publiceringen af nye/ændrede fejlkoder/tekster på doku-wiki, vi forventer at kunne lave det således at dokumentationen opdateres samtidig med at en ny FMK version ligges på test-systemerne. Generatoren er klar, men mangler en automatik til publicering på doku-wiki.
2. ElementPath, et element som førhen kun befandt sig i de udvidede valideringsfejl, som givet et mere præcis angivelse af hvor i ens forespørgsel er gået galt, vil blive indført på en del flere valideringsfejl, såfremt det er muligt og giver mening. (Læs mere om ElementPath her: https://wiki.fmk-teknik.dk/doku.php?id=fmk:generel:fejlhandtering#signalering_af_udvidede_valideringsfejls_pa_requestniveau & https://wiki.fmk-teknik.dk/doku.php?id=fmk:generel:elementpath dokumentation vil blive opdateret når vi er færdige med at implementere det i FMK) (FMK-5943, Version TBD)

Da Softwareborsen.dk er blevet lukket per 1. Oktober 2019, har vi valgt midlertidigt at placere DumpRestore klienten direkte i vores egen Doku-wiki side indtil videre:
https://wiki.fmk.netic.dk/doku.php?id=fmk:dumprestore:dumprestore_snitflade#dumprestore_klient

Version 1.37.2 af receptmodulet deployes på test1+test2 i dag

Det komplette indhold af releasen og udrulningsplanen kan ses på https://www.nspop.dk/display/Web3/Trifork+FMK+Releaseplan