Demographic archetypes for clinical record purposes

Clinical
1

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

Regards

Heather

4 Likes
2

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

3

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

3 Likes
4

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

1 Like
5

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
6

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
7

… 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.

Cheers

Heather

2 Likes
8

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.

party_proxy_entry

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
9

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
10

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.

11

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
12

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.

2 Likes
13

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

entry-participation

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
14

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
15

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.

2 Likes
16

As @heather.leslie mentioned at the start of this thread, several things have been found to be needed both in EHR and DEMOGRAPHIC space.

Here comes a (possibly stupid) question from me, related to this discussion:
Why are CLUSTER archetypes prefixed with EHR or DEMOGRAPHIC?

Now we for example have both:
openEHR-EHR-CLUSTER.death_details
and
openEHR-DEMOGRAPHIC-CLUSTER.person_death_data_iso.v0 (plus
openEHR-DEMOGRAPHIC-CLUSTER.person_other_death_data.v0)

If it for example would be the case that some CLUSTER-archetypes like these could be useful in both EHR and DEMOGRAPHIC use cases, could we not then have more neutral CLUSTER archetypes like
openEHR-CLUSTER.death_details.v0 or openEHR-DATA_STRUCTURES-CLUSTER.death_details.v0 that could be used in both?

Item structure and CLUSTER classes are neither in EHR nor in DEMOGRAPHIC models, they are instead in the sibling level Data Structures Information Model

image
image1163×265 20.7 KB

I can imagine many detail CLUSTER instances that one at certain points would want to copy from some registry/catalog/demographic data and into specific EHR documents, It would be convenient to be able to reuse exacty the same archetyped data structure for both.

@thomas.beale and others, are there historical reasons for the EHR/DEMOGRAPHIC-prefix of CLUSTER ARCHETYPES? Was the data structure package and CLUSTER originally part of the EHR model before being moved to a separate reusable model?

2 Likes
17

In an archetype id like openEHR-EHR-CLUSTER.death_details , the structure (as I think everyone knows) is

publisher-Model-Class.concept.version

where the Class is reachable by the ‘model’ referred to by ‘Model’. Here EHR means the EHR ‘model’, i.e. the EHR IM part of the RM.

In Task Planning we can therefore have:

openEHR-TASK_PLANNING-COMPOSITION

because the TASK_PLANNING model uses class COMPOSITION.

Back to CLUSTER… the assumption made in the existing CLUSTER archetypes is (AFAIK) that the CLUSTER would only make sense under an EHR model top-level object, or a DEMOGRAPHIC model object (PARTY or whatever).

If they could be used in either place then we could solve this by sticking with the original archetype id, and in the appropriate slot in say OBSERVATION or the using archetype, just make sure that the regex pattern pointed to the correct archetype, i.e. openEHR-EHR-CLUSTER.death_details.

So I am not sure if there is a concrete problem, and indeed, such a slot regex makes it clear that somehow the EHR is reusing a ‘demographic’ concept.

If this were not enough, we’d need to invent some special pseudo model name like GENERAL that would be detected by tools, and that starts to look like work…

18

I share the idea that cluster can be generic, not EHR specific. And I like the flexibility of getting clusters reused outside the EHR model. Another example is CLUSTER.device. And maybe many others.
But I do worry about the migration work, every archetype and template and stored composition ever that uses a cluster would need to be migrated…

1 Like
19

What migration do you mean?

20

Replacement of the regexes and use_archetype reference that now point to e.g. openEHR-EHR-CLUSTER.device.v1 and afterwards should point to e.g. openEHR-GENERIC-CLUSTER.device.v1