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.

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.

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 det følgende forklares baggrunden for den ændring, vi har implementeret vedr. retransmission, samt nogle flere detaljer omkring, hvad der rent faktisk er implementeret. Der er blandt andet indført en ny fejlkode.

Den Gode WebService (DGWS) stiller nogle krav til klienter og serviceudbydere for at muliggøre retransmission. Følgende er hvad der står i standarden (v1.0 / v1.0.1) om retransmission:

Quote
Den Gode Webservice anvender HTTP som transportmekanisme mellem klientsystem og
serviceudbyder. Desværre kan HTTP fejle, og det er udefineret, hvad der skal ske, hvis
f.eks. klientsystemet aldrig får svar på en forespørgsel.

For at forebygge at dette sker, skal både klientsystem og webserviceudbyder forsyne hver
request og response med et unikt id for den pågældende meddelelse og med et FlowID,
der er unikt for hele den pågældende session.

   
• Alle afsendte meddelelser skal forsynes med et unikt MessageID, der aldrig må
  bruges til andre meddelelser igen af den pågældende afsender – heller ikke efter en
  geninstallation. Dog skal meddelelsen ved genfremsendelse bruge samme
  MessageID.
• Serviceudbyderen skal i første response i sessionen forsyne meddelelsen med et
  unikt FlowID (løbenummer) for den pågældende session.
• Klientsystem og webserviceudbyder skal genbruge FlowID'et i efterfølgende
  meddelelser i samme session.

For yderligere at sikre en robust kommunikation genfremsendes sikkerhedsoplysninger i
alle kald i den pågældende session.

Ved hjælp af disse mekanismer er det muligt for et klientsystem:

   
• at genfremsende tidligere fremsendte requests uændret, hvis et kald skulle blive
  afbrudt
• at springe et kald over, hvis klientsystemet allerede har de informationer, der er
  nødvendige for at benytte senere eller andre kald i webservicen.

Det er således serviceudbyderens ansvar at sortere dubletter fra og returnere svaret igen,
hvis en request med samme MessageID modtages.

I FMK har dette været tolket således, at det har været klienternes ansvar at anvende unikke MessageID's, og FMK har derfor gemt RequestXML og ResponseXML i en database under en nøgle bestående af klientens IP-adresse og MessageID. Dvs. hvis et nyt request kom fra samme IP-adresse og anvendte samme MessageID som et andet request der er mindre end 14 dage gammelt, så ville ResponseXML fra det tidligere request blive sendt som svar.

Dette er desværre sårbart overfor klienter, som anvender MessageID's der ikke er tilstrækkeligt unikke. Hvis samme et MessageID ved et uheld genbruges indenfor en 14 dages periode har man således fået et response retur, som kan stamme fra en anden bruger, patient og en anden type request!

Det er ikke ualmindeligt, at klienter fra samme leverandør rent netværksmæssigt tilgår FMK via leverandørens adgang til Sundhedsdatanettet, og dermed vil potentielt en stor mængde klienter fremstå for FMK som havende samme klient-IP-adresse. Dette forværrer problemet idét sandsynligheden for sammenfald af MessageID's forøges når der er flere requests i spil. Desuden kan man dermed også modtage responses der stammer fra fx en anden lægepraksis, der anvender samme systemleverandør.

Fra FMK v1.2.6.3 er praksis ændret med hensyn til retransmission, således at et request betragtes som en retransmission hvis:

(1) IP-adresse + MessageID svarer til et kendt request fra de sidste 14 dage
(2) SOAP Body er identisk i det gamle og det nye request

Hvis kriterie (1) er opfyldt men kriterie (2) fejler, så har klienten ikke overholdt sin forpligtelse om at anvende unikke MessageID's, og FMK kan rent teknisk ikke gemme et nyt request med samme IP-adresse + MessageID, da det er den betydningsbærende nøgle. Derfor er der indført en ny fejlkode i FMK til denne situation.

Den nye fejlkode har medcom:FaultCode=3002 og faultstring="Requestet genbruger msgId {0} som allerede er brugt i et ikke identisk request".

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.

De FMK instanser, der betjener FMK-online er blevet opdateret i dag mellem kl. 15:15 og 16:15.

Der har ikke været nedetide i forbindelse med opdateringen, men enkelte brugere kan have oplevet at måtte logge ind en ekstra gang.

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.

Så er der deployet en ny version af FMK-online igen, som løser problemer med login på vegne af andre.

God weekend

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!

På mandag den 5/12 mellem 12 og 14 vil FMK blive opdateret til version 1.2.4.12. Følgende rettelser er med i versionen.

- Problem med danske tegn i organisationsnavne
- Afdelingsnavne uden angivelse af hospitalsnavne i bl.a. print
- Fixet schemavalideringsnavn ved FMK-online opret/rediger LMO med erstatningsydernummer
- Fixet null-organisationsnavn for SuspendedBy, ModifiedBy m.m. ved brug af erstatningsydernummer

Bugs fixed

FMK-440: IllegalArgumentException: (drugStrengthValud and drugStrengthUnit) and/or drugStrengthText must be present
FMK-441: DrugMedicationIdentifierDoesNotExistException / NullPointerException fra CreateDrugMedication
FMK-442: Kommune-organisationsnavne mangler ordet "Kommune"
FMK-443: Skemavalideringsfejl cvc-pattern-valid: Value '1' is not facet-valid with respect to pattern '\d{13}' for type 'EAN13IdentifierType'
FMK-446: Fejl ved CreatePrescription i produktionssystemet 1.2

Opdateringen vil blive udført på 1 ud af 4 servere i første omgang. Efter at have konstateret at den nye version ikke giver problemer vil de øvrige 3 servere blive opdateret.

Opdateringen skulle ikke give anledning til driftsforstyrrelser eller nedetid.

På mandag den 28/11 mellem 9 og 11 vil FMK blive opdateret til version 1.2.4.11. Følgende rettelser er med i versionen:

- Håndtering af kommunekoder som organisationstype
- Korrekt håndtering af forældremyndighed
- Håndtering af erstatningsydernummer
- Ny udskrift

Bugs fixed

FMK-333    Fejl i WSDL vedr. SearchWithdrawnDrugMedications
FMK-355    DrugStrength sættes til enhed alene (uden value)
FMK-362    Recepter der er inaktive i PEM vises i FMK
FMK-364    Patientnavn skal stå på alle sider af FMK print
FMK-375    Ny forældre-barn SQL performer ikke
FMK-389    Dosisdispensering forsvinder på FMK-online i fællestest
FMK-408    Kommunekoder understøttes ikke korrekt
FMK-416    Skemavalideringsfejl vedr. takstversion (PriceListVersionDateType)

Opdateringen vil blive udført på 1 ud af 4 servere i første omgang. Efter at have konstateret at den nye version ikke giver problemer vil de øvrige 3 servere blive opdateret.

I FMK opleves i øjeblikket visse skemavalideringsfejl, som opstår internt i FMK når der genereres responses ud fra receptdata.
Vi arbejder på højtryk med at lave et hotfix, men vil gerne forsøge parallelt at indsamle kommentarer til de løsninger vi
har tænkt os at implementere. Hvis nogen synes, at en anden løsning ville være bedre hører vi meget gerne fra Jer.

IndicationCode '000000' hvor IndicationCodeType kræver værdier mellem 1-9999999.

Der er tilfælde hvor receptdata indeholder en indikationskode '000000', hvilket ikke er en tilladt værdi i skemaet.
I tilfælde hvor feltet er valgfrit vil vi udelade feltet.
I tilfælde hvor feltet er obligatorisk vil værdien '9999999' blive anvendt i stedet.

HospitalOrganisationIdentifier som ikke har formatet '[0-9A-Z]{4}|[0-9A-Z]{6}|[0-9A-Z]{7}'

Der er tilfælde hvor receptdata indeholde identifiers som ikke er valide SKS koder.
I tilfælde hvor feltet er valgfrit vil vi udelade feltet.
I tilfælde hvor feltet er obligatorisk vil værdien 'ZZZZ' blive anvendt i stedet.

ContactName blev fundet hvor StreetName eller PseudoAddress var forventet.

Dette er sandsynligvis en fejl i FMK's skemadefinition af DeliveryStructureType, hvor en choice mellem
StreetName og PseudoAddress burde have været valgfri og i stedet er blevet obligatorisk. I receptserverens
tilsvarende definition af Delivery er den tilsvarende choice valgfri.

Hvis vi mangler en adresse skrives "Ingen adresse" i PseudoAddress.

TelephoneNumberIdentifier som ikke har formatet '(\+)?[0-9]{3,20}'

Der forekommer telefonnumre som ikke umiddelbart har dette format, fx "12345678/1234" eller "12 34 56 78".
Først fjernes spaces (dette er ikke nyt). Hvis et prefix af det angivne telefonnummeret derefter har et korrekt format anvendes dette som telefonnummer.
Fx bliver "12345678/1234" til "12345678".
Hvis man ikke kan udlede et korrekt telefonnumer udelades feltet, hvis det er valgfrit, og ellers anvendes "000000".

ReceiptDosageText er længere end de 70 tilladte tegn

Når teksten er for lang trunkeret den til 70 tegn, som ender med "...".


PriceListVersionDate som ikke er på formatet for PriceListVersionDateType

Dette skyldes en forkert navngivet takstversion, og vi vil tage op med PEM Support hvordan der bedst kan rettes op på det.

FreeTradePackageSizeText fundet hvor PackageNumerIdentifier var forventet

Dette problem skal undersøges nøje. Pakkenummeret er essentielt for en recept. Hvis det ikke findes
er der noget rigtig galt. Vi bliver nødt til at vide hvor problemet ligger og hvis det er på
receptserveren må de rette op på denne mangel.

Det er nu muligt at anvende FMK-online med SmartFraming.

Her er referencer til yderligere information:

• Baggrund og motivation: http://digitaliser.dk/resource/766259
• Specifikation af konceptet: http://digitaliser.dk/resource/831249
• FMK-online's brug af SmartFraming: http://digitaliser.dk/resource/1882373
• SmartFraming .Net komponent v1.1: http://digitaliser.dk/resource/1883931
• SmartFraming Java komponent v1.1: (endnu ikke publiceret)

Login-metoden er via OIOIDWS-H Identity Tokens, som kan skaffes ved STS (v1.5+) der kan veksle et SOSI id-kort til et Identity Token. STS 1.5 er endnu ikke releaset, men man kan ved behov få adgang til en særlig test server som indeholder en release candidate.

SEAL.Net og SEAL.Java understøtter dette fra version 2.1.0 eller nyere. Denne er endnu ikke releaset, men hvis man har brug for en version straks kan en release candidate fås ved henvendelse til Trifork eller NSI.

Hermed understøttes også login for klienter, som anvender SOSI Gateway, idet det STS-kald som henter Identity Token kan instrumenteres med SOSI id-kort af SOSI Gateway.

Forløbig er dette releaset på et FMK testsystem, og den URL man skal ramme er følgende: https://fmkwebtest.trifork.netic.dk/fmk/smartframing.html

Vedhæftet til denne besked er en zip-fil med nogle centrale klasser, der viser hvordan SEAL.Net og SmartFraming .Net komponenten kan anvendes til login mod et FMK testsystem. Dette viser hvordan man kan få hul igennem, men skal sandsynligvis forfines på visse punkter for at kunne bruges i et produktions-setup.