Demographic archetypes for clinical record purposes

Hi all,

Over the years there’s been a proliferation of demographic-related archetypes created using the EHR RM and intended to be used for clinical recording purposes and explicitly designed with a simple, light touch that is adequate for recording in a consult note, a referral or an extract to send to a new GP practice.

We often get pushback from the engineers because it means we don’t end up using proper Master Patient Indexes or Healthcare Provider Indexes etc. So, just to be clear, I’m not talking about the creation of an intraEHR address book either - it is never, or should never be, the intention to add the names or contact details so that it could be updated over time etc. That should clearly be done in a way that is sustainable and separate from the EHR.

Think of these examples:

  • the name and contact details for a lawyer who holds a physical copy of an advanced care record;
  • the name and contact details of a carer in a referral;
  • the name, role and contact details of a member of a care team;
  • the role and contact details of a named primary contact person within an organisation;
  • details about a relative in a family history record; or
  • a witness to an epileptic fit; and
  • the location of a fall or accident.

With that view in mind, and in the context of a multitude of divergent models in various CKMs, we want to try to consolidate and converge back to a common, shared pattern.

Today I’ve sent out 3 CLUSTER archetypes for review - Person, Organisation and Address.

There are additional archetypes for Structured name and Structured address that can be reviewed as fast followers, but act to extend each of these archetypes.

The archetypes are based on:

  • current Australian standards AS 4846-2006 Health Care Provider Identification & AS 5017-2006 Health Care Client Identification. Standards Australia.
  • current FHIR resources, although there are a couple of tweaks but still mappable; and
  • an outdated version of ISO/TS 22220:2007 Health informatics — Identification of subjects of health care.

If anyone can check them against the latest ISO versions that would be much appreciated as I don’t have access to a copy. :zipper_mouth_face:

We have the intent to revise the demographics archetypes built on the Demographic RM at some point in the future - we are certainly intending for them to be compatible.

Examples of template containing the 3 core archetypes can be viewed here:

Please adopt the archetypes if you’d like to participate in the review process




Why aren’t you using the demographic RM to create those archetypes?

Simple answer - because they can’t be used within a clinical template. And secondly they are overcomplicated for clinical purpose.


Then maybe we should improve the model to allow that. What about being able to include the demographic model from specific parts of the RM such as ADMIN_ENTRY? @thomas.beale

I would say that if the demographic model is over-complicated for clinical purposes, then we need to know what the model should be.

A fundamental question for the use cases @heather.leslie mentions is: for these kinds of contact details, e.g. lawyer, care team member, other contact person:

  • what should happen if the contact details of such people change?

If the answer is: just record a new data instance into the EHR of the patient, then this will have to be done for potentially hundreds or thousands of EHRs, if we are talking about a clinical professional from a local clinic being replaced by another. WHereas if that person is represented independently in a demographic cache connected to the EHR system then any change only has to be done once.

On the other hand, let’s say 1500 patients have Dr Sonia Jones as their diabetologist listed in their care team, and just one or a few switch to another diabetologist or for some other reason need to remove Dr Jones from their care team list; this is an example of the relationship being severed, not a change in the demographic entity itself.

Whatever solution is wanted, it is going to have to be able to deal with these standard scenarios. That means considering where the demographic data will live, and whether there will be uncontrolled copies of such data representing the same real world entity (i.e. Dr Jones etc), one managed and versioned instance to which references are created.

We could go further and ask things like: what if the care team for say a lot of diabetics (or EOL patients) is the same for an area - would we want to define that as a team, and just connect the many patients to the team?

1 Like

I’m happy with the initiative! Since we need a person archetype with a role element, for our care plan work.

If I read these usecases, to me it feels like name, role and organisation make sense to store in the EHR. Since if something changes in those elements, e.g. a carer gets a new role, the old role is still valid in the original composition. But contact details does not make sense to store in the composition, for reasons stated by @thomas.beale . (even though it would be the pragmatic solution for our company, since we did not implement the demographics spec.)
(Address as in location of accident does make sense to store in EHR, since it should probably not change.)

1 Like

… Easy answer - if we need to track changing contact details then a fully maintained registry or index should be used eg for addressing and sending referrals or maintaining a current care team within an EHR or institution.

But in so many of the clinical notes, or extracts/messages to providers that don’t have access to a registry or even to the same registry (eg cross border situations), they are a one-off mention of a person or organisation - just enough for an aide memoire or to kickstart the search for current contact details at a later date. We definitely do not need to use a heavy-duty full index approach all the time - for all the examples already mentioned, especially the people/orgs who would never be registered in a HPI or registry for other professions. Also Auntie Sue, who has the same genetically related health condition.

In my experience, even the best healthcare provider indexes have been woefully inaccurate and poorly maintained, so their existence does not necessarily mean higher quality data. Sometimes you just need to record the details that are relevant today and move on.

We’ve been using a range of these ‘light touch’ models since late 2000’s and having these same conversations since then. The clinical requirements remain unchanged and the more urgent issue is to converge the wide variation in models closer to a common pattern for shared use in all our EHRs.

Changing the situation so that there is no demarcation between the Demographic and EHR RMs may be a very sensible future solution to consider but we can’t afford to wait.

If the tech wizards can devise a solution that covers all use-cases, then we’ll be with you 100%. In the meantime, this proposed simple family of clinical archetypes are a simple and pragmatic way forward that will provide an immediate positive impact, converging the myriad of models currently being used.

The design intent is to optimise compatibility with future formal demographics archetypes - for that we need broad input from those who understand the formal demographic domain. (BTW the current draft Demographic archetypes also need considerable work to get them into a reviewable, then published, state.)

Hope this helps clarify the situation.




In that case, the RM already does what is needed, by the use of PARTY_IDENTIFIED (and PARTY_RELATED if you want it) in other_participants on any ENTRY, or as subject of other ENTRYs, and anywhere else PARTY_PROXY is allowed.


That can be true. In pursuing a ‘proper’ solution, I am not advocating creating an MPI. But it’s certainly possible to create a EHR demographic cache within the EHR system, for use by all the EHRs there. With that, everytime you want to record a reference to some ‘Dr Sue Jones’, you create the appropriate PERSON object in the demographic cache (first time) or else just a reference to that object (every subsequent time some EHR needs to mention Dr Sue Jones). The EHR demographic cache is versioned, same as the EHRs, so references point to the version of each demographic entity extant at the time. Later modifications create later versions, and later references will correctly point to those later versions.

With this solution, you get proper archetyped PARTYs, proper versioning, and an already existing model of contracts, addresses, capabilities etc. There’s no difficult engineering here, especially if the cache ignores PARTY_RELATIONSHIPs, and just records PARTYs.

Well we already have the solution: the demographic model - I think it already does everything needed (we can certainly add things if needed, but it mostly relies on archetyping anyway).

We already have quite a few archetypes based on the demographic model as well - so we might be in danger of a proliferation here. I wonder if the best way forward is to compare these newer archetypes, and update the demographic model archetypes (based on PARTY, PERSON etc) with any new details needed.

I certainly see where you are coming from w.r.t. current needs, but looking at it from a systems perspective (i.e. what do installed solutions and data look like), I would say the EHR demographic cache is the simplest and cleanest solution.

1 Like

Jumping in here, to say that in a clinical setting we do need to record information about a person’s name, adress as part of an observation, and this will not be a part of the persistent information. It makes no sense to use a central repository for that information. It can, as Heather points out, be about a person which we never will find in a such registry - the name of the neighbour of the patient who has taken care of the keys to the entrance door after the ambulance has collected the patient. Or the adress of the hotel the patient lived at the holidays, where we suspect there was an outbreak of some food poison bacteria.

This is brief information, valid only for a short time period and connected to a specific stay in the hospital/institution. It will probably never be updated. And if the neighbour with the keys move or does not want to keep the keys, you will not change his/hers adress, but replace with some other neighbour.

1 Like

Right - we already handle that routinely with the PARTY_IDENTIFIED and PARTY_RELATED types, which are the types of ENTRY.provider, and (via PARTICIPATION), ENTRY.other_participations and COMPOSITION.context.participations.

Just to agree with Heather and Vebjorn, that for good or bad we are frequently faced with situations where we need to embed small aspects of person information within the EHR. Sometimes this is ‘by design’ as per Vebjorn’s example, sometimes simply because the kind of technical/governance infrastructure that Thomas correctly suggests, is simply not available, at least in the short term.

As an example, we have been using a small set of archetypes based on the FHIR Care Team resource, which works well for various (often ad-hoc_ lists of important contacts - the might be global for a patient or more likely local to specific conditions or care pathways.

An example is on the ResPECT template. Ideally this would be managed by some sort of master list and not in the EHR at all but that simply is not available to us in either of tyje projects where this will be going live. Even if it did exist there may well be circumstances where some of tis information needs to live in-line (as per Vebjorn).

I am starting think that we need to fundamentally rethink this aspect of how we manage ‘demographic data’ . It is not the clean separation originally envisaged and is not well supported by the current PARTY classes.

1 Like

But these do not work, as we are missing role(s), which could be added to PARTY_IDENTIFIED but then we have a long tail of other, variable pieces of information - contact details, other comment, parent organisation details. None of that is supported by PARY_REF (as in-line data).

If we were to add an archetypeable other_details structure to PARTY, that would become much more useful. but I think we need fundamental re-think in this area.


PARTICIPATION has function; if that is not enough, it’s easy to add role as well.


Well as soon as you say that, we are just talking about the contents of the demographic model. So why wouldn’t we just use it and make references to common instances in a demographic cache in the EHR system? If you’re going to include all these details for Dr Jane Smith once, if you just do that inside Entries or Compositions in an uncontrolled way, you’ll do it again and again, and all those details will contain errors, gradually go out of date etc, and there is no way to keep them up to date.

Doing it with a demographic cache means the instances are properly modelled, archetyped, versioned, and maintainable.

I can’t see any argument for making all this ‘inline data’, but there are many reasons why we would not do this.

BTW I am assuming that there are really three kinds of demographic data we want to capture:

  • A: informal data of non-professional persons related to the patient, e.g. parent, friend, person who brought them to A&E etc
  • B: thumbnail info for clinical professionals - name & identifier(s) - that could be used to look up the professional in an MPI later on
  • C: reliable and detailed demographic data for clinical professionals

A & B can be done with inline data (already handled by the model); C can’t safely be done by that method (the problem of errors, no versioning) - it needs proper modelling and representation.

1 Like

Just thinking about this scenario: is the argument to push ‘proper’ demographic data into the EHR simply because most implementers have not implemented the demographic model? And the workaround today is to put all this stuff into archetyped Observations, Evaluations etc, inside the EHR?

I would suggest the options are:

  • A: do inlined demographic information in the EHR
  • B: build a simple demographic DB within the EHR system, i.e. old-school tables, and refer from EHR Entries to those entities
  • C: implement the demographic model as a versioned demographic cache within the EHR system

A is potentially quick but has the problems of data inconsistency - uncontrolled copies, errors, etc.
B would be pretty quick, and solves the inconsistency problem, since you have one instance of each demographic entity. This solution can also be replaced by a later implementation of C.
C will take longer, but all the modelling and many archetypes are done (and the archetypes are easier), and adds versioning as well.

1 Like

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_ref to 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.