Hej Christian
I dag burde det kunne gøres på to måder:
- Ved at hente den aktuelle version og herefter de tidligere versioner enkeltvis. Dvs. hvis "hent aktuelt medicinkort" returnerer version 10 hentes version 9, 8, 7, ... enkeltvis indtil der returneres en version systemet kender i forvejen, eller der spørges på en version ældre end to år.
- Ved at hente aktuelle medicinkort, herefter at hente medicinkort som det så ud for to år siden (med angivelse af dato i requestet). Herved kender systemet det interval af medicinkort-versionsnumre der kan returneres.
Bemærk dog at de fortløbende versionsnumre med stor sandsynlighed kommer til at blive erstattet af "noget andet". Det skyldes at FKM for at sikre en meget høj oppetid engang i fremtiden vil blive et distriberet system. Herved er der ingen sikker måde at et cluster kan generere "næste nummer", uden at der er en lille risiko for at et andet cluster næsten samtidigt også genererer samme "næste nummer".
Dette "noget andet" vil sandsynligvis blive et ikke fortløbende versionsid, en relation til forrige version, og en "versionering med events". Hvis vi indfører "versionering med events" som beskrevet i dokumentet i linket i min tidligere post, så vil du kunne slå den ældste tilgængelige version op med et request i retningen af:
<EventRequest>
<CPR>1111111118</CPR>
<FromTimestamp>2009-10-17T11:00:00</FromTimestamp>
<ToTimestamp>2999-01-01T00:00:00</ToTimestamp>
<Limit>1</Limit>
</EventRequest>
Der mangler dog en "order by" angivelse, som sikrer at det er det ældste event der returneres, og ikke det seneste, dette element er ikke beskrevet i ideoplægget.
Mvh Tom