FMK Teknik

Hej,

Indenfor den næste halve time opdateres recept-modulet på TEST1. Opdateringen sker uden nede-tid.

Mvh,
FMK-teamet

Hej,

Indenfor den næste halve time opdateres recept-modulet på TEST1. Opdateringen sker uden nede-tid.

Mvh,
FMK-teamet

I løbet af næste uge udrulles et nyt recept-modul i Test 2 miljøet, og FMK vil herefter anvende dette i stedet for IBM's PEM/ReceptServer. Vi har endnu ikke fastlagt et bestemt tidspunkt, men vil gerne have denne udmelding ud alligevel, og så vende tilbage med et præcist tidspunkt når det er fastlagt.
 
Det nye Recept-modul har været anvendt i Test 1 miljøet siden starten af marts, jvf. denne udmelding: http://www.fmk-teknik.dk/index.php?topic=500.0

Tidsplanen er sådan, at det nye Receptmodul forventes sat i drift i den sidste halvdel af september. Det er derfor nødvendigt, at vi kommer på Test 2 miljøet som annonceret her. Når det nye Receptmodul er taget i anvendelse, vil der ske en udfasning af PEM/Receptserveren. Den komplette udfasning ligger dog grundet flere omstændigheder lidt længere ude i fremtiden.  Der vil dog ikke i denne forbindelse være ændret adfærd for FMK’s serviceaftagere.

De recepter på 909 specifikke CPR-numre, som hidtil har været gemt i PEM og været tilgængelige i FMK, vil blive replikeret, så de også efter denne ændring er tilgængelig via FMK.  Øvrige recepter, som kun har eksisteret i en slags "FMK cache" forsvinder desværre, og må oprettes påny efter behov.  Se detaljer om hvilke CPR-numre, der er hhv. i FMK + PEM og i "FMK cache" i denne udmelding: http://www.fmk-teknik.dk/index.php?topic=414.0

Der arbejdes på at tilvejebringe en simpel testklient på testmiljøerne, som kan bruges til bl.a. selv at ekspedere recepter sådan som apotekerne gør.  Vi vender tilbage senere, når vi kender en dato for hvornår denne testklient kan gøres tilgængelig.

Efter næste efterfølgende FMK deployment vil det ligeledes være sådan, at hvis man udfører et "Reset" i FMK's Dump-Restore regi, så vil recepterne i modsætning til tidligere også blive fjernet.  Selve "Dump" og "Restore" operationerne omfatter dog endnu ikke recepterne!

Trifork sørger for, at de recepter / udleveringer, der indgår i certificeringsregnearket etableres i Receptmodulet inden forbindelsen til PEM/Receptserveren på Test 2 miljøet bliver klippet.

Vi er opmærksomme på, at sletning af eksisterende recepter umiddelbart kan byde på udfordringer. Det er dog ikke et problem for de fleste klienter at oprette nye recepter.

Såfremt I har kommentarer til ovenstående er I velkomne til at kontakte os (fx Ellen på email els@trifork.com).  Vi vil da forsøge at afhjælpe akutte udfordringer, således at jeres udviklings- og testplaner ikke generes af ovenstående.

I forbindelse med reimplementeringen af apotekersnitfladen i FMK-regi er der dukket en problemstilling op, som vi gerne vil have at apotekssystemleverandørerne tager stilling til.

Tidligt i implementerings-processen stillede vi et spørgsmål angående brugen af servicen "Hent adresserede recepter" og den tilhørende "Kvitter for modtagelse" service. Nemlig, hvorvidt kvitter servicen altid kaldes med feltet MarkInProgress=true. Svaret var dengang ja.

Dette brugte vi til at konkludere, at der ikke var noget til hinder for, at en adresseret recept sættes under behandling straks ved oprettelsen, i stedet for at vente til "Hent adresserede recepter" servicen bliver kaldt eller til "Kvitter for modtagelse" servicen bliver kaldt, idet apoteket således bare får lås på ordinationen lidt hurtigere på den måde. Vores motivation for at ville dette er af teknisk karakter, og det er for kompliceret til at forklare her, men hvis konklusionen ikke holder skal der bruges noget tid på at ændre implementationen og det vil desværre medføre forringelser på andre punkter: Dels performance/belastning/svartid og dels konsistens i form af at "Kvitter for modtagelse" i fejltilfælde risikerer være delvist men ikke helt gennemført.

Dybt inde i implementeringsprocessen er vi blevet opmærksomme på at "Hent adresserede recepter" service har et ekstra felt ud over "AddressedToLocationNumber", nemlig "MarkInProgressAtLocationNumber". Hvis disse numre ikke er ens når servicen kaldes holder vores konklusion fra før måske ikke!

Derfor vil vi gerne høre fra alle 3 leverandører:

  - Er der tilfælde, hvor I bruger servicen "Hent adresserede recepter" med to forskellige lokationsnumre til hhv. "AddressedToLocationNumber" og "MarkInProgressAtLocationNumber" ?

  - Hvis ja, kan i forklare præcis hvilken use case det bruges til?

Så vidt vi har forstået, så er det beregnet til når serveren på et hovedapotek kalder PEM på vegne af en filial, og derfor henter recepter, der er adresseret til filialen.

  - Men ville der i dette tilfælde være noget til hinder for at bruge filialens lokationsnummer i begge felter, så disse recepter sættes under behandling på filialens lokationsnummer?

Dette ville gøre at vi ikke har et problem.

Alternativt kunne man forestille sig at løsne op omkring definitionen af at en ordination er "låst" til det apotek der har den under behandling. Det kunne fx løsnes op til at ordinationen er låst på apoteksnummeret for det apotek, hvis lokationsnummer recepten var adresseret til. Dette apoteksnummer er nemlig - så vidt jeg ved - ens for hovedapoteket og dets filialer. Det betyder at når en ordination er "låst" til et hovedapotek eller en filial vil både hovedapoteket og alle filialer kunne ekspedere på ordinationen! Tanken er, at hvis det tekniske setup er sådan, at apoteket bruger hovedapotekets server til at kalde PEM, så kan denne måske også sikre at der ikke ekspederes fra det forkerte af hovedapoteket og filialerne? Det forekommer i hvert fald naturligt, at denne problematik er uændret uanset om både hovedapotekets og filialernes lokationsnumre kan accepteres ved en ekspedition, i forhold til hvis det samme hovedapotek og dets filialer konsekvent anvender hovedapotekets lokationsnummer til låsning af ordinationerne.

Det alternative forslag vil krævde kodeændringer hos os, og sandsynligvis mere test både på vores og jeres side. Men det giver ikke de omtalte forringelser på andre punkter.

Vi håber derfor - med jeres accept - at kunne afvige lidt fra snitfladebeskrivelsen på dette punkt.

I vedhæftede dokument beskrives nogle planlagte ændringer til FMK, som bl.a. skal tilgodese et behov for at såkaldte behandlersygeplejersker kan regulere dosering af patienters medicin i henhold til instruktioner fra den instruksansvarlige læge.

Ændringerne beskriver under følgende overskrifter:

• Udvidede beføjelser til lægens medhjælp og tandlægens medhjælp
• Mere fleksibel rolle-rettighedsmodel
• Strengere validering

Evt. kommentarer modtages gerne meget hurtigt, da implementering af ændringerne igangsættes umiddelbart, og planlægges idriftsat 1. marts.

Vi er lige nu i gang med at opdatere FMK med en hotfix release som fixer et potentielt sikkerheds-issue.

Opdateringen giver ikke anledning til nedetid, og skulle ikke berøre nogen på andre måder heller.

Efter deployment af ny FMK-online version i går mellem 13:00 og 14:30 er der opstået et problem, hvor assistenter ikke kan logge ind på vegne af en læge eller en anden autoriseret bruger.

Vi arbejder på at løse problemet så hurtigt som muligt!