FMK Teknik

Det har et stykke tid været muligt på Test1 og Test2 at anvende SOR ID mod FMK som organisations identificer. På Teknikkermødet den 27. februar, blev det gennemgået hvorledes SOR understøttes i FMK. Præsentationen fra teknikkermødet kan læses på http://www.fmk-teknik.dk/index.php?topic=1509.0.

Desuden er anvendelse af SOR, dokumenteret på https://wiki.fmk.netic.dk. Den generalle anvendese af SOR ID i FMK er beskrevet på https://wiki.fmk.netic.dk/doku.php?id=fmk:stamdata:brug_af_sor_id_i_fmk. Anvendelse af SOR i SOAP Headers til system autorisation er beskrevet på https://wiki.fmk.netic.dk/doku.php?id=fmk:generel:systemautorisation, og anvendelse af SOR i Modifikator er beskrevet på https://wiki.fmk.netic.dk/doku.php?id=fmk:1.4.4:modifikator.

Fra den 1. oktober 2019, vil det også blive muligt at anvende SOR ID mod FMK i produktion. I første omgang lukkes der kun op for følgende typer organisationer, der kan anvende SOR
   • behandlingscenter for stofmisbrugere
   • bosted
   • center for misbrugsbehandling
   • genoptræningsenhed
   • handicap- og psykiatrienhed
   • handicapenhed
   • hjemmeplejeenhed
   • hjemmesygeplejeenhed
   • plejehjem
   • psykiatrienhed
   • sundhedscenter
   • sundhedsplejen
   • sygeplejeklinik
   • tandlægepraksis
   • tandplejeklinik   

Bosted og plejehjem har tidligere anvendt kommunekoder til identifikation, og er de første der flyttes over på SOR. De resterende typer er ønsket af EOJ leverandørerne, for at kunne komme helt væk fra at anvende kommunekoder. Hvornår der lukkes for anvendelse af kommunekoder er endnu ikke fastlagt. Ligeledes er det ikke fastlagt hvornår ydeligere organisationer kan anvende SOR.   

Med venlig hilsen
FMK Teamet

Ifm. Windows 10 - 1803 upgrade og tilsvarende for WIN 7 har vi konstateret at Seal.Net v 4.08 ikke overholder DGWS specifikationen, idet den ikke kan håndtere at STS sender et <Signature> element tilbage som har en attribut med navnet id (et lille i og et lille d). Det samme problem findes også i ældre versioner af Seal.net, helt tilbage til version 2.

DGWS specifikationen beskriver specifikt at dette er den korrekte måde, selv om xmldsig specifikationen beskriver det som Id (et stort i og et lille d). Seal.Net v. 4.09 er ændret til at kunne håndtere dette også efter at Windows 10 - 1803 upgrade eller lign er kørt på systemet.

Seal.Net v. 4.09 findes på NuGet, på dette link: https://www.nuget.org/packages/Seal.net/
Såfremt der opleves problemer med tidligere usupporterede udgaver af seal.net fra Digitaliser.dk, Softwarebørsen m.v., anbefales at der foretages opgradering til Seal.Net v. 4.09 - alternativt en tilbagerulning af Windows 10/7 upgrade.

Effektueringer knyttet til lægemiddelordinationer, er primært tiltænkt registrering af de udleveringer som praksislægerne foretager. Derfor har anvendelsen af effektueringer haft et relativt begrænset omfang, og der har ikke tidligere været udfordringer med antallet af effektueringer knyttet til en enkelt lægemiddelordination.

Bostedernes ibrugtagning af FMK har ændret dette. Når bostederne udleverer medicin til deres beboere, registreres dette i FMK som effektueringer. Hvis en beboer får medicin 3 gange dagligt, bliver der på et år registeret 3x365 effektueringer. Så der kan på sigt ligge adskillige tusinde effektueringer under en enkelt lægemiddelordination, der reelt ikke giver meget værdi, og som vil gøre medicinkortet tungt at håndtere både for den centrale løsning, men i særdeleshed for anvendersystemerne. 

Som snitfladen er i dag er der ikke muligheder for at paginere de effektueringer, der returneres fra kald til "Hent medicinkort" og "Hent lægemiddelordination". Dette vil blive skrevet på backloggen til kommende snitflader.

Men indtil nye snitflader tages i brug, er der en udfordring med antallet af effektueringer, som skal løses.

Den umiddelbare løsning er kun at returnerer de sidste effektueringer, f.eks. de 30 nyeste effektueringer. Udfordringen ved dette er at klientsystemerne ikke ved om der er 30 effektueringer, eller om FMK har undladt at returnerer et antal ældre effektueringer.

Der er mulighed for at undersøge om der er flere effektueringer ved at anvende "Hent effektueringer", se http://wiki.fmk.netic.dk/doku.php?id=fmk:1.4.2:hent_effektuering.

Her kan angives <FromDateTime> og <ToDateTime> på den periode man er interesseret i at få returneret effektueringer til. Her vil alle effektueringer i perioden blive returneret uden at antallet er begrænset. Modtages under 30 effektueringer fra "Hent medicinkort" eller "Hent lægemiddelordination", er der kun de returnerede effektueringer. Modtages 30 kan "Hent effektueringer" anvendes til at hente de manglende, ved at sætte <ToDateTime> til tidspunktet for den sidste modtagne effektuering.


Høringen går på:
1)   Er det acceptabelt at begrænse antallet af effektueringer der returneres fra "Hent medicinkort" og "Hent lægemiddelordination".
2)   Hvad er et godt antal at returnere, 30 som foreslået, eller er det bedre at returnere 50, 100? Bemærk antallet er pr. lægemiddelordination.

Høringen løber til tirsdag den 28. februar og svar på høringen skal gives ved at oprette en supportsag på NSPOP.dk.

Dette er en høring om at ændre semantik i historiske FMK kald. Detaljerne i høringen findes i vedhæftede dokument.

Høringen løber til tirsdag den 28. februar og svar på høringen skal gives ved at oprette en supportsag på NSPOP.dk.

På SDS og FMK teamets vegne

Jan Buchholdt

Tilbage i maj måned rettede FMK en fejl, der sikrede at koder, der sendes til FMK er korrekte, i forhold til de koder der findes i Medicinpriser. Før rettelsen var det muligt at sende koder ind, hvor store bogstaver var ændret til små.

Rettelsen betød imidlertid at der var en del regioner, der fik problemer med at lave effektueringer pga. en fejl i ApoVision omkring pakningsstørrelseenhedskoder. FMK rullede derfor rettelsen tilbage.

Den fejl er nu rettet og sikringen af korrekte koder skal slåes til igen.

Planen er at dette sker umiddelbart efter nytår, såfremt der ikke er yderligere indsigelser mod dette.

Med venlig hilsen

FMK Teamet

På teknikkermødet 2017-11-07 blev 3 forskellige måder gennemgået, hvor doseringsstrukturen bliver anvendt forkert. På mødet var der enighed om at doseringsstrukturerne ikke skulle anvendes på denne måde, og at det er hensigtsmæssigt at FMK sikre det ikke sker. Derfor er der nu implementeret en validering, der giver brugeren en fejl, såfremt doseringsstrukturen alligevel bliver anvendt forkert.

De 3 situationer er:

1. Morgen, middag, aften eller nat anvendes flere gange samme dag

En typisk "2 tabletter hver morgen", ser således ud:

<Day>
  <Number>1</Number>
   <Dose>
     <Time>morning</Time>
     <Quantity>2</Quantity>
   </Dose>
</Day>

Men enkelte systemer har indrapporteret:

<Day>
  <Number>1</Number>
    <Dose>
      <Time>morning</Time>
      <Quantity>2</Quantity>
    </Dose>
    <Dose>
      <Time>morning</Time>
      <Quantity>1</Quantity>
   </Dose>
</Day>

Valideringen af at morgen, middag, aften eller nat ikke anvendes flere gange samme dag, resulterer i følgende fejl:

229, "Fejl i doseringen: tidsangivelsen 'morgen' må ikke anvendes mere end een gang indenfor samme doserings-dag"

2.  Samme tidspunk anvendes flere gange same dag

Det samme gælder tidspunkter.

<Day>
  <Number>1</Number>
    <Dose>
      <Time>18:00:00</Time>
      <Quantity>2</Quantity>
    </Dose>
    <Dose>
      <Time>18:00:00</Time>
      <Quantity>1</Quantity>
    </Dose>
</Day>

Valideringen af at samme tidspunk ikke anvendes flere gange samme dag, resulterer i følgende fejl:

229, "Fejl i doseringen: tidsangivelsen '18:00:00' må ikke anvendes mere end een gang indenfor samme doserings-dag"

3. Samme Day struktur anvendes flere gange

Samme 'Day' struktur bør kun anvendes 1 gang. Derfor bør denne struktur ikke anvendes:

<Day>
   <Number>1</Number>
   <Dose>
     <Time>morning</Time>
     <Quantity>2</Quantity>
  </Dose>
</Day>

<Day>
  <Number>1</Number>
  <Dose>
    <Time>evening</Time>
    <Quantity>2</Quantity>
  </Dose>
</Day>

I stedet bør man kun angive samme dag 1 gang

<Day>
  <Number>1</Number>
  <Dose>
    <Time>morning</Time>
    <Quantity>2</Quantity>
  </Dose>
  <Dose>
    <Time>evening</Time>
    <Quantity>2</Quantity>
  </Dose>
</Day>

Valideringen der sikre at samme "Day" kun anvendes 1 gang, vil resulterer i følgende fejl:

234, "Fejl i doseringen: Doseringsdag '1' optræder flere gange i samme doseringsstruktur"

Ændringen kan testes på Test1 og Test2 fra den 15. November.

Såfremt der ikke modtages yderligere tilbagemeldinger, ligges ændringen i produktion mandag den 4. December.

Som præsenteret på de sidste 2 teknikkermøder, er det besluttet, at det ikke giver klinisk mening, at bestilleren kan angive en doseringstekst på receptanmodninger.  Dette er nu implementeret.

Fra FMK 1.4.4.E2/1.4.6 er det ikke mere muligt at angive doseringstekster i receptanmodninger.

I de eksisterende snitflader er det ikke muligt at fjerne doseringsteksten, da denne er påkrævet, såfremt der i receptanmodningen ønskes at angive:
•   Varenummer
•   Antal pakninger
•   Antal udleveringer
•   Pakkestørrelse
 
For alligevel at understøtte at doseringsteksten ikke anvendes, er følgende funktionalitet implementeret i FMK.

Bestilleren (typisk hjemmeplejen) skal medsende en doseringstekst som de plejer, såfremt de ønsker at angive varenummer, antal pakninger, antal udleveringer eller pakkestørrelse. Denne doseringstekst fjernes af FMK og i stedet ser lægen følgende doseringstekst på receptanmodningen:
•   Den korte tekst, såfremt varenummeret passer med lægemiddelordinationen.
•   Er den korte tekst for lang (70 karakterer) angives doseringsteksten "Se lægemiddelordinationen"
•   For ikke takst lægemidler, eller hvis varenummeret ikke passer med lægemiddelordinationen, anvendes altid doseringsteksten "Se lægemiddelordinationen"
•   Hvis receptanmodningen er enten annulleret eller omsat til en recept, anvendes doseringsteksten "Se lægemiddelordinationen"

For at sikre at lægen altid tager stilling til doseringsteksten ved oprettelse af recepter ud fra receptanmodninger, er der i FMK lavet en ny validering, der returnerer en fejl, såfremt en recept oprettes med doseringsteksten "Se lægemiddelordinationen".  Kaldet fejler med følgende fejl:
477, "Recepten har en ugyldig doseringstekst, "Se lægemiddelordinationen" er ikke tilladt som doseringstekst".

Ændringen kan testes på Test1 nu.

Den 15. November bliver ændringen også lagt i Test2.
Såfremt der ikke modtages yderligere tilbagemeldinger, ligges ændringen i produktion mandag den 4. December.

Med venlig hilsen
FMK Teamet

Med overgangen fra FMK 1.2.6 til FMK 1.4.0, blev formatet for versioneringen af medicinkort og lægemiddelordinationer ændret. For at give systemerne mulighed for at konvertere internt gemte FMK versionsnumre fra det gamle format til det nye, blev VersionsServicen idriftsat, se evt. http://wiki.fmk.netic.dk/doku.php?id=fmk:version:versionsservice_snitflade.

Vi kan i overvågningen se, at denne service ikke mere anvendes, og derfor vil servicen blive lukket, såfremt vi ikke hører protester indenfor de næste 14 dage.   

Med venlig hilsen
FMK Teamet

Dags dato rulles nye stamdata ud på alle 4 testmiljøer. Vi starter på Test1 ca. 11.30 og tager et miljø ad
gangen. Øvelsen forventes afsluttet i dag. Nedetid pr. miljø forventes at være max 1 time.

Baggrund for øvelsen:
Som det er meldt ud på NSPOP i NSP-10552 er der åbnet for en ny måde at oprette testdata på. Man får adgang til brugergrænsefladen ved at få oprettet brugernavn/password og er herefter klar til at anvende løsningen. Konsekvensen af dette er at FMK, FMK-Online, DDV, TAS og BEM skal genindlæse stamdata fra det nye system, og derfor er dette servicevindue nødvendigt. Beklager det korte varsel.

I forbindelse med annoncering af den nye selvbetjeningsløsning er der samtidig sket en oprydning i eksisterende testdata, idet testpersoner, som har et CPR-nummer, der findes eller kan komme til at findes i produktion er blevet slettet.
Sletningen er en beslutning, der er truffet for længe siden.
Sletningen kan medføre lidt udfordringer på den korte bane, idet såvel brugere som testpatienter kan være berørt af sletningen. Hvis fx en person, som en leverandør bruger som testlæge er ramt af sletningen, vil leverandøren ikke kunne anvende denne testlæge mere. Der skal således oprettes en ny testperson, som gøres til læge – og der skal rekvireres et nyt certifikat til denne bruger.
Sletningen kan også påvirke testpatienter, som anvendes til uddannelse – så vær opmærksom på det. Gennemgå jeres materiale og find ud af om testpatienterne findes eller der skal rekvireres nye.

Med venlig hilsen

FMK-Teamet

De kommende releases af nye doseringsforslag er nu aftalt med Lægemiddelstyrelsen.

Følgende releasedatoer er aftalt:
1. april 2017
15. juni 2017
15. september 2017
15. december 2017
15. marts 2018
15. juni 2018
...

10 arbejdsdage før releasedatoen bliver regneark med nye/ændrede/slette doseringsenheder publiceres på FMK-Teknik, under emnet http://www.fmk-teknik.dk/index.php?board=19.0 og samtidig bliver de nye doseringsforslag lagt på test1

5 arbejdsdage før releasedatoen bliver de nye doseringsforslag lagt på test2

På releasedatoen bliver de nye doseringsforslag lagt på produktion, Udd og ProdTest

Med venlig hilsen
FMK Teamet

På teknikermødet onsdag den 25. Januar 2017, blev det besluttet at lave en minihøring vedr. et nyt format af doseringsforslag på NSP stamdata. I det vedhæftede dokument er formatet beskrevet. Bemærk der er 2 løsninger i spil, og vi vil gerne have input til hvilket af de 2 forslag der giver jer mest værdi.

Såfremt der ikke er modtaget indsigelser mod denne ændring inden den 20.02.2017, vil der blive arbejdet videre med et af de 2 forslag.

Med venlig hilsen

FMK teamet

På teknikermødet onsdag den 25. Januar 2017, blev mange systemers anvendelsen af "Opslag på medicinanmodninger" taget op under emnet "Best practices". Beslutningen på mødet var at problematikken var så alvorligt, at det var nødvendigt med en separat annoncering på FMK-Teknik.

Vedhæftet pdf beskriver problematikken og skitserer hvorledes problemerne undgås ved at ændre integrationen mod FMK.

Med venlig hilsen

FMK teamet

Minihøringen på http://www.fmk-teknik.dk/index.php?topic=967.0 ændrede POR således at dobbeltregistreringer af tilknytninger/indlæggelser undgås.

Denne ændring har været i produktion siden 1. November. Erfaringerne har generelt været gode, men der ses stadig dobbelt registreringer på indlæggelser.  Ofte modtages patienter uden at sygehuset ved hvilken afdeling patienten ender med at være indlagt på. Et eksempel kan være at patienten ved modtagelsen indlægges på sygehuset med SKS=5506 "PSY Psykiatrien (Esbjerg)". Senere overføres patienten på afdelingen med SKS=550601 " Psykiatriske afdeling, Ribe".

Hvis patienten ikke først udskrives fra SKS=5506 vil det resulterer i dobbeltregistreringer.

For at løse dette foreslås det at ændre POR, således at hvis en patient indlægges på en underafdeling, angivet med en 6- eller 7-cifret SKS, og patienten i forvejen er indlagt på en mindre specifik afdeling i samme SKS hierarki, så slettes den mindre specifikke indlæggelse. I ovenstående eksempel betyder det at indlæggesen på SKS=5506 slettes når patienten indlægges på SKS=550601.   

De slettede indlæggelser kan stadigvæk ses, såfremt historiske patienttilknytninger hentes.

Såfremt der ikke er modtaget indsigelser mod denne ændring inden den 18.01.2017, vil ændringen efterfølgende blive implementeret og gjort tilgængelig på testsystemerne.

Med venlig hilsen

FMK teamet

Som beskrevet i post http://www.fmk-teknik.dk/index.php?topic=1079.0 er der lagt nye doseringsforslag og enheder på test1.

Der har fra regionerne været ønske om at der forsat publiceres regneark indholdende enheder.

I det vedhæftede ark, er der 4 faner:

• Alle lægemidler med tilknyttet enheder (Total)
• Tilføjede lægemidler med enheder (Added)
• Fjernet lægemidler eller enheder (Removed)
• Lægemidler hvor der er nye enheder (Changed)

Der er ligeledes sat et filter ind i toppen af arket, så det er nemmere at filtrere / søge.

Regnearket indeholder enheder fra de doseringsforslag der er frigivet 2016-12-13 13:48

Med venlig hilsen
FMK Teamet

Lægemiddelstyresen har frigivet nye doseringsforslag og doseringsenheder. Disse er i dag lagt på test1 NSP'en og kan hentes der. Frigivelsen af  doseringsforslagene i produktion vil følge nedenstående plan.

2016-12-16 Doseringsforslag og doseringenheder klar på Test1 NSP'en
2016-12-20 Regneark med nye/ændrede/slette doseringsenheder publiceres på FMK-Teknik under emnet http://www.fmk-teknik.dk/index.php?topic=1081
2017-01-11 Doseringsforslag og doseringenheder klar på Test2 NSP'en
2017-01-18 Doseringsforslag og doseringenheder klar på produktion, udd og prodtest NSP'erne 

Med venlig hilsen
FMK Teamet

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

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.

I forbindelse med fjernelse af klokkeslæt på start- og slutdatoer i FMK 1.4.4, er der identificeret nogle cases, hvor det er problematisk, at brugere af FMK 1.4.4 klientsystemer ikke kan få viden om klokkeslæt, der er registret via en ældre snitflade, og hvor den registrerende kliniker antager, at denne information er tilgængelig i andre systemer.

For at gøre denne information tilgængelig i den overgangsperiode, hvor der i FMK ligger informationer registreret med klokkeslæt på start- og slutdatoer, vil disse klokkeslæt (hvis de eksisterer) kunne afleveres med i en doserings supplerende tekst.

For at give parterne mulighed for at se, hvordan dette fungerer i praksis, vil SDS pr. 2. september slå denne funktionalitet til i TEST1.

Mvh
FMK-teamet

FMK giver i dag mulighed for at kunne registrere en patients tilknytning til hjemmeplejen eller at patienten er indlagt på et sygehus. Det er klinisk relevant at have mere end en tilknytning/indlæggelse og derfor tillader snitfladen at der oprettes flere tilknytninger/indlæggelser.

Erfaringerne har dog vist at der ofte oprettes flere indlæggelser til samme afdeling. Når afdelingen efterfølgende udskriver patienten opdager de ikke at patienten er blevet indlagt flere gange, hvilket resulterer i at patienten fejlagtig står som indlagt selv om dette ikke er tilfældet.

For at forhindre denne dobbeltregisterering, foreslås det fra SDS's side at ændre registrering af patienttilknytning således, at hvis en patient tilknyttes hjemmeplejen eller indlægges på en afdeling, hvor patienten allerede er tilknyttet/indlagt, så vil den eksisterende tilknytning/indlæggelse blive slettet, således at patienten kun vil fremstå som tilknyttet/indlagt en gang pr. organisation.

Det vil være muligt at fremsøge de slettede registreringer med historikkaldet, der blev implementeret i  E1, se evt http://wiki.fmk.netic.dk/doku.php?id=fmk:patient-organisation-relation:1.4.2:opslag_pa_tilknytning

Såfremt der ikke er modtaget indsigelser mod denne ændring inden den 15.08.2016, vil ændringen blive implementeret og gjort tilgængelig på testsystemerne.

Med venlig hilsen

FMK teamet