FMK Teknik

Vedr. localsource feltet i FMK 1.6.0 - vil det også blive brugt ifm. en validering når der opdateres i FMK? Dvs. vi skal både have DrugId/Source/LocalSource siddende helt i skabet for at kunne gennemføre en update uden fejl?

/Mikkel Andersen

Hej.

Her er et eksempel hvor ovenstående forslag ville have gjort en stor forskel i smidig håndtering af fejlsituationer.

Den 11-03-2022 10:41:27.355 sendes MessageID f0e5e3d1-85b7-495e-ab16-ca7327d5cb6c som resulterer i en HTTP 500 med fejlkoden dcc_syntax_error.
Fejlkoden er nærmere beskrevet her https://www.nspop.dk/display/public/web/DCC+-+Guide+til+anvendere
og i vores øjne betyder det at vores applikation har sendt et ugyldigt request. Derfor parkeres kaldet i vores system og afventer manuel interaktion. I virkeligheden viser det sig at kaldet er korrekt udformet, men noget i DCC'en, eller deromkring, er gået galt, da vi senere kan afsende kaldet uden at have ændret noget.

Derfor vil jeg igen appelere til at en fremtidig FMK platform bruger HTTP statuskoder mere hensigtsmæssigt i stedet for at klassificere alt som HTTP 500.

/Mikkel Andersen

Hej.
P.t. returnerer FMK (1.4.6 E3) og hele økosystemet omkring dette i de fleste kald HTTP 500 "Internal server error", når noget fejler. Alt efter årsagen til fejlen kan man nogle gange finde uddybende fejlkode i FaultCode elementet. Hvis FaultCode elementet findes, kan dette indeholde koder der indikerer at indholdet i requested er ugyldigt (og fejler under valideringen) eller fejl fra DCC om timeouts osv.

Vi bruger i dag lidt krudt på at undersøge de mange muligheder for årsagen til fejlen når vi får en HTTP 500 og dermed forsøger at afgøre om det kan betale sig at sende requested igen efter en lille pause, eller simpelthen parkere det i en fejlkø, fordi indholdet ikke blev fundet validt af FMK.

Det ville være nemmere at afgøre om fejlen skyldes ugyldige data eller om der er et driftsproblem hvis:

• HTTP 400 (Bad request) returneres når vi ikke magter at sende valide data.
• HTTP 500 (Internal server error) returneres når der er tale om udfald i driften, så vi derved kan afgøre om vi vil prøve igen lidt senere.

/Mikkel Andersen

Hej.

Jeg synes princippet er godt, men da oppetiden på selve FMK ikke er vores største problem, ville det være godt med en tilsvarende service, hvor man, evt. med FOCES/VOCES, kan komme helt ude fra klientsystemet, gennem DCC/STS -> FMK. Det er nemlig systemerne før FMK vi oftest har problemer med, hvis man holder dem op mod hinanden.

/Mikkel

Hej.

Efter flere gode møder virtuelt, vil jeg foreslå at det bliver muligt at deltage virtuelt til dette møde i stedet for fysisk fremmøde, primært for at undgå transporttid.

Vil det være muligt?

/Mikkel

I forhold til indlæg fra Lisbet/Charlotte har vi ingen indvendinger.

/Mikkel

Hej.

1) Ok, såfremt det implementeres nøjagtigt som beskrevet.
2) Ok, såfremt det implementeres nøjagtigt som beskrevet.
3) Hvis grænsen ikke er en fast værdi på 8, så har jeg brug for mere beskrivelse af hvordan grænsen kommunikeres via FMK. Jeg tænker det må kræve en ændring til snitfladen hvis PA kan sætte denne værdi individuelt. Samtidig har vores UA'ere brug for tid, inden idriftsættelse af sådan en validering, så administration på forhånd kan tilpasses PA'ernes kommende begrænsninger.
Uddybning: Vi ønsker at valideringen i punkt 3 bliver en Medium i første omgang så UA'erne via deres valideringskørsler kan blive adviseret. Efter en aftalt periode, er det i orden med os, hvis den ændres til at blive blokerende ved Klar til pakning - men ikke i første implementering.

Venlig hilsen
Mikkel, Vitec Cito

Hej Søren.

Jeg kan se at det er nogle andre test endpoints der står i rapporten end dem vi bruger til FMK api'et. Er det kun browserbaseret adgang, altså FMK-online der lukkes for?

Her er nemlig et kald jeg har lavet til  test2-cnsp.ekstern-test.nspop.dk:8443   som går fint igennem - uden brug af de nævnte Ciphers eller TLS niveau.

Version: 3.1 (TLS/1.0)
Random: 60 36 7A 02 EC 4E CB EB AD A2 0D 93 C5 66 2E 51 E3 E6 C3 A5 C3 40 EA 15 86 E0 B8 99 17 5D 27 E6
"Time": 27-04-1971 03:29:04
SessionID: empty
Extensions:
   ec_point_formats   uncompressed [0x0], ansiX962_compressed_prime [0x1], ansiX962_compressed_char2 [0x2]
   supported_groups   sect163k1 [0x1], sect163r1 [0x2], sect163r2 [0x3], sect193r1 [0x4], sect193r2 [0x5], sect233k1 [0x6], sect233r1 [0x7], sect239k1 [0x8], sect283k1 [0x9], sect283r1 [0xa], sect409k1 [0xb], sect409r1 [0xc], sect571k1 [0xd], sect571r1 [0xe], secp160k1 [0xf], secp160r1 [0x10], secp160r2 [0x11], secp192k1 [0x12], secp192r1 [0x13], secp224k1 [0x14], secp224r1 [0x15], secp256k1 [0x16], secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
   SessionTicket   empty
Ciphers:
   [C014]   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
   [C00A]   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
   [0039]   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
   [0038]   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
   [C00F]   TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
   [C005]   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
   [0035]   TLS_RSA_WITH_AES_256_CBC_SHA
   [0088]   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
   [0087]   TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
   [0084]   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
   [C012]   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
   [C008]   TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
   [0016]   SSL_DHE_RSA_WITH_3DES_EDE_SHA
   [0013]   SSL_DHE_DSS_WITH_3DES_EDE_SHA
   [C00D]   TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
   [C003]   TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
   [000A]   SSL_RSA_WITH_3DES_EDE_SHA
   [C013]   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   [C009]   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
   [0033]   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
   [0032]   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
   [C00E]   TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
   [C004]   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
   [002F]   TLS_RSA_WITH_AES_128_CBC_SHA
   [009A]   TLS_DHE_RSA_WITH_SEED_CBC_SHA
   [0099]   TLS_DHE_DSS_WITH_SEED_CBC_SHA
   [0045]   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
   [0044]   TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
   [0096]   TLS_RSA_WITH_SEED_CBC_SHA
   [0041]   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
   [0007]   SSL_RSA_WITH_IDEA_SHA
   [C011]   TLS_ECDHE_RSA_WITH_RC4_128_SHA
   [C007]   TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
   [C00C]   TLS_ECDH_RSA_WITH_RC4_128_SHA
   [C002]   TLS_ECDH_ECDSA_WITH_RC4_128_SHA
   [0005]   SSL_RSA_WITH_RC4_128_SHA
   [0004]   SSL_RSA_WITH_RC4_128_MD5
   [0015]   SSL_DHE_RSA_WITH_DES_SHA
   [0012]   SSL_DHE_DSS_WITH_DES_SHA
   [0009]   SSL_RSA_WITH_DES_SHA
   [0014]   SSL_DHE_RSA_EXPORT_WITH_DES40_SHA
   [0011]   SSL_DHE_DSS_EXPORT_WITH_DES40_SHA
   [0008]   SSL_RSA_EXPORT_WITH_DES40_SHA
   [0006]   SSL_RSA_EXPORT_WITH_RC2_40_MD5
   [0003]   SSL_RSA_EXPORT_WITH_RC4_40_MD5
   [00FF]   TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Compression:
   [01]   DEFLATE
   [00]   NO_COMPRESSION

Hej. Jeg synes stadig det er muligt at gennemføre requests til FMK på TEST2 uden de nævnte ciphers. Er det implementeret?

/Mikkel Andersen

Hej.

Vi har gennemgået materialet og har talt med et PA og UA omkring mulighederne.

Det har afstedkommet nogle få kommentarer, som vi præsenterer her:
•   Vi antager at kortet oprettes med SORPERSON. Det kræver at både Cito og NNIT kan håndtere dette, hvilket for Citos vedkommende ikke er implementeret endnu.
•   Vil FMK selv danne nye perioder når de sættes klar til pakning? Hvis ja, er det så hensigtsmæssigt?
•   PA har oplyst at der er behov for en udløbsdato på sådanne poser, da de netop ikke er til specifikke dage. Skal det være en del af FMK snitfladen?
•   Skal vi tage højde for om PA kan håndtere det antal dage/poser (f.eks. 100 poser)? Vi har tidligere fået at vide fra NNIT PA'ere at de ikke ønsker perioder på mere end 14 dage, og da NNIT har oplyst at det ikke er en begrænsning i PharmaNet, så kan det være en fysisk begrænsning.
•   Er der noget vi skal være opmærksom på såfremt nogen kunne finde på at lave PN?

Venlig hilsen

Mikkel Andersen

Hej.
Jeg har læst på løsningsforslaget del 2 og har ikke andre kommentarer end at vi ser frem til at det implementeres.
/Mikkel

Tak for det. Hvornår forventes den at komme i PROD?
/Mikkel

Hej. Hvornår kommer versionen i PROD?
/Mikkel

Hej FMK. Vi har heller ingen problemer med den ene eller den anden løsning.
/Mikkel

Hej.

Da Cito i brugergrænsefladen ikke giver mulighed for at samme LMO knyttes flere gange til samme DD-kort, vil det være en fordel at FMK kan medvirke til at sikre at andre systemer heller ikke gør det. Det skyldes de tilfælde hvor et apotek med C2 overtager et DD-kort vedligeholdt i et andet system.

/Mikkel