FMK Teknik

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.

Deployment af FMK v1.2.4.12 i produktion er nu gennemført.

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 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.

Hej Preben,

Der er flere aspekter i det spørgsmål, du rejser. Svarene på de fleste aspekter burde i virkeligheden søges hos andre leverandører, men jeg vil alligevel gerne give mit bud her.

• MOCES2 understøttes af Seal.net og Seal.java fra version 2.0 og 2.1, som kan downloades nu.
• NSP og STS anvender Seal 2.1 og understøtter MOCES2 certifikater fra NSP version 1.5, som forventes i produktion i oktober/november 2011.
• FMK kommer i produktion med en Seal 2.1, og understøtter dermed MOCES2, i november 2011.

Leverandørerne står med følgende opgaver:

• at komme op og bruge Seal.net eller Seal.java i version 2.1.0 (eller nyere)
• at håndtere de nye MOCES2 certifikater på klienterne
• at anvende passende Seal API til at signere SOSI ID-kort
• at anvende passende Seal/STS API til at få en STS til at signere ID-kort

Med "passende API" menes, at der muligvis er tale om andre API-metoder end dem, der anvendes i dag, men det er nok et spørgsmål til LakeSide (Seal.java),  Silverbullet (Seal.net) eller Arosii (STS). Alternativt kan man jo kigge i dokumentationen for Seal.java, Seal.net, STS og/eller NSP.

For nogle vil disse problemstillinger formentlig løses via ny version af SOSI-Gateway.

DanID er som bekendt endnu ikke parat til at udstede MOCES2 certifikater, og der er mig bekendt ikke udmeldt en forventet dato lige pt.

Selv efter DanID bliver klar, kan det meget vel tænkes at IT & Telestyrelsen vælger at udskyde opstarten for udstedelse af MOCES2 certifikater indtil en "passende" mængde service providers (som FMK og andre) har erklæret sig kompatible med MOCES2.

Så selv om både vi og I bør gøre klar til at møde denne problemstilling, går der sandsynligvis endnu noget tid inden den bliver aktuel i praksis. Det er svært at sige noget mere præcist end det.

Venlig hilsen
Ulrik Skyt