FMK Teknik

Hej,

Det ville være fint med en liste over kommuner og deres leverandør...

Mvh.
Jesper

Det vil være fint med en status på de strukturerede doseringsforslag kontra receptens begrænsning på 70 tegn.
En snak om tekstuel oversættelse af strukturerede doseringer vil også være meget relevant - gerne incl. best practice og tips/tricks.
Erfaringer med e2e test mellem regionssystemer og LPS er interessant.

Ved man noget om hvornår valideringen udbredes til Test2 m.fl.?

Hej Tom

Det er forståeligt! Men efterhånden er der ret mange services, leverandører og instanser involveret i NSP, FMK, DDV, NAS, STAM, DGWS, GW, DCC m.v. så det er svært altid at kende vejen til support. Jeg kunne godt bruge en form for oversigt over support indgange til de forskellige services og miljøer i det hele taget... Hvor mon jeg skal anmode om det? :-)

Mvh.
Jesper

Jeg er lidt bekymret over ordlyden mht. hvorvidt EOJ kan/skal/bør angive en modtager på receptfornyelser:

"I kaldet kan der medsendes en angivelse af hvilken lægepraksis, evt. sygehusafdeling m.v, som
hjemmesygeplejen ønsker genbestillingen skal foretages af. Dette angives i elementet Prescribing-
Organisation. Elementet kan udelades eller der kan angives flere, f.eks. hvor hjemmesygeplejen er i
tvivl om hvorvidt genbestillingen skal foretages af borgerens egen læge eller af en speciallæge, et
ambulatorium eller lignende. Er der ikke medsendt noget PrescribingOrganisation-element er
bestillingen afhængig af at der findes en eller flere læger der abonnerer på borgerens CPR-nummer, og
handler på baggrund af adviseringen.
Det anbefales at EOJ-systemet angive mindst en PrescribingOrganisation med patientens egen læge."

Sagen er at det er meget svært at vedligeholde idlister med CPR-numre i LPS systemerne af flere årsager: mange patienter har ingen fast tilknyttet læge (grundet ubesatte ydernumre), patienter passes på skift i forbindelse med ferie og patientafgang er ikke veldefineret m.v. Derfor vil rigtig mange CPR-numre optræde i ganske mange klinikkers idlister og den støj og forvirring der opstår i kølvandet herpå (i form af adviseringer der går til "forkerte" klinikker/læger må ikke undervurderes).
Jf. Lakeside, citat: "I forhold til receptfornyelser er det således også håndtag i 1.4 snitfladen til at slå bestilte receptfornyelser op for et givet ydernummer. I forhold til implementering ud i kommunerne er der hensigten at der ved receptfornyelser fra hjemmeplejen altid skal angives (mindst én) modtager og der fra EOJ systemerne kun må bestilles receptfornyelser via FMK fra læger der er på 1.4 og kan håndtere receptfornyelser (dvs. EOJ systemerne vedligeholder en form for whitelist)." Skal der angives en modtager i EOJ - men det stemmer altså ikke med nærværende dokument. og dermed går vores intention om at benytte ydernumre i idlisterne fløjten! Det ville ellers give 2 store fordele: a. Idlisterne ville bilve MEGET nemmere at vedligeholde og b. antallet af adviseringer der "rammer forkert" vil blive minimalt!

Hvad er sandheden her?

Hej,

Som jeg forstår det er 1.2.6 og 1.4 nu i drift, hvordan med 1.4.2? ER den i drift? Hvis ikke hvornår kommer den det og hvornår kan den tilgås i testmiljøet?

Event ideen er god. Her er lidt løst og fast...
Hvor meget er en event værd hvis den kun returnere et id på f.eks. den lægemiddelordination der er ændret? Det betyder at klientsystemet kun kan vise en generel ændrings information - ellers kræver det yderligere opslag. Måske man kunne bede om at få flere eller færre data med retur i eventforespørgslerne alt efter det aktuelle behov?
I MedWin forsøger vi allerede nu at lave en "ændringsrapport" til lægen ved at løbe medicinskema versioner igennem. Ideen er at den vigtigste information til lægen er en kort og præcis oplysning om hvad der er sket på patientens medicinkort uden for egen klink siden lægen sidst så patientens medicinkort. Events vil kunne hjælpe os til at opbygge sådanne rapporter på en mere elegant måde - hvilket føre hen til at man måske kunne forestille sig at svaret på en event forespørgsel på events mellem f.eks. medicinkort version 3 og 24 ikke er 117 events, men een stor tilbagemelding samlet i een struktur?
Mht. cluster drift og sammenfaldne begivenheder må det være relativt få situationer der opstår (alt efter antallet af clustre naturligvis...). Hvis merge funktionaliteten kan bringes til at virke fornuftig må det være godt nok.

Mvh.
Jesper