Dosisdispensering i 1.6.0 inkludere en del ændringer, for at flytte over til den nye delte model for planlagt administration. Indholdet på det nye dispenseringskort, som vil erstatte dosisdispenseringskortet, vil minde meget om det nuværende DD-kort, men enkelte elementer er fjernet, og enkelte elementer er tilføjet.

Herunder findes nogle billeder som opsummere ændringerne til DD-kortet som skal forventes at blive indført i 1.6.0. Forklaring til hver enkelt hoved-element kan findes i de forskellige afsnit længere nede på denne side.

Der vil fra FMK's side blive implementeret en del hjælpe-services for apoteket, i arbejdet med at rykke deres implementering fra workflower som anvendes i 1.4.6, til det workflow som forventes anvendt i 1.6.0.

En af disse vil være beregnet til at hjælpe apoteket med på en gang at flytte alt deres nuværende data, fra modellen i 1.4.6, til modellen i 1.6.0. Dette forventes at skulle kunne gøres med system-kald, og skal kun benytte PersonIdentifier og DoseDispensingCardIdentifier som input.

Formålet med denne service er som sagt at migrere data over i 1.6.0 modellen, så apoteket ikke behøver at bekymre sig om at skulle “genopstarte” alle deres kunder. Men samtidig er vil det blive en nødvendighed at det er apoteket selv som kalder denne service, og dermed foretager migreringen, således de først flytter data når de er klar til det.

DD-kortet bliver flyttet i sin helhed, de elementer som ikke længere supporteres i 1.6.0 (Se mere om dette længere nede på siden) fjernes, men det nye Dispenseringskort vil kunne beholde samme Identifier, såfremt dette bliver aftalen med apotekssystemerne.

PlannedDispensing migreres ved at den planlagte administration adskilles og flyttes over på det nye dispenseringskortet stadig tilknyttet den samme ordination som PlannedDispensing var. Den nye planlagte administration vil få en ny Identifier og Version, vi forventer ikke at genbruge Identifier her, da der ikke er tale om en “tilsvarende” entitet som ved Dispenseringskortet.

DD-perioder migreres IKKE, da Dispenseringsperioderne ikke har samme tilknytning som DD-perioderne har i 1.4.6.

Det vil blive nærmere aftalt med apotekssystemerne hvilke konsekvenser en migrering har, og om det skal være muligt at migrer flere gange.

NormalPeriodDuration er fjernet i forhold til 1.4.6, da den ikke er relevant i det nye workflow, hvor perioderne ikke oprettes på forhånd, da perioderne ikke længere er en separat entitet i forhold til dispenseringerne.

DoseDispenseableUnitLabel er ligeledes fjernet, denne værdi har altid været optionel, og vi kan ikke finde tegn på den har været benyttet som tiltænkt.

AnyPeriod er et felt som beskriver noget som ikke er en decideret DD-periode, men en oversigt over hvad der ville være inkluderet i en DD-periode, hvis den blev pakke i dette øjeblik. Den hentes ved at benytte AnyPeriod i RequestedPeriod når DD-kortet hentes i dag. Denne erstatter vi i 1.6.0 med en ny værdi som vi kalder AdministrationOverview.

AdministrationOverview er et nyt felt, som inderholder en liste af PlannedAdministration. Eksempler på dette kan ses i et andet afsnit.

DispensingOrganisation er et nyt felt, og vil være anvendt såfremt dispenseringskortet faktisk er ejet af hjemmeplejen el.lign organisation, feltet vil være udfyldt med organisations-informationer på samme måde som OrderedAtPharmacy er i dag.

Der er lagt op til ret store ændringer af hvordan apoteket håndtere DD-perioder i forhold til hvordan det gøres på 1.4.6. DD-perioderne vil ikke længere være noget som skal laves “up-front”, dvs de skal ikke længere oprettes separat. Det sker i stedet når dispensering registreres.

Der er enkelte ændringer i indholdet af Dispenseingsperioderne:

Status vil få nogle flere værdier, og nogle vil udgå. Den nuværende plan er at der indføres 1 status til når hjemmeplejen registerer deres fysiske ophældning, fx “Ophældt”. De nuværende status værdier Planlagt og Apoteksbehandling påbegyndt udgår. Med det nye workflow hvor perioderne ikke oprettes på forhånd, vil disse værdier ikke længere give mening.

Deadline elementet fjernes, værdien forventes ikke at give mening med det nye workflow, og med de ændringer som er forventet at blive implementeret i FMK vedrørende akut-håndtering, vil dette felt være overflødigt. Feltet har altid blot været en “kan jeg nå det” værdi, som ikke med det nye workflow giver mening, da det direkte kan ses ud fra hvad slutdatoen på den sidste DD-periode som er registeret på FMK er.

DetailedSpecifications Er en noget som returneres fra hent DD-kort servicen, såfremt der er bedt om det i input. Inholdet i dette element er data i et format som er tiltænkt pakke-apoteket og i sidste ende deres pakkemaskiner. Det har igennem tiden vist sig at være et ret tungt element at returnere i flere tilfælde, og tilføjer en den processingstid at danne, specielt i situationer hvor rigtig mange DD-perioder hentes på en gang. Det skal derfor forventes at hele funktionaliteten med at hente disse data, flyttes ud i en dedikeret service, som skal kaldes separat af pakke-apoteket.

Hvad der før blev kaldt for “planlagt dispensering” ændres til blot at være dispensering. Dette gøres både for at modellen passer bedre sammen med hjemmeplejens workflow, men også fordi dispenseringen er placeret et andet sted i apotekets nye workflow. Planlagt dispensering blev brugt fordi dispenseringen faktisk kun var planlagt, indtil DD-perioden skiftede status væk fra Planlagt. Når DD-perioden, og dens tilhørende dispenseringer, nu først oprettes når apoteket er klar til at sende en periode til pakkeapoteket, er det mere retvisende ikke længere at kaldet det “planlagt” da arbejdet med dispenseringen er gået i gang.

DrugMedication elementet er fjernet fra dispenseringen, men er “blot” flyttet et niveau ned, til den planlagte administration. Dette gøres igen for at signalerer at det er administrationen som er kædet sammen med ordinationen, og ikke nødvendigvis denne dispensering.

ValidPrescription elementet er også flyttet ned på den planlagte administration, mere om dette i dens afsnit.

TotalDispensedQuantity Er et navneskift af elementet som i 1.4.6 hedder TotalNumberOfDoseDispensedQuantity. Dette reflektere blot at Dispenseringen ikke længere nødvendigvis er Dosisdispenseret.

DoseDispensingEndDate Har skiftet navn og bliver også flyttet ned på den planlagte administration.

Planlagt administration overtager som hoved-element på dispenseringskortet i 1.6.0. Dvs når en ordination lægges ind på dispenseringskortet, vil det være i form af en planlagt administration og ikke en planlagt dispensation som i 1.4.6. Med dette bliver administrationen en separat etentitet, med sig egen Identifier og Version, det betyder også at de elementer som vi fjerner fra Dispenseringen i 1.6.0, flyttes herhen.

Identifer & Version elementerne er tilføjet administrationen i forhold til 1.4.6. Dette fastslår semantisk at den nu er sig egen etentitet, og er derfor adskilt fra dispenseringen.

DrugMedication LMO'en som administrationen er tilknyttet. Er indsat her efter den er fjernet fra dispenseringen.

ValidDispensingBasis Element som kan indholder en liste af forskellige udleveringsgrundlag. Hvor vi i 1.4.6 kun fra DD-recepter som validt udleveringsgrundlag for dosisdispensering, så vil der være flere muligheder i 1.6.0. Fx er DD sit eget dedikeret udleveringsgrundlag, men også Recept og Håndkøb skal forventes understøttet, og vil sikkert være egnet som udleveringsgrundlag for DD i 1.6.0.

Warning Element som også kendt fra 1.4.6. Men indført her af samme grund som øvrige element, så skal advarsler som primært har med administrationen at gøre, opstå her. Hvor ting som kun har med den enkelte dispensering at gøre, stadig opstå på Dispenserings' niveauet.

DispensingEndDate Elementet kendt som DoseDispensingEndDate i 1.4.6. Igen flyttet ned på Administrationen, da det ikke har noget med dispenseringen at gøre.

PlannedAdministrationOverview hoved-elementet som returneres såfremt det er det som blev angivet i sit request til at hente dispenseringskortet fra FMK. Inderholder en liste af PlannedAdministration og/eller en liste af PrivatePlannedAdministration.

PrivatePlannedAdministration Erstattet PrivatePlannedDispensing. DM-version vil ikke længere være optional, til gengæld fjernes Warning fra dette element. Da det ikke giver mening at kunne advarer på noget som personen ikke må se, faktisk kunne der være farer for at noget i Warning elementet kunne røbe detaljer som ikke bør overgives uden samtykke.

Der er en del ændringer i services i forhold til 1.4.6. Herunder findes en oversigt over services som enten udfases, har ændret funktionalitet, eller services som ikke ændres betydeligt.

Herunder er en liste af services som udfases, med en begrundelse.

Servicen Hent DD-kort var det første forsøg på denne service, og blev erstattet af hent eksplicit DD-kort. Denne service udfases nu permanent i 1.6.0.

Services som vedligeholder DD-perioderne som kendt fra 1.4.6 hvor perioder var separate entiteter fra dispenseringerne. Dette princip udfases i 1.6.0, og services dertil udfases derfor også.

Service indført i 1.4.6.E6, som en udvidelse af Hent pakkegruppe, hvor der returneres nogle ekstra detaljer. Denne service udfases da den ekstra detaljer i stedet flytter over i servicen Hent pakkegruppe igen.

Services vedrørende planned dispensings bliver alle udfaser og erstattet med nye dedikerede services til planned administration. De nævnes primært her og ikke under ændrede services fordi planned dispensings skal migreres og ikke blot flyttes over i 1.6.0.

Herunder er en liste af services som skal forventes opdateres i 1.6.0, og hvad der skal forventes ændret i forhold til 1.4.6.

Dosisdispenseringskortet udfases til fordel for Dispensingskortet i 1.6.0. Eftersom dispenseringskortet indeholder næsten alle af de nuværende felter, vil de nemt kunne flyttes over i den nye model i 1.6.0 uden nogen umiddelbar ændring i indholdet.

Historikken ændre sig ikke markant, men som nævnt tidligere udfases nogle elementer i 1.6.0, og disse vil derfor heller ikke kunne hentes med denne service. Der vil dog være understøttelse i servicen for at historikken hentes hen over 1.4.6 og 1.6.0.

Servicen bliver ret direkte erstattet af Hent Dispensingskort som nævnt i tidligere afsnit.

Nok den service som vil se de største ændringer fra 1.4.6 til 1.6.0. Servicen skifter ikke længere status på en allerede oprettet DD-periode, den validere om en periode kan startes og opretter en såfremt dette er tilfældet.

Det betyder i realiteten at DD-perioder opstår først når apoteket har taget alle opdateringer ind, og har klargjort alle data til pakkeapoteket. Hvis FMK finder fejl i det data som apoteket indsender, vil der ikke blive oprettet en periode, og fejlende som ligger grund til afvisningen returneres.

Det vil være et krav at eventuelle substitutioner som skal foretages i perioden af udleveringsapoteket, angives i input til denne service. I det fleste tilfælde vil der dog ikke være brug for at skifte fra det som pakke-apoteket anvendte sidste, så en markering om at FMK skal anvende seneste substitution vil blive understøttet. Input til alternativer er velkomne.

Det skal forventes at størstedelen af de nuværende valideringer og advarsler bibeholdes, medmindre de ikke længere er relevante p.g.a ændringerne i modellen. Hvilke advarsler som udfases/ændres vil blive beskrevet senere.

Nogle Warnings i 1.4.6 er blokerende, og med dette menes blokerende i denne service for at perioden kan sættes “Klar til pakning”. Det overvejes i 1.6.0 af Warning elementet udvides med et “Blocking” felt, som blot beskriver om denne fejl har været blokerende for at starte DD-perioden i 1.6.0. På denne måde kan apotekets-systemet nemmere markere hvilke fejl som minimum skal udbedres inden perioden kan sendes til pakkeapoteket. Input til dette er velkommende.

Afbrydning af DD-perioden skifter mening. Hvor man før kunne benytte denne service til at flytte status baglæns, vil den i 1.6.0 helt fjerne perioden. Servicen overtager ansvaret fra Slet DD-periode, og vil resultere i at perioden slettes fra FMK, sammen med dens tilhørende dispensering(er).

Afslut pakning forventes i 1.6.0 at inkludere substitutionen ved pakkeapoteket, det som der i 1.4.6 anvendes en dedikeret service til. For bedre at understøtte den nye datamodel og minimere workflowet, ønsker vi at flette disse 2 services i 1.4.6 sammen i 1.6.0.

Dette betyder at når pakkeapoteket sætter status til “Pakning Afsluttet” har de også mulighed for at angive en substitution til hver dispensering. Valideringerne fra den dedikerede substitutions-service vil blive inkluderet i 1.6.0 versionen af denne service.

Servicen er næsten uændret, dog er der gjort tanker om at indføre en Reason element i servicen. Denne bør benyttes ved apoteket til at markere en grund til at man vælger at kassere perioden. Denne Reason kan så ses når perioden hentes.

Servicen inkludere nu de nye elementer som blev tilføjet i E6's Hent indhold af pakkegruppe. Da vi ikke ønsker at have 2 service som henter næsten det samme data, udfases den service som aldrig er blevet anvendt, og de nye funktioner der var i den flyttes ind i denne service. Yderligere ændringer til denne service kan også blive nødvendigt for at hjælpe apoteket i det nye workflow, som muligvis ikke nødvendigvis er lige så godt understøttet af denne service længere.

Hentning af paknings overblik som primært gøres ved udleveringsapoteket lige før ekspeditionen. Det er vores forståelse at dette benyttes til at taksere indholdet i rullerne så en pris kan udregnes. I E6 blev der lavet en udvidelse af denne service i form at en nye service “Hent paknings overblik detaljer”. E6 servicen udfases, men forskellen mellem de 2 servicen tages ind i denne service i 1.6.0. Der vil dog være forskel i hvad servicen returene alt efter om der kaldes med MOCES eller FOCES certifikater.

En stor række af de services der i dag eksitere til DD, vil kunne flyttes med meget små eller ingen ændringer til in eller output.

Service som blev indført i 1.4.6.E6, og giver et hurtigt overblik over status for DD, eller mangel på samme, for en given person. Det overvejes om hvorledes denne skal generaliseres og både vise DD og Ophældt dispensering.

Også kaldet påbegynd pakning. Service anvendt af pakke-apoteket for at markere at de har overtaget kontrollen af perioden, og det kan forventes at den fysisk pakning påbegyndes snart. Vi ser ikke nogen umiddelbare brug for ændringer i denne service, medmindre de ændringer som er nævnt til Afslut Pakning af DD-periode ønskes flyttet til denne service af apoteks-systemerne.

Service anvendt ved pakkeapoteket, som “skubber” perioden baglens, og markere at apoteket har stoppet og ikke kunne fuldføre den planlagte pakning. Vi forventer ikke at skulle lave om i hvad der angives i en forespørgsel til denne service, ej hellere hvad kommer tilbage i output. Vi forudser dog at denne service vil kunne forsage en ændring i den planlagte dispensering som er oprettet til perioden, for at fjerne den substitution som pakkeapoteket muligvis har lavet.

Service anvendes ved udleveringsapoteket, og er det sidste led i workflowet omkring udleverings a DD. Signalere at den fysiske DD-rulle er blevet kørt igennem kassen og enten udleveret til patienten, eller er blevet overgivet til levering. De ændringer vi forventer at skulle lave til denne service, er relaterede til de andre ændringer som indføres i 1.6.0 om fx udleveringsgrundlag, hvis dette bliver en nødvendighed.

Service kan anvendes ved både udleverings eller pakkeapoteket. Benyttes såfremt en DD-periode allerede er blevet kasseret, og dette er gjort ved en fejl. Vi forventer ikke ikke at der vil være brug for at røre meget ved denne service, da dens omfang er ret lille i forvejen.

En liste af service til vedligeholdelse at pakkegrupper. Funktionaliteten omkring pakkegrupper forventes ikke ændret i 1.6.0, så vi forventer ikke at skulle ændre i disse services med mindre apotekets-systemerne kommer med ønsker.

Uploading af sortimentet for et givent pakkeapotek. Vi forventer ikke at lave nogle ændringer til denne service medmindre apoteks-systemerne ønsker det.

Primært en service til at kigge efter nye akutte perioden, som kan kaldes fast af pakke-apoteket med henblik på at disse opdages hurtigst muligt så perioderne kan pakkes. Servicen vil have blive påvirket af det nye workflow, da servicen før var afhængig af Deadline for en periode. Når deadline udfases i 1.6.0, vil det skulle afklares hvordan perioder skal udvælges i denne service.

Der vil være brug for en ny række services i 1.6.0 for at understøtte den nye DD-workflow, derudover vil nogle af disse services også være delt med fx hjemmeplejen når de skal foretage fysiske ophældninger hjemme ved borgeren.

Der vil bliver indført en nyn række services til oprettelse og vedligeholdelse af de planlagte administrationer. Indholdet af disse er beskrevet i afsnit ovenover.

I forhold til Hent planlagte administration er denne service også tiltænkt hentning af historike data. På 1.4.6 snitfladen findes op mod flere services som henter den planlagte dispensering, enten nuværende eller historik. Vi håber på at kunne undgå at skulle have flere services til dette for den planlagte administration i 1.6.0.

Det har været diskuteret flere gange om ikke det ville være optimalt at udleveringsapoteket kunne hente sortimentet igennem FMK, når nu FMK faktisk har disse data til sine valideringer. I første omgang blev dette skåret fra, men vi håber at kunne genintroducere det i 1.6.0. Dette ville sikre at udleveringsapoteket, som ikke nødvendigvis deler data med pakkeapoteket direkte, også kan få indsigt i hvilke lægemidler de kan forventes kan blive pakket.

Erstatter IncludeDetailedSpec på Hent Dispensingkort kaldet. Benyttes til at hente det format som er kendt i 1.4.6 til pakkeapoteket, som kan oversættes til det format som pakke-maskinerne ved pakke-apoteket benytter. Dette format er dog meget XML tung, og det er ikke ofte det faktisk skal benyttes. Derfor ønsker vi at flytte det ud af Hent dispenseringskort servicen, og ind i den dedikeret service hvor, given en specifik DD-periode, får dette format retur. Vi håber på dette vil gøre workflowet hurtigere, når unødvendige data ikke hentes flere gange.

Som en del af flytningen over på 1.6.0 formatet, vil vi i FMK udstille en service hvor DD-kortets udlevernings-apotek kan få migreret deres data fra 1.4.6 formatet, over i det nye 1.6.0 format. Dette forhindre at apoteks-systemener skal bruge tid på at udvikle funktionalitet til dette, når FMK nemmere kan håndtere denne flytning internt. Vi vælger dog at dette skal være en service, så udleveringsapoteket selv vælger hvornår de ønsker at overgå til 1.6.0 formatet.