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