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).
I have argued, so far unsuccessfully, that as a minimum, adding role (0…*) to PARTY_IDENTIFIED would solve most of these kinds of requirements, but that it would also be very helpful to add an other_details, archetypable slot.
I response your pain. Can we please make a decision on at least adding Role?
Sorry @thomas.beale - we have had this argument over and over. It is way over the top for what we need, which is just a common requirement for integrated data feeds, to record not just name and identifier but some variable ‘clinical provenance’ info such as role, organisation name.
There is honestly no demand , in my world , for what you are suggesting.
Hmm not sure why I responded to Birger - Discourse gave me the impression that this was a new post. Nevertheless , we need to make progress on this one, it keeps coming around, and often forces us to not make proper use of attributes like participations
I’m not 100% sure what you are referring to here - is it the 2yo post above?
There are clearly different needs in different places. I can tell you for a fact that there is very keen (non-academic) interest in some major locations in these questions. It’s just that the activities in each country or region are not the same.
OMOP is a similar question - probably irrelevant in the UK for now, but a burning topic in at least 2 locations that I know of.
Yes - sorry you always look a bit daft when you have a rant about a post that is 2 years old!! For some reason, Discourse notified me about hese posts, so I responded as if it was new
You are not going mad; I moved a fair few posts into a new Specifications/demographics category, since we have so many. Discourse seems to notify as if they are new. But not always. Or something like that…
