Teknikermøde den 28.10.2020

[Ellen Simonsen]

Kære alle

Mødet den 28.oktober 2020 bør allerede være i jeres kalender  Mødet afholdes som et virtuelt møde. Link til mødet udsendes inden mødet.

Dagsorden for mødet:

Velkomst og præsentation

Opfølgning fra seneste møde
Orientering ved Sundhedsdatastyrelsen

Frokost

eCPR projektet
Indikationskoder brug af dem versus fritekst indikationer
E5 – Indhold / ikke låst snitflade
National afprøvningsplatform (NAP)
FMK snitflade 1.6.0
Eventuelt, Indkomne emner / forslag
Evaluering / næste møde

På FMK teamets vegne
Ellen Simonsen

Zoom link til mødet:
Topic: FMK Teknikermøde
Time: Oct 28, 2020 09:30 Copenhagen

Join Zoom Meeting
https://trifork.zoom.us/j/91425371003?pwd=ODc3aEgxc0JzaGpjMGU4YWlySW1WZz09

Meeting ID: 914 2537 1003
Passcode: 125287

[Claus Hemberg Jørgensen]

Information til deltagerne (også udsendt pr. email til tilmeldte):

Det indledende arbejde med en kommende FMK 1.6.0 snitflade er blevet sat i gang, og i den forbindelse ønsker FMK projekt teamet at involvere relevante interessenter på en række områder. Vi er p.t. i gang med at opbygge et katalog over konkrete emner til FMK 1.6.0, og vi har identificeret en række punkter med særlig interesse for FMK klientudviklere, hvorfor vi på det kommende teknikermøde den 28.10.2020 gerne vil udbede os noget feedback herom. Dette dels for at få afklaret, i hvor høj grad punkterne er relevante, og dels i hvilken retning vi skal gå med løsningerne i den nye snitflade. Vi forventer at lave en mere fyldestgørende gennemgang af ideerne til 1.6.0 på et senere teknikermøde. De punkter som vi gerne vil høre jeres input til er flg.:


Anvendelse af SOR nummer som primær organisations id i FMK snitfladen.
Da det næppe er realistisk at gøre SOR til den eneste tilladte organisations id endnu, skal der i en længere overgangsperiode arbejdes med en overgang fra SKS- og ydernumre til SOR. Det kunne eksempelvis ske ved at forbyde anvendelse af SKS/Ydernumre i requests, og kun acceptere SOR koder. I responses kunne vi stoppe berigelsen med organisationsstamdata ud fra SKS-koder/ydernumre og blot returnere de oprindeligt gemte data.

Spørgsmål: hvor langt er de respektive klientsystemer med anvendelsen af SOR id'er? Vil I fra dag 1 kunne begynde at anvende SOR id'er til FMK kald, eller er der lang vej dertil endnu? Hvilke udfordringer kan I se i den forbindelse?


Anvendelse af mere HL7FHIR lignende datastrukturer
Der er i FHIR defineret en lang række entiteter, hvoraf mange lignende kan findes i FMK snitfladen, dog med lidt anderledes strukturer og indhold. Som et første skridt i en mulig migrering hen imod anvendelse af FHIR i FMK snitfladen kunne der udvælges en eller flere entiteter, som skemamæssigt kunne tilrettes i retning af FHIR's entiteter. Hvis entiteter, feltnavne og indhold derved gradvist kom til at stemme overens med FHIR ville en fremtidig overgang mod en ren FHIR snitflade blive enklere, ligesom mapningen fra/til FMK snitfladen ville blive triviel for allerede FHIR-baserede FMK klienter. For ikke at gøre udviklingsopgaven for stor for de respektive FMK klienter formodes det, at en gradvis overgang vil være at foretrække, d.v.s. en proces der vil strække sig længere end kun FMK 1.6.0 snitfladen.

Spørgsmål: hvordan ser I på anvendelsen af FHIR i fremtiden – er det et erklæret mål at anvende det, anvender I det allerede internt i jeres systemer, og kunne en sådan gradvis overgang være interessant?


Mere ensartet response-struktur
I de nuværende snitflader indgår der en række mere tekniske/logiske elementer i svarene, der ikke har noget med de kliniske data at gøre. Derfor foreslås det at flytte disse dele ud i en generel response header. Disse elementer kunne være: "Medicinkort ugyldig" markering , VersionMismatchWarning, Privatmarkering (=eller mere generelt: der findes skjulte data), status fra bulkkald (UpdateMedicineCard), liste af tidl. (e)cpr-numre efter cpr/ecpr-skifte, paginering samt generisk fejlhåndtering. Derved ville FMK klientsystemerne kunne håndtere svar på en mere ensartet måde end i dag, fx hvad angår paginering, der i de eksisterende snitflader foretages på forskellig vis, men også fejlhåndtering – herunder fejlhåndtering fra bulkkald.

Spørgsmål: kunne en sådan refaktorering af response's være relevant/ønskværdig, vil den løse nogle af de problemer I evt. i dag måtte stå med, eller skal det gøres på en helt anden måde? I særdeleshed i.f.m. bulkkald har vi gennem tiden modtaget flere spørgsmål i forhold til fejlhåndtering – i hvor høj grad anvendes disse bulkkald (UpdateMedicineCard) til flere samtidige operationer, og vil det være relevant at forbedre fejlhåndteringen heraf?

Tillade eksterne, ikke FMK-kendte sources for stamdata
I dag tillades kun sources for stamdata, som FMK i forvejen kender til og dermed kan validere.
Spørgsmål: Er der et behov for at åbne yderligere, således at datakilder der ikke kan valideres af FMK, men som er eksternt kendte (eks. Nomecos sortimentliste), kan anvendes i FMK's snitflade? De enkelte værdier ville fortsat ikke blive valideret af FMK, men det kunne måske være hensigtmæssigt for klientsystemer der kender den pågældende eksterne source, at give muligheden for at behandle den som sådan og ikke blot som source="local".

Registrering tilbage i tid
Spørgsmål: I hvor høj grad vil det være relevant at forbyde/tillade registrering af data bagud i tid – f.eks. i forbindelse med efterregistrering, rettelse af fejl i data o.lign.? Det har været diskuteret, om der skulle indføres en validering der eksempelvis forbyder seponering af ordinationer 1 år tilbage i tiden, men det helt overordnede spørgsmål er egentlig, om det overhovedet er relevant at kunne rette/registrere data, der ikke længere er aktuelle?

Vi ser frem til at høre jeres input til ovenstående på FMK-teknikermødet.