FMK Teknik

En disk var løbet fuld pga. en konfigurationsfejl, og så døde databasen.
Nu er både data og konfiguration restaureret, og databasen er kørende igen.
Dermed skulle fejlen gerne være rettet!

Kommende henvendelser af denne type bør gå til nsp.servicedesk@nsi.dk.

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

Vi er opmærksom på problemet.

Kan du leve med at vi finder en god løsning mandag, eller vil du meget gerne have et hotfix-hack i dag?

Ad 1: ITS er inkluderet i STS og NSP leverancer fra v1.5.

Ad 2: SOSIID har en begrænset tidsmæssig gyldighed (5 minutter), som er beregnet på at det anvendes én gang til at etablere en session og så ikke mere. Skal man bruge et igen, skaffer man et nyt.

Ja, det er korrekt. Og jeg har kendskab til nogen der gør det!
Men jeg kan pt. ikke helt gøre rede for hvordan requestet skal se ud.

Hej Leon,

"Sikker browseropstart" er en måde at foretage automatisk login i en browserapplikation ud fra et SOSI-idkort som haves enten i en klient applikation eller i en SOSI-Gateway, som klienten anvender.

I praksis skal man "veksle" sit SOSI-idkort til et "SOSIID", som reelt er et system-specifikt Identity Token, som beviser brugeren identitet men kun er gyldigt til brug i et bestemt system (fx FMK-online). Det gøres ved at kalde en separat Identity Token Service (ITS) på STS-serveren. Dette vekslingskald er en normalt DGWS kald, så SOSI-idkortet skal med i headeren, enten fra klienten eller fordi SOSI-Gateway sætter det på. Dette foregår på Sundhedsdatanettet (SDN).

Når man har fået sit SOSIID kan det anvendes ved opstart af FMK-online, som også beskrevet i den refererede tråd:

https://fmk-online.dk/fmk/sosiid?SOSIID=xxxxx#cpr=1234567890

Så logges brugeren automatisk ind og hvis #cpr parameteren også er med, vil FMK-online direkte slå op på den ønskede patient.

Et kald til ITS kan fx se således ud, hvis man kalder direkte fra en klient til ITS'en.
Der er nok forskel på angivelsen af idkort, hvis man kalder via SOSI-Gateway, men det kan jeg ikke lige specificere uden at undersøge nærmere først.
Herunder er XML-delen pænt opstillet (hvilket man ikke skal gøre i rigtige requests):


POST /sts/services/IdentityTokenService HTTP/1.1
SOAPAction: http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue
Content-Type: text/xml; encoding=utf-8
User-Agent: Java/1.6.0_31
Host: niab01.nsp-test.netic.dk:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 6439

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802">
<soapenv:Header>
<wsa:Action>http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action>
<wsa:MessageID>urn:uuid:de8e9776-b074-49fa-9572-b0b8cb8421d1</wsa:MessageID>
<wsa:To>http://niab01.nsp-test.netic.dk:8080/sts/services/IdentityTokenService</wsa:To>
</soapenv:Header>
<soapenv:Body>
<wst:RequestSecurityToken Context="urn:uuid:7d194b03-f9a1-47f3-a11a-ee6cb1424126">
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wst14:ActAs>
<saml:Assertion IssueInstant="2012-05-10T07:35:37Z" Version="2.0" id="IDCard">
<saml:Issuer>TESTSTS</saml:Issuer>
<saml:Subject>
<saml:NameID Format="medcom:cprnumber">2006271866</saml:NameID>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</saml:ConfirmationMethod>
<saml:SubjectConfirmationData>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyName>OCESSignature</ds:KeyName>
</ds:KeyInfo>
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2012-05-10T07:35:37Z" NotOnOrAfter="2012-05-11T07:35:37Z"/>
<saml:AttributeStatement id="IDCardData">
<saml:Attribute Name="sosi:IDCardID">
<saml:AttributeValue>QT0q6c2rZms8mnTLO5OlOA==</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sosi:IDCardVersion">
<saml:AttributeValue>1.0.1</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sosi:IDCardType">
<saml:AttributeValue>user</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sosi:AuthenticationLevel">
<saml:AttributeValue>4</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sosi:OCESCertHash">
<saml:AttributeValue>fWnwGlZ+b73DMkNIb2I7rzx5YJ8=</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<saml:AttributeStatement id="UserLog">
<saml:Attribute Name="medcom:UserCivilRegistrationNumber">
<saml:AttributeValue>2006271866</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:UserGivenName">
<saml:AttributeValue>Muhamad</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:UserSurName">
<saml:AttributeValue>Danielsen</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:UserEmailAddress">
<saml:AttributeValue>min.email@adatatest.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:UserRole">
<saml:AttributeValue>Doctor</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:UserAuthorizationCode">
<saml:AttributeValue>19901</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:UserOccupation">
<saml:AttributeValue>Overtester</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<saml:AttributeStatement id="SystemLog">
<saml:Attribute Name="medcom:ITSystemName">
<saml:AttributeValue>SOSITEST</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:CareProviderID" NameFormat="medcom:cvrnumber">
<saml:AttributeValue>25520041</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:CareProviderName">
<saml:AttributeValue>TRIFORK SERVICES A/S // CVR:25520041</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" id="OCESSignature">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#IDCard">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>QhHn/IAWralrd0Zlg/6RjYyALwA=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>e6cmnFygFtaWo6IMBAxekYFRI56+9szevPDi1mlsN8clDnrPGRRilro1D9ADc3AbeCOIm6ANqxJ3A0XaVA+wwJ8zVK4BZiuBxfAzhZ9gX//cK/ZBCQ9RtIKuzEa3VzsFRwCEUtYCdgMf9G9mINQD7RHtwJx6idFm/cz2BK7+FQk=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIFBjCCBG+gAwIBAgIEQDfroDANBgkqhkiG9w0BAQUFADA/MQswCQYDVQQGEwJESzEMMAoGA1UEChMDVERDMSIwIAYDVQQDExlUREMgT0NFUyBTeXN0ZW10ZXN0IENBIElJMB4XDTExMDkwMTEzNDAwOFoXDTEzMDkwMTE0MTAwOFowgYMxCzAJBgNVBAYTAkRLMSgwJgYDVQQKEx9EYW5za2UgUmVnaW9uZXIgLy8gQ1ZSOjU1ODMyMjE4MUowIQYDVQQDExpEYW5za2UgUmVnaW9uZXIgLSBTT1NJIFNUUzAlBgNVBAUTHkNWUjo1NTgzMjIxOC1VSUQ6MTE2MzQ0NzM2ODYyNzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnTc5xPDQBn95WZlY/yKH0vu4L0qOc9/M14bzAJEULYO55vqOYqSgFkOwPGqTwoK9Ajlqmn1zkdLBbwQYXRb+bEOSfJ+FTCvVo9IzKee0yQznJk0HZNTuuznpcoSybde1YXLrHupPxXUl2gNakmf65XczvE3E2J62hMYIM6Pxa9MCAwEAAaOCAsgwggLEMA4GA1UdDwEB/wQEAwIDuDArBgNVHRAEJDAigA8yMDExMDkwMTEzNDAwOFqBDzIwMTMwOTAxMTQxMDA4WjBGBggrBgEFBQcBAQQ6MDgwNgYIKwYBBQUHMAGGKmh0dHA6Ly90ZXN0Lm9jc3AuY2VydGlmaWthdC5kay9vY3NwL3N0YXR1czCCAQMGA1UdIASB+zCB+DCB9QYJKQEBAQEBAQEDMIHnMC8GCCsGAQUFBwIBFiNodHRwOi8vd3d3LmNlcnRpZmlrYXQuZGsvcmVwb3NpdG9yeTCBswYIKwYBBQUHAgIwgaYwChYDVERDMAMCAQEagZdUREMgVGVzdCBDZXJ0aWZpa2F0ZXIgZnJhIGRlbm5lIENBIHVkc3RlZGVzIHVuZGVyIE9JRCAxLjEuMS4xLjEuMS4xLjEuMS4zLiBUREMgVGVzdCBDZXJ0aWZpY2F0ZXMgZnJvbSB0aGlzIENBIGFyZSBpc3N1ZWQgdW5kZXIgT0lEIDEuMS4xLjEuMS4xLjEuMS4xLjMuMBcGCWCGSAGG+EIBDQQKFghvcmdhbldlYjAdBgNVHREEFjAUgRJkcmlmdHZhZ3RAZGFuaWQuZGswgZcGA1UdHwSBjzCBjDBXoFWgU6RRME8xCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxIjAgBgNVBAMTGVREQyBPQ0VTIFN5c3RlbXRlc3QgQ0EgSUkxDjAMBgNVBAMTBUNSTDI4MDGgL6AthitodHRwOi8vdGVzdC5jcmwub2Nlcy5jZXJ0aWZpa2F0LmRrL29jZXMuY3JsMB8GA1UdIwQYMBaAFByYCUcaTDi5EMUEKVvx9E6Aasx+MB0GA1UdDgQWBBQLXbSSnyHTIbP7jK5RemgCp28B2zAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjEDAgOoMA0GCSqGSIb3DQEBBQUAA4GBAIetUxFyQTFl5xNN/21EGk/U8r1/E5X/9oYLOdzOjzH3tV0al56vAovy+R16c4wjUwM3P6LPJeZeU0m5GyIGYdcbdZeNi0Z693XXcWvROfGEzOsTHe2T8j1tDu8DzY6mCVnXb8Q9aeY1G3hFLL70mE8rbtwVHgPdg3riuIbcdTXs</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml:Assertion>
</wst14:ActAs>
<wsp:AppliesTo>
<wsa:EndpointReference>
<wsa:Address>http://fmk-online.dk</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
</wst:RequestSecurityToken>
</soapenv:Body>
</soapenv:Envelope>


Jeg vil mene årsagen er forklaret her: http://www.fmk-teknik.dk/index.php?topic=125.0

Hej Daniel,

Ja, det er muligt. Det kan angives som således:

https://fmk-online.dk/fmk/#cpr=1234567890

I øvrigt er der også mulighed for at anvende SmartFraming på Mac via en Java-baseret SmartFraming-komponent.

Endelig er der også det relaterede koncept "sikker browseropstart" som kan bruges til at initiere FMK-online inkl. login overført fra et system som har et SOSI id-kort (eller anvender SOSI Gateway til at opbevare et SOSI id-kort). Med denne løsning kan man starte FMK-online med en URL som denne, og så få automatisk login, og starte på den ønskede patient:

https://fmk-online.dk/fmk/sosiid?SOSIID=xxxxx#cpr=1234567890

Dette er pt. konfigureret på visse testsystemer, men kommer på de øvrige testsystemer og i produktion indenfor kort tid.

Den centrale NSP, som LPS systemerne bl.a. skal bruge, er opgraderet til v1.5 på nuværende tidspunkt (de blev opgraderet en gang i januar).

De decentrale NSP'er, som regionernes EPJ systemer skal bruge, afventer deployment i henhold til regionernes indmeldingsønsker herom.

FMK anvender Seal v2.1.x i alle miljøer nu og skulle således være forberedt på at der på et tidspunkt kommer MOCES2 baserede id-kort.

STS'en understøtter det som nævnt fra v1.5 som - mig bekendt - endnu ikke er deployed i produktion.
Leverancen er vist løbende blevet udvidet og derfor også udskudt. Og der er visse problemer med at etablere ordentlige NSP 1.5 testmiljøer med sammenhængende testdata.
Men jeg mener at NSP 1.5 ikke desto mindre kommer i produktion inden længe.

Den formelt set rigtige at spørge er nok NSP servicedesken som håndteres af NetDesign som træffes via mail nsp.servicedesk@nsi.dk eller telefon 7222 8601.

Jeg prøver desuden at forhøre mig hos CapGemini - jeg skal nok vende tilbage hertil når jeg får svar.

Ok, nu forstår jeg. Jeg vil sørge for at dit forslag om yderligere services til at vedligeholde bemyndigelser tages op til diskussion/prioritering.

De nye rettigheder vil slå igennem i alle snitflade-versioner. Det forudsætter blot at rollen specificeres korrekt - i modsat fald vil kaldet blive afvist (når den fulde validering sættes i funktion).

Paul: Jeg forstår ikke hvad du antyder. Hvad er det man ellers kunne ønske sig?

Mit første svar var vist lidt for kortfattet.

Det betyder, at der sandsynligvis kommer en eller flere services til at forespørge på hvilke rettigheder brugeren har.
Således vil systemerne kunne enable/disable funktionalitet for brugeren på basis af, om de afledte kald til FMK vil kunne gå igennem.
Vi arbejder i øjeblikket med at fastlægge form og funktion af disse services, så vi kan ikke sige så meget endnu om hvordan de helt præcis vil blive.

Men der er ikke nye services med i det, som offentliggøres den 1. marts.
Det er ikke fastsat hvornår snitflade version 1.2.6 releases, og dens eksakte indhold ligger heller ikke fast endnu.

Med snitflade version 1.2.6 er der planlagt en (eller måske flere) services til at spørge på rettigheder.

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.