Organization of a party within the EHR

So that sounds like an integration scenario - I didn’t think Ian or Heather were talking primarily about this (end of life and other such use cases - data would be provided by application).

Which is the attraction of the ‘cheap’ version - it’s just a special EHR in the CDR, containing normal Compositions and Entries, so the only extra functionality that is needed is to create (some) demographic objects in that special EHR (call it D) rather than in the EHR being worked on (for some patient P), and connect the demographic refs in P’s EHR to those in the D EHR. Plus a bit of additional work to enable applications to search on existing demographic items within the D record, which gets you reuse.

That is of course true. But why would the cache be deleted or become outdated?

Well in fact… it is!

Also, tools like Archetype Designer get their model definition from BMM files, and those include the whole demographic model. So making archetypes of demographic entities is possible today in that tool.

Plus, this proposal adds some missing representational power to the demographic model.

Well there’s clearly market demand for representation of demographic data, otherwise we wouldn’t be having this conversation. The market assumes that suppliers will figure out the details of how to offer what is needed. So it’s up to the suppliers to determine implementation possibilities. Which is what we are discussing.

The key question is therefore: what are the real requirements? I can see quite a few, but they have not been clearly separated or described. Some involve de novo data capture; some appear to involve integration data sources with ?unreliable / random ‘demographic’ data; there are significantly differing requirements with regard to content (as far as I can see, adding PARTICIPATION.role would fix a lot of problems). And so on.

Just like every other possible feature of an EHR system, we need to analyse these requirements in an organised way to work out what makes sense in the solution space.

Understood; some projects don’t want to / can’t use this model because it’s too much work. That’s why I made the EHR demographic cache record proposal, which uses the EHR demographic archetypes Heather was talking about, and doesn’t use the demographic model at all. It will simply reproduce most of the semantics (probably not the PARTY_RELATIONSHIPs) represented as ADMIN_ENTRYs. I proposed this as one possibility to show how very little work indeed could be done to obtain a reasonable amount of demographic entity referencing, as well as supporting the inlined content we have (assume that role is added). Note that this particular solution requires no formal change to the RM at all (other than role) - the only changes might be to document the ‘demographic cache record’ as an implementation possibility.

Other implementation possibilities are no doubt possible and maybe desirable - I’d say we should try to describe the requirements systematically in order to work out what these are.

Here’s an articulation of various possibilities for demographic ‘caching’ and service in an EHR environment. The proposal I was making was the ‘CDR-local cache’, but as you can see, it could easily be sensible to add an even lower level, ie. per EHR, since it is very likely that even ‘informal’ references (patient’s brother, lawyer etc) will have multiple mentions from the same EHR.

Anyway, food for thought, it’s in no way definitive of anything. (@heather.leslie , @ian.mcnicoll , @birger.haarbrandt might want to say if in principle this kind of referencing is at least occurring in your various project scenarios).