A few more thoughts percolating in my mind as I was out walking…
Let’s say an area health service has 1,000 clinicians, and they have average 10 contacts / day, x 300 days in the year. That’s 3million contacts. With no common repository for their details, that’s 3 million replicated data entry events. Normally we want to avoid that.
For solutions/products that have only a CDR and no demographic capability today, there is an easy hack that will solve the problem, which is:
- create a special EHR (possibly with a special UID, e.g. 0000 …)
- use that to store Compositions containing ADMIN_ENTRYs, containing the demographic details of interest, probably one Composition per entity. They will be versioned in the normal way when changes are made.
- use
PARTY_PROXY.external_refto point to these.
I still think this is only marginally quicker to implement than a local demographic cache containing PARTY objects, but one attraction is that it should be completely possible with no software changes to an existing CDR product.