FMK Teknik

Hej,

Recept-modulet er netop blevet opdateret til v1.0.10 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

Hej,

Recept-modulet er netop blevet opdateret til v1.0.3 på TEST2. Opdateringen skete 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

FMK recept-modulet opdateres uden nedetid på Test 2 miljøet i dag, forventet mellem kl. 11:00 og 11:30.

Det kan man ikke i FMK.

Apotekerne har nogle andre servicekald til at fremsøge recepter ud fra andre kriterier.

Vi nåede ikke at gennemføre ændringen i sidste uge, som annonceret, men nu er ændringen gennemført.

FMK og FMK-online vil derfor anvende FMK's eget recept-modul på Test 2.

Det er desuden sat op, så ændringer der laves i recept-modulet også replikeres over til PEM.

Bemærk: I en kort periode kører der faktisk replikering begge veje, og dette kan medføre at data som ændres flere gange i træk kan ændres et skridt "tilbage" igen når de første ændringer replikeres rundt, indtil de sidste ændringer også når frem!

Inden længe vil trafikken fra apotekersnitfladen på IBM's "ekstern test 2" miljø ligeledes blive ledt over til FMK recept-modulets tilsvarende apotekersnitflade.

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.

Flere har efterspurgt en komplet liste af fejlkoder.

Vedhæftet er den komplette liste, ganske vist i et lidt "råt" format, idét listen er klippet direkte fra vores kode.

Bemærk at enkelte linjer med fejlkoder er udkommenterede, fordi de er kendt fra PEM men pt. ikke anvendes i FMK.

Og her er den anden præsentation.

Mvh Ulrik

Tak for svar, Thomas.

Der angives værdier flere steder. Dels i XML-dokumentet og dels i nogle HTTP form-parametre (user, localuser, password, pnumber, locationnumber og requestdata med XML).

Mener du at ekspeditionen indberettes til Apotekersnitfladens "Foretag ekspedition" service med hovedapotekets p-nummer (i både XML-delen af requestet og i HTTP form-parameteren), og filialens lokationsnummer (i HTTP form-parameteren)?
Dette skulle der ikke være noget problem i, der valideres ikke på p-nummer niveau.

Det vigtige er at HTTP form-agumentet locationnumber matcher det lokationsnummer, hvor odinationen er sat under behandling. Dette gælder både i PEM/ReceptServer og i vores implementation.

Angående dit spørgsmål - snitfladespecifikationen beskriver følgende om "Hent adresserede recepter":

QuoteDenne service returnerer de ordinationer der er adresseret til det pågældende lokationsnummer, hvor der
endnu ikke er kvitteret for modtagelse. Specifikt returneres ordinationer med status Åben, Delvist
udleveret eller Under behandling (under behandling forudsætter at ordinationen er låst af apoteket angivet
i parameteren AddressedToLocationNumber). Når ordinationerne returneres til receptursystemet sættes
ordinationernes status til "under behandling".

Vores ønske er, at sætte ordinationerne under behandling allerede når de oprettes som adresserede, i stedet for få minutter efter, når apoteker henter de adresserede recepter. Dette medfører samtidig den binding, at ordinationerne sættes under behandling på det lokationsnummer som recepten er adresseret til.

"Kvitter for modtagelse" servicen vil reelt ignorere feltet "MarkInProgress". Vi har tidligere fået afklaring omkring, at MarkInProgress altid sættes til "true" når "Kvitter for modtagelse" servicen kaldes.

Fra Apoteksdata har vi hørt at de altid anvender samme lokationsnummer til "AddressedToLocationNumber" og "MarkInProgressAtLocationNumber".

De udtrykker dog bekymring for om fx døgnapoteker bliver forhindret i at ekspedere ordinationer, hvis ordinationerne låses straks ved oprettelsen.

Til det kan man sige flere ting:

• Ordinationerne låses kun ved oprettelsen hvis den er adresseret - lægen kan undlade at adressere den, eller adressere den til det apotek, som patienten har tænkt sig at anvende
• Ordinationer kan låses op med det flow der starter med at kalde "Anmod om at frigive ordination"
• Om låsningen sker straks ved oprettelsen, eller indenfor de næste 5 minutter - når apoteket henter adresserede recepter og kvitterer for disse - giver i praksis samme opførsel

Vi mener derfor alle problemer kunne løses, hvis evt. hovedapoteker, der kalder på vegne af filialer, sørger for at anvende filialens lokationsnummer konsekvent til både "AddressedToLocationNumber" og "MarkInProgressAtLocationNumber".

Giv lyd, hvis i mener der er noget vi overser, eller hvis i mener denne løsning giver problemer for jer eller apotekerne!

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.

There has not been sufficient interest in using the SmartFraming solution.

One provider started using it, but abandoned that solution because of technical issues.

Therefore NSI has decided not to support SmartFraming.

DGWS specifikationen kræver at alle fejlsvar returneres med HTTP statuskode 500.

Jeg er enig i, at det i mange situationer signalerer noget andet end den reelle fejlbesked!