News:

Velkommen til FMK Teknik

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - Ulrik Skyt

#1
Vi er blevet bekendt med at Receptserverens lokationsnummer (5790000155811) er blevet fjernet fra SOR, som er det autoritative register for lokationsnumre. Det skete 21.03.2018.

Det medfører udfordringer i nogle systemer, der genererer en liste med valide apoteker ifm. oprettelse af recepter.
 
Systemleverandører der er berørt af problemet kan evt. vælge at opdatere deres database manuelt, så de opretter det Lokationsnummer manuelt, som er blevet slettet i SOR.

Det skal endvidere oplyses, at recepter kan oprettes UDEN at der sendes et modtagerapotek. Der har blot været en sædvane om, at man i stedet for ikke at sende noget modtagerapotek har sendt lokationsnummeret for Receptserveren.

Fremadrettet vil der nok komme en proces, hvor vi beder alle om at oprette recepter uden strukturen til modtagerapotek i stedet for at angive Receptserveren som modtagerapotek, for lokationsnummeret kan sandsynligvis IKKE genoplives i SOR!


Med venlig hilsen
FMK-teamet
#2
Version 1.24 af Recept-modulet er netop deployet på Test1.
Versionen indeholder følgende ændringer:

- FMK-4306 Apoteksnitflade må ikke tillade ekspedition på fremdaterede recepter

Konkret er der en ny fejlkode på apoteksnitfladen, som man kan få når man påbegynder en ekspedition - dvs. når man kalder servicen GetMedicationByMedicationID med MarkInProgress=true.

Fejlkode: 206010
Overskrift: Fejl under påbegynd ekspedition
Beskrivelse: Recepten er ikke gyldig på nuværende tidspunkt. Recepten er gyldig i perioden fra {0} til {1}.

Hvor {0} og {1} erstattes af datoer på formen YYYY-MM-DD.

Mvh
FMK teamet
#3
Version 1.23 af Recept-modulet er deployet på Test2 i formiddag.
Versionen indeholder primært interne ændringer samt forberedelse til forbedringer i dump-restore (som bliver tilgængelig med en kommende version af FMK).

Mvh
FMK teamet
#4
Version 1.23 af Recept-modulet er deployet på Test1 i eftermiddag.
Versionen indeholder primært interne ændringer samt forberedelse til forbedringer i dump-restore (som bliver tilgængelig med en kommende version af FMK).

Mvh
FMK teamet
#5
Version 1.21 af Receptmodulet deployes på Test2 i formiddag.
Versionen indeholder primært interne rettelser, samt en enkelt bugfix til GetNewOrders på 1.4.6 snitfladen.

Mvh
FMK teamet
#6
Hej,

Recept-modul v1.20.5 blev deployet på TEST1 i fredags sent om eftermiddagen, og er lige nu deployet på TEST2.

Versionen indeholder kun ændringer der ikke bør give synlige ændringer, men er udelukkende af intern, teknisk karakter.

Mvh
FMK teamet
#7
Den nye FMK version, der blev deployed på TEST1 i går har fejl vedr. borgerlogin.

Vi arbejder på en løsning.

Mvh
FMK-teamet
#8
Hej,

Der er nu deployed en ny udgave af FMK-1.4.6.4 på TEST1.

Den fixer bl.a. nogle problemer med schemavalidering og IDWS signaturvalidering.

Mvh
FMK-teamet
#9
Der er netop releaset en ny version af FMK (v1.4.6.4) på TEST1. Tidligere version var 1.4.6.3.

Indhold og release datoer er også at finde på https://www.nspop.dk/display/web/Trifork+FMK+Releaseplan.


Mvh
FMK teamet
Modify message
#10
I dag releases Recept-modul v1.19 til TEST2, og i løbet af de næste uger foretages en række data-migreringer i Recept-modulets data.

Der vil ikke være nedetid eller ændret opførsel som følge af dette.

Mvh
FMK-teamet
#11
I dag releases Recept-modul v1.19 til TEST1, og over de næste dage foretages en række data-migreringer i Recept-modulets data.

Der vil ikke være nedetid eller ændret opførsel som følge af dette.

Mvh
FMK-teamet
#12
Som aftalt med apoteksleverandørerne og Apotekerforeningen har vi bestræbt os på at lave en "endelig" version af 1.4.6 snitfladen inden 1. februar 2017.

Det betyder at vi har samlet en række opdateringer af snitfalden, som udkommer med næste version af FMK. Denne version vil af samme årsag hedde "FMK 1.4.6.1", da vores versionsnummer-konvention siger at FMK versioneres i henhold til den seneste produktionsklare snitfalde-version.

Følgende liste beskriver schema-rettelserne i 1.4.6 snitfladen:

- Alle opdaterende requests har fået tilføjet en ModificationMetadata-struktur, ligesom øvrige opdaterende requests i FMK. Disse har hidtil ikke været anvendt til noget, men kan tages i brug til fx at have en "force" funktion så visse valideringsregler kan ignoreres. Der informeres særskilt om dette, såfremt denne mulighed tages i brug. Tilføjelsen af ModificationMetadata har i tre tilfælde krævet, at der blev introduceret en ny mellemstruktur, så request-strukturen er blevet en smule anderledes: Afvis/Annuller receptfornyelsesanmodning (CancelPrescriptionRequestRequest), Genåbn recept (ReopenPrescriptionRequest), Afslut recept (TerminatePrescriptionRequest).
- På visse opret recept request-strukturer er Drug-strukturdn flyttet ud fra PackageRestriction, så den i stedet ligger på Prescription-niveau. Det drejer sig om servicene Opret og ekspeder recept, Opret recept til brug i praksis og Opret recept til person uden CPR. Baggrunden er ønsket om at kunne anvende disse typer recepter i forbindelse med DD, også for lægemidler hvis varenumre ikke er kendte i FMK, fx præparater fra mærkevaretaksten.
- Servicen GetDoseDispensingCard og tilhørende schemaer er taget ud af 1.4.6 snitfladen - den vil i stedet blive udstillet i en 1.4.6.E2-snitflade.
- CreateAndEffectuatePrescription har ikke længere ValidFrom / ValidTo, da de ikke giver mening at specificere på en papirrecept, der skal være afsluttet straks ved oprettelsen.
- Recepter har ikke længere en struktureret dosering, kun en doseringstekst. Dette blev oprindeligt indført af hensyn til dosisdispensering, og tog reelt den strukturerede dosering fra den lægemiddelordination, som recepten var knyttet til. Men løsningen til dosisdispensering bliver lidt anderledes end først tænkt, så denne struktur giver ingen værdi. Desuden har instruksen til apoteksleverandørerne hidtil alligevel været, at de kunne nøjes med at vise doseringsteksten.
- Schemaer til AquireOrder service (anmod om frigivelse af recept) er slettet. Denne service er ikke relevant i 1.4.6.

De nye skemaer kan som sædvanlig findes her: https://github.com/trifork/FMKResources/releases/tag/1.4.6.1

Desuden ændrer vi en smule på, hvordan FMK sender SOAP Faults. De indeholder i dag nogle elementer under <details>, som er FMK-specifikke. Disse har i dag namespace sv.t. FMK v1.4.0, uanset hvilken snitfladen der kaldes på. Dette bliver fixet for 1.4.6, så 1.4.6-namespacet anvendes. Desuden er der i visse tilfælde problemer med at <faultstring> mappes ud efter <details>, hvilket er forkert iflg. SOAP 1.1 schemaet (på trods af at det er specificeret sådan i "Den Gode WebService" v1.0 / v1.0.1 standarden).

Vi regner med at deploye den nye version af FMK på TEST1 onsdag den 25. januar.

Mvh
FMK-teamet
#13
Vi har gennemgået beskrivelserne under "Scenarier for et apotek" på DokuWiki:

http://wiki.fmk.netic.dk/doku.php?id=apo:generel:scenarier:scenarier

Ud over lidt smårettelser er det primært præciseret hvordan dosisdispensering skal fungere i den første fase. Specielt vedr. dosisdispensering af ikke-lægeordineret medicin, der ligesom i dag håndteres helt udenom FMK. Desuden er der tilføjet beskrivelse af et fejl-scenarie vedr. udløb af ID-kort ved kø-processering.

Mvh
FMK-teamet
#14
I morgen, den 6. dec. forventer vi at release en ny version af FMK (v1.4.4.15.*) på TEST1.

Der er sket flg. ændringer siden FMK v1.4.4.14 (som forventes at komme i produktion i dag):


FMK-3505   IDWS skal enables for læger og tandlæger
FMK-3495   GetPermissionsRequest bliver afvist for borgere ved IDWS-kald på 1.4.6
FMK-3082   Problem med AssistantAuthenticator
FMK-2606   DosageLong tekst viser ikke "1 gang daglig" i longtext
FMK-3270   ASCP00087074 FMK fejl ved genoptag netop pauseret lægemiddelordination
FMK-3447   NPE på apotekersnitflade
FMK-3451   Forkert fejl ved oprettelse af papirrecepter uden indikation
FMK-3487   Substitution virker ikke ved effektuering i 1.4.6
FMK-3453   SpringWhitelistingParser (IDWS) er ikke trådsikker
FMK-3472   ASCP00089563 Dump/restore håndterer ikke udenlandske recepter
FMK-3482   NPE ved Print for LMO'er uden Drug form
FMK-3497   Sikre at kun Trifork CVR kan ændre rettigheder i AdmGUI
FMK-3504   ASCP00090173 Manglende fejlmeddelse ved Fjern Patientrelation
FMK-3369   Sikre at OrgUsingID matcher tilladt format
FMK-3407   FMK-3369 Sikre at OrgUsingID matcher tilladt format
FMK-3464   Udskift Jersey 1 med Jersey 2


En ændring i 1.4.6 er, at man i CreatePharmacyEffectuation ikke må angive SubstitutedDrug, hvis der samtidig angives et varenummer fra Medicinpriser.


Mvh
FMK teamet
#15
Til oplysning og påmindelse orienteres hermed om, at ændret opførsel vedr. "leveringsoplysninger på recepter skal afspejle den aktuelle bestilling" nu er enabled i produktion, jvf. tidligere udmelding: http://www.fmk-teknik.dk/index.php?topic=1007.0

Mvh
FMK-teamet
#16
På test2 miljøet er funktionalitet vedr. "Leveringsoplysninger på recepter skal afspejle den aktuelle bestilling" blevet enabled for et øjeblik siden, jvf. planen i dette tidligere opslag:

http://www.fmk-teknik.dk/index.php?topic=1007.0

Mvh
FMK-teamet
#17
I morgen, fredag den 30. sep. forventer vi at release en ny version af FMK (v1.4.4.13.*) og Recept-modulet (v1.16.4) på TEST1.

Der er sket flg. ændringer siden FMK v1.4.4.12 (aktuelle produktionsversion), hvoraf nogle dog allerede har været releaset til TEST1 og TEST2:

FMK-3094 Tillad kald af "Hent MedicinKortVersion" med VOCES
FMK-2998 ASCP00080169 DD recepter på LMO'er med fri tekst og AccordingToSchme fejler
FMK-3115 Håndtering af tidspunkter i doseringsperioder
FMK-3144 ASCP00082662 Sender vi forkert doseringstype ud på 1.4.0 snitfladen ?
FMK-3129 ASCP00084128: Tom PostCode mappes forkert
FMK-2958 ASCP00078113 Dosis-til-text: slutdato mangler i ugentligt gentagede doseringer
FMK-3017 Dosis-to-text oversætter NotIterated struktur med en enkelt dag forkert
FMK-3057 Validationsender: medicinecard20150101:PackageSize
FMK-3110 fix non-deterministisk hashCode impl for OtherPerson
FMK-3043 ASCP00081296: Fejl i valideringen af ReportedByFMK-3238
FMK-3015 ASCP00080346: EffectuationDateTime på GetMedicineCardVersions skal vise seneste ændringsdato for effektueringer og ikke blot dato for seneste effektuering
FMK-3188 Sendxml kald fra admingui er altid med 1.2.6 i service version
FMK-3172 Fjern muligheden for at angive receptordinations-ID i medicinanmodninger
FMK-3194 ASCP00085231 Fejl i pausering
FMK-3196 NullPointer pga. null DosageTimes
FMK-3199 Tilføj IDWS til manglende services i 1.4.6 snitflade
FMK-3197 ASCP00085242 DD recepter for fritekst / iflg. skema doseringer - startdato behavior
FMK-3069 ASCP00082124: MaximalQuantity validering accepterer ikke decimal som 0,5
FMK-2896 ASCP00075906 Print: fejlagtig markering af at doseringsdato er overskredet
FMK-3204 Håndtering af ny rolle Apoteksansat i FMK REST-lag
FMK-3206 Tilføj ny fejlkode til ukendt Idws Soap fejl
FMK-3179 EO funktionalitet: GetRequestedPrescriptions (ud fra CPR)
FMK-3238 ValidationSender ved GetOrderedEffectuations
FMK-3239 ValidationSender ved EffectuationOrdering svar
FMK-3228 POR Gensuspendering
FMK-3227 Periode-start kan mangle i longtext ifm. periodejustering
FMK-3230 AutomatedStartEffectuation implementering (ny service i FMK 1.4.6)
FMK-3253 Ændring til periodetekst
FMK-3083 NullPointerException i getNewOrders
FMK-3139 ASCP00084492 Validation sender
FMK-3220 NullPointer i SpecielPeriodHandling
FMK-3181 Understøttelse af recepter i DumpRestore

OBS potentielle brud på bagud-kompatibilitet:

- FMK-3172 Fjern muligheden for at angive receptordinations-ID i medicinanmodninger

WSDL til 1.4.6 er opdateret med nye services. Den tidligere WSDL er kompatibel med denne FMK version.
Her er links til de varianter af WSDL og schemaer der udgives, i en version der passer til denne FMK version:

- WSDL og skemaer, version 1.4.6: https://github.com/trifork/FMKResources/blob/1c42d2385103fbafdc838bf885033800792f5725/wsdl/MedicineCard_2015_06_01-collection.zip?raw=true
- WDSL med skemaer inline, version 1.4.6: https://github.com/trifork/FMKResources/blob/1c42d2385103fbafdc838bf885033800792f5725/wsdl/MedicineCard-inline_2015_06_01.wsdl.zip?raw=true
- IDWS WSDL og skemaer, version 1.4.6: https://github.com/trifork/FMKResources/blob/1c42d2385103fbafdc838bf885033800792f5725/wsdl/MedicineCard_Idws_2015_06_01-collection.zip?raw=true
- IDWS WDSL med skemaer inline, version 1.4.6: https://github.com/trifork/FMKResources/blob/1c42d2385103fbafdc838bf885033800792f5725/wsdl/MedicineCard-inline_Idws_2015_06_01.wsdl.zip?raw=true
#18
Baggrund
Visse felter på recepter i FMK har i dag en uhensigtsmæssig virkemåde. Det drejer sig om følgende felter, der samlet kan betegnes som leveringsoplysninger:

  • Delivery (priority, address / pseudo address, contact person)
  • DeliveryInformation
  • OrderInstruction
Hvis der oprettes en adresseret recept, og disse felter udfyldes, vil værdierne af dem ikke kunne genfindes hvis man henter recepten umiddelbart efter. Først efter der er sket en ekspedition på apoteket vil felterne fremgå på recepten i FMK.

Årsagen til dette er historisk. Dengang recepter blev hentet via en service i Receptserveren var det en begrænsning i servicen – disse oplysninger, som reelt vedrører en bestilling på apoteket, blev returneret som en del af udleveringsstrukturen, og derfor blev de først returneret når der var gennemført en ekspedition.

I FMK anvendes felterne efterfølgende altid fra den første udlevering, formodentlig fordi det oftest er oplysninger som lægen har angivet på den oprindelige recept, og derfor blev oplysningerne tænkt som værende en del af selve recepten. Oplysningerne er dog ikke nødvendigvis fra recept-oprettelsen, men kan være opstået ved fx at hjemmeplejen har anmodet om en udlevering på recepten via EffectuationOrdering-servicen. Men faktum er, at oplysningerne relaterer sig til en bestilling på apoteket, og måske endda er mindre relevante når først bestillingen er gennemført og der findes en udlevering (effektuering). Dvs. når man kan se dem i FMK, er de ikke så relevante længere.

Semantisk ændring af felter med leveringsoplysninger
Det aktuelle forslag går ud på at lave en semantisk ændring af disse felter i de eksisterende FMK snitflader (1.4.0, 1.4.2, 1.4.4 og 1.4.4 E1).

Felterne til leveringsoplysninger i snitfladen ændres til at afspejle værdier fra den aktuelle bestilling til et apotek. Således vil felterne være udfyldt hvis der foreligger en aktuel bestilling til et apotek (i det omfang felterne taget i anvendelse), og vil ikke være udfyldt når bestillingen er effektueret af apoteket. Feltet EANLokationsnummer på recepterne afspejler faktisk allerede i dag værdien på den aktuelle bestilling, og fungerer derfor allerede nu på den måde, der foreslås for leveringsoplysningerne: Det er udfyldt når der foreligger en aktuel bestilling, og siger i givet fald hvilket apotek, bestillingen er sendt til. Når bestillingen er effektueret, og der ikke længere foreligger en aktuel bestilling, så udfyldes feltet ikke.

Fra FMK snitflade version 1.4.6 vil der være en eksplicit entitet kaldet bestilling (Order), og den indeholder netop disse oplysninger (apotek + leveringsoplysninger). I 1.4.6 vil der dels være den aktuelle/åbne bestilling, som ikke er effektueret, og dels vil der være en bestilling for hver recept-effektuering.

At lave den foreslåede ændring retter dels op på den uhensigtsmæssighed, at lægen ikke kan se de leveringsoplysninger, som vedkommende lige har indtastet på en ny recept, og dels bringer den de gamle snitflader lidt mere på linje med den nye 1.4.6 snitflade, idet de kan levere flere oplysninger fra den aktuelle apoteksbestilling ud til øvrige brugere af FMK snitfladerne.

Dette er altså en semantisk ændring i snitfladen, idet felterne ikke længere forsøger at være indhold fra lægens oprindelige recept, men i stedet viser oplysninger fra den evt. aktuelle bestilling til et apotek.

Tidsplan
Denne ændring er implementeret og gøres tilgængelig efter følgende tidsplan:

  • Test1: 16. september 2016
  • Test2: 17. oktober 2016
  • Prod: 1. november 2016
  • Udd + Prodtest: (samme dato som prod)
#19
 
Der er i dag en udfordring vedr. annullering af recepter, fordi apotekerne ikke nødvendigvis opdager, hvis en læge har annulleret en recept, som de skal til at ekspedere, såfremt de allerede har den under behandling.

Problemstillingen har to sider. Apoteket må ikke ekspedere en recept, som ikke længere er gyldig, fx hvis en læge har annulleret den. Men hvis apoteket reelt er begyndt at ekspedere, bør lægen nok heller ikke kunne annullere recepten, da kunden er ved at tage medicinen med hjem. Hvis det er livsvigtigt at recepten annulleres og kunden ikke må få udleveret medicinen, må lægen tage direkte kontakt til apoteket/patienten.
I dag afspejler receptens status desværre ikke om recepten reelt er under behandling dvs. om ekspeditionen reelt er i gang ved skranken,  fordi en adresseret recept sættes under behandling fra det øjeblik den modtages på apoteket, og altså ikke først når apoteket begynder at ekspedere den. Den kan altså være under behandling i timer, dage eller uger! Det samme er gældende hvis fx hjemmeplejen har lavet en genbestilling på en reitereret recept. Og det ville ikke være godt, hvis lægen i et udefineret langt tidsrum forhindres i at annullere en recept på medicin som patienten ikke længere bør få.

Hvis apoteket  i dag ekspederer en recept, som lægen har annulleret og som apoteket ikke har opdaget er annulleret, så vil indberetningen fejle og købet vil derfor ikke fremgå af FMK.  Lægen tror at annulleringen havde den tilsigtede effekt, og kun apoteket ved at der alligevel blev udleveret medicin. I værste fald opdager apoteket ikke engang at indberetningen af udleveringen fejlede. Dermed tror alle at alt er som det skal være, selvom det modsatte er tilfældet.

For at imødekomme dette problem er der iværksat flere tiltag:

Pr. 1. juli 2016 er apotekerne pålagt at foretage elektronisk kontrol af recepter gyldighed inden der foretages ekspedition. Dette foregår ved at apotekerne kalder en servicen der hedder "påbegynd ekspedition", som foretager denne kontrol for dem.

Pr. 22. august (forventet) iværksættes en ændring som betyder to ting:


  • dels skal apotekerne udskyde det tidspunkt, hvor recepten får status "under behandling". I stedet for at recepten sættes under behandling så snart den er adresseret eller en udlevering er bestilt, så skal recepten først sættes under behandling, når apoteket kalder servicen "påbegynd ekspedition". Dermed forlænges det tidsvindue, hvor det kan lykkes en læge at annullere en recept, således at apoteket opdager det inden ekspeditionen og derfor undlader at ekspedere recepten.
  • dels vil læger opleve at få en ny type fejl, såfremt de forsøger at annullere en recept, der er under behandling på et apotek. Fejlbeskeden vil lyde således:

Recepten med id {0} er under behandling hos {1} - annulleringen vil derfor først træde i kraft når deres ekspedition er fuldført (eller afbrudt).

Dvs. annulleringen er reelt noteret på recepten, men træder først i kraft når den igangværende ekspedition er fuldført. Dette vil normalt være efter få minutter, men kan i visse særlige tilfælde være væsentlig længere tid. Hvis samme læge eller evt. andre brugere af FMK betragter medicinkortet efter denne delvist gennemførte annullering vil receptens status fortsat være "under behandling" indtil apoteket enten færdiggør eller afbryder ekspeditionen. Under alle omstændigheder vil status derefter være annulleret, uanset om apoteket har markeret at recepten skal afsluttes eller ej.

Såfremt lægen vurderer at det er vigtigt at bremse apotekets igangværende ekspedition, eller patientens efterfølgende indtagelse af medicinen, må lægen kontakte apoteket eller patienten!

For dosisdispenserede recepter indtræffer samtidig også nogle ændringer. Hver gang apoteket påbegynder ekspedition af en dosisdispenseret recept - hvilket typisk sker med 14 dages mellemrum - så skal apotekssystemet ligeledes kalde "påbegynd ekspedition" servicen. Herfra vil der typisk gå et par dage inden dosispakningen er fremstillet og den endelige ekspedition af recepterne foretages. I den mellemliggende periode har de dosisdispenserede recepter status "under behandling" og når ekspeditionen er gennemført får de igen status "overført til dosiskort". Læger kan annullere recepter til dosisdispensering imens status er "overført til dosiskort" idet apoteket da vil opdage det næste gang de påbegynder en ekspedition. Hvis lægen annullerer en dosisdispenseret recept imens den er under behandling, så annulleres recepten først efter apotekets ekspedition, og får derfor ikke virkning for den dosispakning, der er ved at blive pakket nu, men først når den efterfølgende dosisekspedition skal påbegyndes næsten 14 dage senere! Såfremt lægen vurderer at ændringerne skal træde i kraft tidligere end dette, skal apoteket, borgeren eller evt. hjemmeplejen kontaktes.
#20
Der er nu lagt en version 1.4.4.11.b af FMK på Test 1.

Mvh
FMK-teamet