Ideoplæg til versionering med events

[Tom Kückelhahn Nilson]

Vedhæftet er et ideoplæg til hvorledes FMKs versionering kunne forbedres.

Kommentarer er velkomne.

Mvh Tom

[Jesper Sørensen]

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

[Tom Kückelhahn Nilson]

Hej Jesper

Tak for din kommentar.

Vi har haft diskussioner om hvor meget information der skal være i et event. Jeg mener, at vi med den beskevne løsning har et nogenlunde kompromis mellem de datamængder vi kan risikere at returnere og anvendelighed.

Event-modellen er i første omgang opstået som en nødvendig løsning for at kunne håndtere drift i flere clusters. Problemstillingerne ved opdateringer foretaget på et ikke opdateret medicinkort ligner i øvrigt også hvad der kan optræde ved cluster drift. Men en meget væsentlig forbedring (og måske den forbedring, der gør det værd at tage eventmodellen i brug i et klientsystem) er at gøre noget ved den kliniske versionering vi i dag har med medicinkortets og lægemiddelordinationernes versionsnumre: Versionsnummeret indeholder én fast fortolkning af hvad en "interessant" ændring er, og lige nu er f.eks. receptudstedelse og effektueringer på apoteket efter den definition ikke interessante. Fremover vil vi også kunne få ændringer fra receptserveren, hjemmesygeplejen, "det fælles dosiskort", og hvad der ellers kunne komme af systemer.

Event-modellen er designet således at den ikke er specifik for FMK, men f.eks. også kan bruges hvis klientsystemet alene er interesseret i ændringer på f.eks. patientens dosiskort. En service til at lave en diff mellem to medicinkort-versioner, lægemiddelordination-versioner m.v. er nok en FMK specifik service, og måske så præsentations-specifik, at den ikke er ligetil at løse på en god måde gennem en webservice.

Mvh Tom

[Jesper Sørensen]

Hej,

Jeg kan godt se argumenterne for en generisk eventmodel og også at det måske let bliver for specifikt at lave "rapport" services. Et eller andet sted peger alle disse input hen mod det mere overordnede område. "historik". P.t arbejder man jo med de 2 år efter udløb/seponering - er der tænkt videre mht. dette og hvordan tænkes receptserverens rolle på den lange bane?

Mvh.
Jesper

[Tom Kückelhahn Nilson]

Hej Jesper

Umiddelbart er det ikke svært at finde gode argumenter for konsolidere FMK og receptserver i en eller anden grad. Indtil nu har jeg dog ikke hørt noget konkret herom. Omkring de to års udløb er det nu reguleret af bekendtgørelser, og det vil være naturligt at se på det i forbindelse med en ændring af receptserveren. F.eks. også således at recepter ikke nødvendigvis altid opbevares i to år: Mindre kunne også give god mening, f.eks. er der sjældent god grund til at en ikke afhentet penicillinrecept skal findes på receptserveren i to år. Igen: Jeg har ikke hør noget konkret herom.

Mvh Tom