Revision of the clinical 'demographic archetypes'

There is a need to be able to detail/describe people/caregivers/roles within the clinical record or documents to be exchanged eg cc’d clinicians to a record or a list of caregivers in a referral. The current clinical archetypes were built over a decade ago and never had any formal review process.

Given the momentum of FHIR, logically it makes some sense to align the content with the FHIR models, to minimise need for mappings etc.

Are there any strong feelings against exploring this option?

If we can, I’d prefer to avoid the old argument about preferred use of demographic archetypes and take it as understood that we need separate clinical demographics :grin:

4 Likes

OK - I’ll take silence as an indication of agreement, so we’ll go ahead with exploring a closer alignment :sunglasses:

I’m happy to help with that :smiley:

1 Like

Excellent. Offer accepted.

1 Like

I agree - has been our policy in the UK for a while - see https://ckm.apperta.org/ckm/projects/1051.61.31

for how we created some FHIR-aligned ‘cc’ archetypes for the Scottish work. Happy to help get this into the international domain. They are not perfect but they have traction.

2 Likes

Ok - I suggest we take further chatter offline to the Slack channel and post our findings back in this topic when we have something to show or ask…

I’ll aim to utilise Ian’s existing work, already used in implementations, and align with the FHIR spec and propose changes for our archetypes in this CKM.

The FHIR Patient resource is normative; but all others have a maturity level of 3 or less and are likely to shift with ongoing balloting. Maybe we focus on Patient to begin with…

Does that sound like a plan?

Cheers

Heather

I would do both Patient and Care Team plus associated Tel contacts, addresses, names etc. - we don’t actually need Patient for any live projects but Contacts/Care Team is a very valuable addition to almost any kind of care plan, advance directive, power of attorney … I’m not too bothered about the normative status or not - these things will continue to shift over time and will in any case require quite a lot of local extension/profiling.

2 Likes

Understand that we don’t need a patient, but the content should inform all our other requirements.

Makes alignment seem impossible, the way you describe it… :grimacing:

1 Like

@heatherleslie, if needed we might be able to help out. Spent a lot of time digging into FHIR patient and the challenges there.

Me too…

1 Like

Really a pragmatic effort :+1:

And alignment between the demographic and the clinical archetypes.

One thing we could do is just allow the same demographics Cluster archetypes to be used in EHR templates - I don’t think there is any real reason why this is not allowed just now -is that correct @thomas.beale?

Technically not. But the big problem with templates right now is that many of them are intended to model retrieval data-sets, and should be able to stitch together:

  • data from multiple dispersed Compositions in the EHR
  • data from multiple systems, particularly EHR and demographics

At the moment, a template is modelled as a single Composition, preventing both of these. I’ve made some attempts on getting past this - it requires some RM additions, but to no avail so far. However it’s probably the most important thing we do in the short term (also not complicated).

In this case, though we would actually want to embed persisted ‘demographic-type’ data in the EHR space. I agree with what you said but this is a different -use-case.

Brilliant, if we can avoid duplication we should. Unless we identify slightly different use cases.

@sebastian.iancu - - it would be good to get your perspective here.

yes sure, need to dive in :slight_smile:

Do you want to be able use demographic archetypes in EHR templates? This might be useful to model UIs, or to capture & design EHR+demographic data, maybe even to persist it. But at least in our system we separate these data, so I cannot contribute to much with such mixed archtypes/templates.
The archetypes and templates we are now using are 95% matching those published on CKM, which were originally based on ISO 22220:2011. In NL we need nowadays also to comply with HCIM (https://zibs.nl/wiki/HCIM_Release_2017(EN) ) and their FHIR implementation (https://simplifier.net/nictizstu3-zib2017), which I found it not that different. My midterm plan was to propose some changes on those archetypes on CKM, to support also these new requirements. Therefore I’m interested in syncing with others on this. @ian.mcnicoll, is it an idea to setup a call with all interested on this, to see where are we on this, how to go forward?