FMK Teknik

For alle systemer, der ikke har søgt dispensation, er der nu aktiveret en validering af hvilken/hvilke OrgUsingID de bør anvende i Test1. Da vi kan se der er systemer som anvender den forkerte OrgUsingID type, venter vi med at aktivere valideringen i test2 en uge. Det giver mulighed for at test på test1 inden det bliver aktiveret på test2.
Problemer og spørgsmål skal indrapporteres som supportsager på NSPOP. 

Hej Henrik

Når jeres system anvendes af Region Syddanmark, er systemet et "Regionalt EOJ" system. Som tabellen viser, er det under afklaring hvad der skal anvendes. Indtil dette er afklaret, kan i fortsætte med at anvende CVR.

Dit spørgsmål angående "Registrer tilknytning" er Off topic, og vi må henvise til supportkanalerne.

Jeg har tilføjet Privatejet EOJ i listen, og indtil videre skal i anvende CVR på sådanne plejehjem som Mariehjemmene

Den 15. august blev validering af OrgUsingID aktiveret på testsystemerne, som annonceret på http://www.fmk-teknik.dk/index.php?topic=937.0. Formålet med valideringen er som bekendt at ibrugtage den nationale Behandlingsrelationsservice (BRS), og dermed forebygge misbrug af FMK.

Det blev hurtigt klart at der var mange systemer, der ikke anvendte OrgUsingID korrekt, og selv om flere systemer var i stand til at korrigerer deres anvendelse hurtig, var der også systemer, der ikke ville være i stand til at gennemføre de nødvendige rettelser, inden for en overskuelig tidshorisont. Valideringen blev derfor rullet tilbage, således at disse systemer ikke blev blokeret på testsystemerne.

På april teknikkermødet, såvel som på annonceringen på FMK-Teknik, blev det pointeret at man skulle anvende samme Id i OrgUsingID, som den Identifier der angives i modifikator. Men testen viste at flere systemer havde valgt at anvende CVR i OrgUsingID i stedet for Ydernummer, SKS eller kommunekode. CVR er, f.eks. for en region, ikke tilstrækkelig til at verificerer en behandlingsrelation, og kan derfor ikke anvendes til OrgUsingID.

Nedenstående tabel angiver hvilken type OrgUsingID, der skal anvendes for de forskellig typer systemer. Såfremt der er systemer, der ikke er angivet i nedenstående tabel, kan man lave en supportsag og få afklaret hvilken type der skal anvendes.  De systemer der er angivet med et ?, angiver at det korrekte Id er under afklaring, og afventer beslutning fra de respektive organisationer.

System	Identifier
Regionalt EPJ system	SKS, 6 eller 7 ciffer. Nogle regioner har selv opfundet 8.   og 9. ciffer. Disse ekstra ciffer ignoreres af FMK og kun de første 7   anvendes. SKS valideres op imod SOR og SHAK.
Privatklinik med SKS kode	SKS, 6 eller 7 ciffer. SKS valideres op imod SOR og SHAK.
LPS	Ydernummer valideres op imod yderregisteret
Vagtlæge systemer	?
Kommunalt EOJ	Kommunekode, valideres op imod kendte kommunekoder
Regionalt EOJ	?
Privatejet EOJ	CVR
Tandlægesystemer	Ydernummer, der valideres op imod yderregisteret. For   klinikker uden ydernummer anvendes CVR, der valideres op imod det anvendte   certifikat.
Apoteker systemer	EAN Lokationsnummer, valideres   op mod SOR
Kommunalt bostedssystem	Kommunekode, valideres op imod kendte kommunekoder
Regionalt bostedssystem	?
Special klinikker uden yder eller SKS	?
Systemkald, regional PAS systemer	SKS, 4, 6 eller 7 ciffer, valideres op imod SOR og SHAK.
Borgerrettede systemer	Ingen krav om angivelse af organisatorisk tilknytning.   Anvend BorgerOpslag

Ovennævnte tabel vedligeholdes fremadrettet på http://wiki.fmk.netic.dk/doku.php?id=fmk:generel:systemautorisation#orgusingid

For at sikre kvalitet i OrgUsingID udvides valideringen, således at det også checkes at typen af den Identifier matcher ovenstående tabel. Hvis ikke fejler kaldet. Da enkelte systemer leverer løsninger til flere typer organisationer er det muligt at blive godkendt til at anvende flere typer OrgUsingID.

For at få bragt projektet videre er følgende plan blevet udarbejdet.

7. december 2016. Den udvidede validering enables på testsystemerne. De systemer der ikke er klar til dette, skal i en supportsag angive at de ikke er klar til denne validering, samt hvornår de så er klar. Såfremt denne data er acceptabel for dataejeren, vil systemerne blive undtaget for validering indtil denne dato, hvorefter valideringen enables.

10. januar 2017.  Den udvidede validering enables i produktion. Igen kan de systemer, der ikke er klar, undtages af valideringen, ved at oprette en  supportsag, med angivelse af hvornår de vil være klar. Samtidig ibrugtages behandlingsrelationsservicen, hvilket betyder at brugerne af de systemer, der ikke anvender korrekt OrgUsingID, vil af behandlingsrelationsservicen blive flaget, som have lavet uberettiget opslag, og vil derfor være kandidat til manuel kontrol af misbrugskontrollen.

Med FMK 1.4.0 er det blevet muligt for borgeren at udføre handlinger i FMK. Pt. har borgeren mulighed for at kunne sætte og ophæve privatmarkeringen på en lægemiddelordination, samt at kunne anmode om recepter på eksisterende lægemiddelordinationer. Hvor privatmarkeringen ikke giver ændringer af informationen i medicinkortet, ud over selve privatmarkeringen, er det anderledes for receptanmodninger, hvor borgeren står som opretter af anmodningen.

Der er rejst bekymringer om hvorvidt alle systemer tydeligt viser om en receptanmodning er borger-initieret og har mulighed for at skelne disse fra receptanmodninger initieret af hjemmeplejen. Derfor beder vi alle systemer, at indsende dokumentation for deres visning af borger initierede handlinger. Der er på test2 oprettet testdata til at teste dette. På testpatient 030775-2106 ligger der en receptanmodning på Cilest ordinationen. Der skal indsendes data for listevisningen af receptanmodninger samt detaljevisningen af anmodningen.
I bedes sende skærmbilleder retur til els@trifork.com senest mandag den 7. november 2016, hvor jeres systemnavn indgår.
 
På vegne af Sundhedsdatastyrelsen

Jan Buchholdt

Det er planen, såfremt der ikke er nogen der finder problemer med løsningen.

Forslaget er nu også tilgængelig på test2.

Med FMK 1.4.6 er der indført en ny samtykke header <ConsentHeader> til at markere, at der er givet samtykke eller der er anvendt værdispring for at se privatmarkerede data. Denne header har erstattet <NegativeConsent> elementet på hent lægemiddelordinationer. Beskrivelsen af headeren kan ses på http://wiki.fmk.netic.dk/doku.php?id=fmk:1.4.6:soap_header_--_specifikt_omkring_samtykke

Formålet med at anvende en header er dels at åbne mulighed for nye typer samtykker, der ikke kun er relevant for lægemiddelordinationer, samt at åbne op for at øvrige ”hent” services kan udvides til at omfatte eventuelle privatmarkerede oplysninger.

Anvendelsen af den nye <ConsentHeader> kunne eksempelvis være at et apotek har fået samtykke til at udføre en medicingennemgang, eller at en borger, gennem den kommende fuldmagtsservice, har givet en anden borger eller organisation fuldmagt til at håndtere sin medicin.

Den nye header kan allerede nu testes på test1 og test2, og WSDL’erne er opdateret med den nye header.

Det er også muligt at anvende <ConsentHeader> med ældre snitflader, til at angive samtykke eller værdispring, i stedet for <NegativeConsent> elementet. Det er dog ikke muligt at både have <ConsentHeader> og <NegativeConsent> elementet i samme kald, da i så fald vil fejle med fejl 450, ”Forespørgslen må ikke indeholde et NegativeConsent element hvis der samtidig er angivet en SOAP ConsentHeader”.

Det kan specielt være relevant at anvende <ConsentHeader> i FMK 1.4.4 E1, hvor man kan hente alle recepter tilhørende en patient. Hvis patienten har recepter under en privatmarkeret lægemiddelordination, vil disse recepter være privatmarkerede. Kun ved at anvende <ConsentHeader> vil det være muligt at se disse privatmarkerede recepter.   

Det er nu muligt at teste den nye header på test1 og test2, og med release 1.4.4.13 vil headeren også kunne anvendes i produktion. Planerne for denne release kan følges på https://www.nspop.dk/display/web/Trifork+FMK+Releaseplan.

WSDL’erne for FMK 1.4.0, 1.4.2, 1.4.4 og 1.4.4.E1 er opdateret med muligheden for at anvende headeren.