# Demographic archetypes for clinical record purposes **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2021-05-07 06:18 UTC **Views:** 2440 **Replies:** 43 **URL:** https://discourse.openehr.org/t/demographic-archetypes-for-clinical-record-purposes/1534 --- ## Post #1 by @heather.leslie 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: - [Person](https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDAyZmVjMzI4N2ZiNzRjMmZhZjFjZWJkMjFiYjY3ZDQ3) - [Organisation](https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDM4YWMyYzA3YmRlMjRlN2I5NzhiZjgwYzJmMDZjNTk5) Please [adopt the archetypes](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949159/Adopt+an+Archetype) if you'd like to participate in the review process - [Person](https://ckm.openehr.org/ckm/archetypes/1013.1.5358) - [Organisation](https://ckm.openehr.org/ckm/archetypes/1013.1.371) - [Address](https://ckm.openehr.org/ckm/archetypes/1013.1.273) Regards Heather --- ## Post #2 by @damoca Why aren't you using the demographic RM to create those archetypes? --- ## Post #3 by @heather.leslie Simple answer - because they can't be used within a clinical template. And secondly they are overcomplicated for clinical purpose. --- ## Post #4 by @yampeku 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 --- ## Post #5 by @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? --- ## Post #6 by @joostholslag I'm happy with the initiative! Since we need a person archetype with a role element, for our care plan work. [quote="heather.leslie, post:1, topic:1534"] * 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. [/quote] 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.) --- ## Post #7 by @heather.leslie [quote="thomas.beale, post:5, topic:1534"] what should happen if the contact details of such people change? [/quote] ... 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 --- ## Post #8 by @thomas.beale [quote="heather.leslie, post:7, topic:1534"] 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. [/quote] 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|414x440](upload://k89UozDRHO5SPHubUbEyWJJOFgq.png) [quote="heather.leslie, post:7, topic:1534"] 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. [/quote] 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. [quote="heather.leslie, post:7, topic:1534"] 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. [/quote] Well we already have the solution: the [demographic model](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___18_1_83e026d_1433773264451_579451_7035) - I think it already does everything needed (we can certainly add things if needed, but it mostly relies on archetyping anyway). [quote="heather.leslie, post:7, topic:1534"] 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. [/quote] 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. --- ## Post #9 by @varntzen 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. --- ## Post #10 by @thomas.beale [quote="varntzen, post:9, topic:1534"] 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 [/quote] 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. --- ## Post #11 by @ian.mcnicoll 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. --- ## Post #12 by @ian.mcnicoll [quote="thomas.beale, post:10, topic:1534"] 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. [/quote] 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. --- ## Post #13 by @thomas.beale [quote="ian.mcnicoll, post:12, topic:1534"] we are missing role(s), which could be added to PARTY_IDENTIFIED [/quote] PARTICIPATION has function; if that is not enough, it's easy to add role as well. ![entry-participation|428x428](upload://o5yBWcNKn3tjMh0JnitBJJg3Oos.png) [quote="ian.mcnicoll, post:12, topic:1534"] but then we have a long tail of other, variable pieces of information - contact details, other comment, parent organisation details [/quote] 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. --- ## Post #14 by @thomas.beale [quote="ian.mcnicoll, post:11, topic:1534"] 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). [/quote] 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. --- ## Post #15 by @thomas.beale 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. --- ## Post #16 by @erik.sundvall 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](https://ckm.openehr.org/ckm/archetypes/1013.1.5605) and [openEHR-DEMOGRAPHIC-CLUSTER.person_death_data_iso.v0](https://ckm.openehr.org/ckm/archetypes/1013.1.492) (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](https://specifications.openehr.org/releases/RM/latest/data_structures.html#_cluster_class) classes are neither in EHR nor in DEMOGRAPHIC models, they are instead in the sibling level [Data Structures Information Model ](https://specifications.openehr.org/releases/RM/Release-1.1.0/data_structures.html#_overview) ![image|690x157](upload://9ZVbVLfNoFW64lfQ3WOACOiN0PK.png) I can imagine many detail CLUSTER instances that one at certain points would want to copy from some [registry/catalog/demographic](https://discourse.openehr.org/t/demographic-model-improvements/1645/2?u=erik.sundvall) 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? --- ## Post #17 by @thomas.beale 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... --- ## Post #18 by @joostholslag 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.. --- ## Post #19 by @thomas.beale [quote="joostholslag, post:18, topic:1534"] 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 [/quote] What migration do you mean? --- ## Post #20 by @joostholslag 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 --- ## Post #21 by @thomas.beale I was not really suggesting we do that; as far as I know the current tools have no problem with either openEHR-EHR-CLUSTER.device.v1 or openEHR-DEMOGRAPHIC-CLUSTER.device.v1, and it's easy to make a regex allowing both: `openEHR-(EHR|DEMOGRAPHIC)-CLUSTER\.device\.v1\..*` --- ## Post #22 by @ian.mcnicoll They could do it but they don't do it right now. At least not the Ocean / Better tools @yampeku . I'd be in favour. --- ## Post #23 by @yampeku If regex are correctly defined, then no problem including any of the archetypes that are allowed in that regex. Demographic clusters are allowed to be created/edited in linkEHR in any case --- ## Post #24 by @erik.sundvall If we want to add a choice of also picking some more neutral string (in addition to the present EHR or DEMOGRAPHIC) for the `model` part of publisher-**Model**-Class.concept.version, then such an ID choice/renaming could in the future be considered... * ...when a **new** CLUSTER archetype of shared interest **is created** or... * ...when for some reason a **new major (breaking) change is needed anyway** for a CLUSTER archetype of shared interest --- ## Post #25 by @yampeku I would assume that other things apart from archetype_id could be used for slot definition, probably things like TYPE or CLASS (e.g. "TYPE='CLUSTER'"), BINDING (e.g. BINDING=< Use to record details of a person/structure name of a ** as they are known or understood in the course of clinical documentation, often ad hoc or when it is not appropriate or possible to use a formal demographic register/index or address lookup service. Misuse always states context-appropriate statements such as: > Not to be used to represent or replace formal identification management or for the purposes of maintaining an official demographic register or index. Use a formal Health Provider Index for this purpose, or archetypes based on the openEHR Demographic Information Model. > > Not to be used to represent the location of care and similar data elements that should be represented formally in the health record using the Reference Model attributes. These archetypes are out for review until April 8. If you would like to participate and have not received an invitation in your email box today please [adopt each archetype](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949159/Adopt+an+Archetype) and you will be added. Regards Heather --- ## Post #30 by @atapuria Hi, Would you label the demographics related achetypes as 'clinical' or 'admin'? --- ## Post #31 by @heather.leslie Hi Archana, [quote="heather.leslie, post:29, topic:1534"] there are many clinical and/or modelling use cases that require these models. I am certainly getting repeated requests from modellers - ‘We really need these archetypes’! One of the most critical use cases is to consistently record information where the person, organisation or address will never ever be found within any relevant registry/index/service. [/quote] These ones in the [Demographics EHR archetypes project](https://ckm.openehr.org/ckm/projects/1013.30.104) are developed using the EHR reference model, based on ISO standards, and intended for clinical modelling or documentation purposes only. They are definitely not intended for use as part of a formal demographic service. --- ## Post #32 by @pablo [quote="erik.sundvall, post:16, topic:1534"] Why are CLUSTER archetypes prefixed with EHR or DEMOGRAPHIC? [/quote] IMO DEMOGRAPHIC model on the CLUSTER archetype ID is wrong, since CLUSTER is defined in the representation package inside EHR. --- ## Post #33 by @pablo [quote="heather.leslie, post:29, topic:1534"] In anticipation of pushback again from the technical/specs purists, we understand your issues but there are many clinical and/or modelling use cases that require these models. [/quote] It would be useful to contemplate these use cases against the current models to find the gaps, since @thomas.beale keeps finding ways of modeling different use cases with the current model. On the other hand, modeling tools are not there yet with the demographic model, maybe if tools allow to use the demographic model in full, we could use that model more. It's also true that the current demographic model needs some fixes and have been left aside from reviews and improvements in the last 10 years. --- ## Post #34 by @ian.mcnicoll The issue is not really that there are gaps inthe spec or models but these are the issues we encounter... 1. For clinical users it is not uncommon for us to be asked to carry a few more details in the CDR than is allowed for in the RM e.g. in a recent project we have been asked to carry the clinician name, ID, role and speciality in the CDR. THis information is maintained in a staff directory but we do not have access, and the customer has sked us to put these detailsin the CDR for clinical sense-making. 2. Similarly external reports like lab reports often carry additional information like lab address or lab specialist contact number, and these need to be stored in the CDR, as these details are not otherwise accessible, other than from the lab message. 3. There are other structures like Emergency personal contacts or professional contacts that are specific to care pathways. In theory, the professional contacts should be maintained in a demographics store but of then this does not exist, or is not accessible/maintainable and even if it , it may not support the additional requirements for Emergency contacts. 4. Unfortunately the inability to extend PARTY . PARTICIPATIONS in the RM via a cluster slot means that we often have to add these EHR Demographics clusters in odd places - this often means that we have to ignore Participations (see project above) and essentially recreate Participations in a Cluster archetype that does allow some extensibility. Adding a other_details slot attribute to PARTY_IDENTIFIED would go a long way to making this much more rational and understandable to modellers. Having said that the basic problem is that in many/most of the projects we have worked with right now it is simply impossible to have a completely clear separation of demographic details into the demographics space, and that is probably never going to go away. This really has nothing to do with the Demographic RM or models, or indeed tooling. --- ## Post #35 by @thomas.beale [quote="ian.mcnicoll, post:34, topic:1534"] Adding a other_details slot attribute to PARTY_IDENTIFIED would go a long way to making this much more rational and understandable to modellers. [/quote] I think we agreed on this in principle a long time ago, although I can't put my finger on a CR or PR documenting that so far. But do you want another Cluster inside PARTICIPATION as well as one on PARTY_IDENTIFIED? --- ## Post #36 by @thomas.beale [quote="ian.mcnicoll, post:34, topic:1534"] Similarly external reports like lab reports often carry additional information like lab address or lab specialist contact number, and these need to be stored in the CDR, as these details are not otherwise accessible, other than from the lab message. [/quote] As we've discussed before, over the course of accumulated events in thousands of health records, much of this data will be replicated through all those records, since the labs and other imported data come from the same places (for the receiving institution that has the EHRs). Errors and omissions in recording that data can't be realistically fixed, because there will be no way to track them. I don't know whether such replication is currently thought to be the preferred solution, but it sounds pretty bad from a data management perspective. An easy solution architecturally to address it is to create a special 'EHR' within an openEHR CDR EHR service (I have proposed in the past, with a special number '0', i.e. the Guid '0' or some other special Guid) that contains normal Compositions containing ADMIN_ENTRYs containing the relevant provider demographics. These would be archetyped using the EHR flavour of demographic achetyped, but would also be properly versioned, and would be *referenced* by the PARTY_IDENTIFIED EHRs in that service. This will give the effect of close to having a versioned demographic service without actually doing so, and would require minimal engineering by CDR implementers. --- ## Post #37 by @pablo [quote="ian.mcnicoll, post:34, topic:1534"] For clinical users it is not uncommon for us to be asked to carry a few more details in the CDR than is allowed for in the RM [/quote] Doesn't that have more to do with the implementation than IM or archetypes? I mean, what the user sees is not only information from the CDR, each screen has integrated information from many sources, CDR included. So the requirement of having some data physically stored in the CDR is more a technical decision than a user requirement, isn't it? For instance, in [Atomik](https://atomik.app/) we support storing EHR and DEMOGRAPHIC in the same physical database, based on respective EHR and DEMOGRAPHIC OPTs. Then the end user in the end system will see the same information independently of which repository was used to store the info. The same thing would happen if an architecture has 10 different systems like an MPI, clinician directory, CDR, contracts, consents, admission, etc. all as different services/repositories, the user, at the end, will see all information integrated in one screen. Of course, for this to happen, the platform should be capable of resolving those references between different repositories, so the end user doesn't really know where is the data physically. Note this is in the tone of a question, I don't have strong opinions about what Heather posted initially, just curious about if that is the best solution or if it's just an interim one while we fix the demographic model and modeling tools. [quote="ian.mcnicoll, post:34, topic:1534"] these need to be stored in the CDR, as these details are not otherwise accessible [/quote] Same question, are not accessible because of technical implementation constraints of because something that has to do with the IM or archetypes? [quote="ian.mcnicoll, post:34, topic:1534"] Unfortunately the inability to extend PARTY . PARTICIPATIONS in the RM via a cluster slot means that we often have to add these EHR Demographics clusters in odd places - this often means that we have to ignore Participations (see project above) and essentially recreate Participations in a Cluster archetype that does allow some extensibility. [/quote] That might be actually a gap between requirements and IM/archetypes. It would be worth to specify the requirements, document the gap to the current demographic IM, and use those notes as input for the new entity model. [quote="ian.mcnicoll, post:34, topic:1534"] Having said that the basic problem is that in many/most of the projects we have worked with right now it is simply impossible to have a completely clear separation of demographic details into the demographics space, and that is probably never going to go away. [/quote] That's kind of the question to answer: why is that? is that demographics lack expressiveness? because modeling tools don't support demographic archetypes and templates in full? because modelers are not familiar with the demographic model? because implementers feel it's convenient/easier/direct to do it that way instead of pointing to the demographic model via PARTY_PROXY? Again, I don't have a strong opinion here, just trying to understand since I'm not 100% convinced that this is the right path or the only path. --- ## Post #38 by @heather.leslie [quote="thomas.beale, post:35, topic:1534"] I think we agreed on this in principle a long time ago [/quote] [quote="thomas.beale, post:36, topic:1534"] As we’ve discussed before [/quote] The discussions have not been with the leaders of the clinical modelling efforts in CKM. [As I've said before](https://discourse.openehr.org/t/collaboration-between-programs-and-tooling-vendors/1942), there is a serious disconnect between specs program decision-making and modelling program requirements. Nothing has changed. If both aren't operating in sync then the organisation has a problem. --- ## Post #39 by @thomas.beale [quote="heather.leslie, post:38, topic:1534"] The discussions have not been with the leaders of the clinical modelling efforts in CKM. [As I’ve said before ](https://discourse.openehr.org/t/collaboration-between-programs-and-tooling-vendors/1942), there is a serious disconnect between specs program decision-making and modelling program requirements. Nothing has changed. If both aren’t operating in sync then the organisation has a problem. [/quote] Well we have had numerous technical discussions over the years on purely architectural concepts. As I'm sure you'll appreciate, the technical part of any organisation needs to have such discussions in order to get its ideas straight. We have had many subsequent discussions that have included yourself and other clinical modelling experts. No doubt we need more. Let's continue to look at the details of what is needed to marry technical good practice (e.g. non-replication, sustainable modelling, representational clarity) with clinical and business needs and realities. That's what this discussion is for. --- ## Post #40 by @pablo Wouldn't the NL conference be a good place to have a SEC + Clinical discussion on open topics? --- ## Post #41 by @sebastian.iancu Yes, we can. I know some about technical discussions we had over the years (and I don't think I should revive them here now) - but I'm not sure I heard all of the requirements/wishes from clinical program. There is a chance though that some were driven by practicality - i.e. Implementation issues. --- ## Post #42 by @ian.mcnicoll I agree there is a gap in having a space to thrash out some of these issues which have an impact on both modelling and specs. - would it be worth setting up a specific Discourse channel for these? --- ## Post #43 by @pablo A channel for this would be good. Though I think this deserves a F2F or even an online workshop so modelers can expose their use cases and gaps they detected, and from the SEC we can gather requirements to improve specs or tooling. It's difficult to explain just via text. --- ## Post #44 by @thomas.beale I'm inclined to think that a Confluence page(s) would be a good place to gather requirements from clinical / vendor / business side --- **Canonical:** https://discourse.openehr.org/t/demographic-archetypes-for-clinical-record-purposes/1534 **Original content:** https://discourse.openehr.org/t/demographic-archetypes-for-clinical-record-purposes/1534