FMK 1.4.6 er en ny videreudvikling af FMK's 1.4.4 snitflade, hvor der primært tilføjes funktionalitet til at understøtte apoteker på FMK. Snitfladen vil blive anvendt af mange forskellige aktører: læger, sygeplejersker, hjemmepleje, apoteker m.fl. Der videreføres dog koncepter og funktionalitet både fra FMK's tidligere snitflader og fra den tidligere apoteksnitflade.

Nogle funktioner kan kun bruges af et apoteket, andre kan fx kun bruges af læger. Dette er en videreførsel af det generelle rolle-rettigheds koncept fra tidligere FMK versioner.

Den største nyhed i FMK 1.4.6 er at den er udbygget med services til apotekerne, så de igennem denne snitflade kan håndtere deres arbejdsgange med opslag, søgning, ekspedition m.m.

Ved dosisdispenserede recepter kan apoteket i forbindelse med hver ekspedition oprette en bestilling til næste ekspedition og opdatere den med information om pakkeapotek, forventede første og sidste doseringsdag, tidsfrist for ændringer som kan nå med inden bestillingen ekspederes m.m. Det giver lægerne bedre mulighed for at agere hensigtsmæssigt i forhold til apotekernes arbejdsgang.

I tidligere FMK snitflader har begrebet receptordination været anvendt. Fra FMK 1.4.6 anvendes i stedet ordet recept i samme betydning. I XML elementerne ændres tilsvarende fra PrescriptionMedication til Prescription.

Det har altid været et potentielt problem, at der kan være forskel på lægemiddelordinationerne (patientens aktuelle medicinering) og recepterne (det der må udleveres på et apotek).

Når FMK 1.4.6 ibrugtages på apotekerne vil apotekerne se både lægemiddelordinationer og recepter. Dermed udstilles evt. forskelle imellem disse tydeligt, og de kan i tvivlstilfælde tage kontakt til lægen for at afklare hvad hensigten er. Hvis der er fejl i recepten skal lægen skal rette op ved at annullere recepten og oprette en ny som er korrekt.

Det er et eksplicit fokus med denne version at opnå bedre sammenhæng mellem lægemiddelordinationer og recepter. At de ikke er slået mere sammen (så recepten slet ikke bærer data om lægemiddel, dosering m.m.) skyldes primært at det ville give en konflikt mellem jura og rolle/rettigheder/arbejdsgange. Visse roller har i deres arbejdsgange behov for at opdatere lægemiddelordinationer, fx dosis-justeringer, men har ikke rettighed (eller tilladelse i juridisk forstand) til at annullere/oprette recepter, hvilket er forbeholdt læger og tandlæger.

For alligevel at opnå en forbedring af sammenhængen mellem lægemiddelordinationer og recepter lægges fra nu af op til at læger og tandlæger bør korrigere recepterne når der rettes i lægemiddelordinationerne. Og det gøres ved at annullere og oprette nye. På en lægemiddelordination bør der som udgangspunkt være 0 eller 1 åben recept tilknyttet. Hvis der er flere bør de som regel kunne sammenlægges til én recept.

I tidligere FMK version har recepter haft en af følgende Dispensing typer:

• SinglePrescriptionDispensing
• ReiteratedPrescriptionDispensing
• DoseDispensedDispensing

Dette har i nogle tilfælde været en lidt dårlig opdeling idet apoteket har kunnet vælge at udlevere på andre måder end lægen forestiller sig ud fra disse elementer. Hvis fx lægen har oprettet en recept af typen SinglePrescriptionDispensing for en lægemiddel i en pakning med 100 tabletter, så kunne apoteket alligevel vælge at udlevere i to omgange, fx 50 stk ad to gange.

I FMK 1.4.6 angives i stedet et af følgende elementer:

• PackageRestriction, med varenummer, pakkestørrelse, antal pakninger, antal udleveringer (totalt, ikke gen-udleveringer), evt. periode mellem udleveringerne
• DoseDispensedRestriction, med et optionelt varenummer som anvendes såfremt lægemidlet ikke er fra taksten (og derfor ikke har et DrugID)

Bemærk at ved dosisdispensering angives ikke et varenummer, pakkestørrelse m.m., da disse også ville være lidt misvisende, når der er tale om dosisdispensering. Dvs. apoteket skal substituere og ekspedere ud fra Drug.

Desuden indeholder DoseDispensedResctriction ikke længere dosisdispenseringens start- og slutdato. Disse hentes fra lægemiddelordinationens strukturerede dosering, eller alternativt fra lægemiddelordinationen såfremt de ikke findes på doseringen.

Hvis en recept annulleres og evt. afløses af en nyere version, imens der er en igangværende ekspedition så kan ekspeditionen godt færdiggøres. Der er en særlig ny status på bestillingen som betyder at apoteket er i gang med ekspeditionen, som ikke skal sættes straks når en recept fx er adresseret, men først når selve ekspeditionen går igang. Inden ekspeditionen går i gang skal apoteket undersøge om de har nyeste version af recepten, og at den stadig er åben og ikke låst af et andet apotek.

Lægen kan når som helst annullere en recept, men hvis der er en åben bestilling med status “ekspedition påbegyndt” tillades denne ekspedition at blive fuldført. Men hvis der ikke er en bestilling, eller den ikke har status “ekspedition påbegyndt” kan der ikke ekspederes mere på den recept.

Dette understøtter en opførsel som rent faktisk vil foregå på apotekerne, uanset om systemet understøtter det eller ej. Med denne ændring bliver det tydeligt for alle parter, hvis en bestilling er ved at blive ekspederet når recepten annulleres. Det sikrer også at apoteket rent faktisk kan indberette ekspeditionen, selvom det sker efter en læge har annulleret recepten. Det kunne de ikke før.

Lægerne kan sætte gyldighedsinterval på recepter, så de tidligst må afhentes efter en dato og ikke senere end en anden dato.

Der er flere mulige brugs-scenarier for dette:

• Vagtlæger-recepter må ikke være gyldige efter 7 dage. Dette er tidligere håndteret automatisk ud fra viden om hvilket system vagtlægerne har brugt til at oprette recepter, eller ud fra vagtlægens organisation. Fra FMK 1.4.6 bliver det klientens ansvar at indberette med et passende gyldighedsinterval.
• Visse behandlinger skal igangsættes straks for at give mening. Hvis man venter for længe skal lægen revurdere om det er den rigtige behandling. Fx en penicillin-kur, som skal anvendes nu imens man er syg. Hvis man venter et halvt år er der ikke tale om samme sygdomsforløb, og så bør en læge igen vurdere om penicillin er den rigtige behandling.
• Fremdaterede recepter (som først er gyldige fra en fremtidig dato) kan give mening i visse situationer, hvis der ikke må udleveres for meget ad gangen, eller ikke flere gange på samme recept.

Bemærk: Det er p.t. ikke tilladt at fremdatere en recept. D.v.s. ValidFromDate kan ikke være senere end oprettelsestidspunktet.

Der er lavet nye services der giver apotekssystemer adgang til at opdatere status på en recept i henhold til tilladte statusskift. Det drejer sig om følgende services:

• Ugyldiggør recept (fra den tidligere apotekssnitflade)
• Afslut recept (fra den tidligere apotekssnitflade)
• Genåbn recept (ny service, der giver mulighed for at fortryde de to ovennævnte)

Det er besluttet at EO skal være en integreret del af FMK-snitfladen, og dermed ikke have sin egen service/WSDL. Derfor er der tilføjet en række nye services til FMK snitfladen, der giver anvendere af snitfladen mulighed for at arbejde med receptanmodninger.

Med denne ændring er der samtidig sket en simplificering, bl.a. med henblik på at forhindre mange af de problemstillinger der har præget brugen af den gamle EO snitflade.

Der er endvidere sket en adskillelse af funktionalitet til bestilling af apoteksudlevering (hvilket i forvejen understøttes af 1.4.6-snitfladen via Opret Bestilling), og funktionalitet til anmodning om en recept. Der er således ikke længere mulighed for den såkaldte ”wildcard-bestilling” fra tidligere EO-snitflader, som enten blev til en receptanmodning eller en apoteksbestilling.

I FMK 1.4.4 (og tidligere versioner) har Dosage elementet kunne indeholde et Structures element med en eller flere understrukturer (fx for flere doseringsperioder), hvor de enkelte doseringselementer enten kunne være fast (implicit) eller efter behov (ved angivelse af et IsAccordingToNeed element). Man har også kunnet anvende strukturen således, at faste doseringer og doseringer efter behov var adskilt i separate understrukturer. Denne anvendelse har været anbefalet i en periode.

I FMK 1.4.6 er strukturen ændret, så adskillelse mellem fast og efter behov er helt eksplicit. I stedet for et Structures element kan man i 1.4.6 have først et StructuresFixed og derefter et StructuresAccordingToNeed element. Indholdet af disse svarer til indholdet af det tidligere Structures element, bortset fra at der ikke kan angives IsAccordingToNeed inde i understrukturen.

Der er i FMK 1.4.6 introduceret en ny metode til at angive samtykke til visning af privatmarkerede data.

Hvor man i tidligere snitflader har gjort brug af specifikke XML elementer i den enkelte request (eksempelvis <NegativeConsent>), så angives samtykke nu i SOAP request headeren. Princippet åbner bl.a. mulighed for at der fra centralt hold kan stilles krav om samtykkeangivelse i forbindelse med vilkårlige servicekald til FMK, uden at dette påvirker skemaerne for de services der kaldes.

Den nye metode er gældende fra 1.4.6, hvor det samtidig er den eneste måde at angive samtykke på idet de tilsvarende XML request elementer samtidigt er fjernet fra skemaet.