The ‘Person’ archetype has gone through 3 review rounds and is now ready for publication. It is part of a family of archetypes that are intended for use within the clinical recording process and in form building.
Feedback from all reviews, including the latest review, can be found here: Clinical Knowledge Manager. There were 2 reviewers who suggested a Major revision in the latest review round, but their feedback related to data that will be recorded outside the context of this ‘Person’ archetype, so did not prevent publication.
Quite reasonably, the notion of creating ‘EHR demographics’ archetypes has created a tension between clinical requirements and the use of demographic services in the past - you can see the previous Discourse discussion thread here: Demographic archetypes for clinical record purposes
The archetypes are absolutely not intended to take the place of a formal demographic service but to allow a standardisation of the ad-hoc recording of people within the health record, referrals, or registries etc eg a witness to an epileptic fit or someone who’s details would not be available in any relevant register.
There is clearly a ‘grey zone’ where you may want to record someone once and save them for future reuse - however, we see that as an ‘in application’ decision, rather than managed through archetype design.
Unless there are objections the ‘Person’ archetype will be published on May 2, 2022.
It would be interesting to understand why birth date is assumed to not qualify as an attribute in this archetype. I see the birth date as one of the standard ways of distinguishing between different persons with the same name.
In a demographic system or ISO standards this makes perfect sense, but we’re definitely not trying to mimic a formal demographic index - we’re simply building a subset of relevant demographic components into a coherent ecosystem of clinical models.
The purpose of this archetype is to name a person in the health record and record relevant details about them in the context of recording in an EHR, but definitely not intended for purposes of formal identification and providing evidence to support who they claim to be. The ID data elements are an anomaly within the maximal data set ideal and have been requested to support sharing of relevant info in some situations such as referral.
No one has provided a use case where the DOB of a witness to an accident or a provider needs to have their DOB recorded, it is usually contact details only. The notion of DOB in the context of an EHR is usually only relevant to the subject of care, so we have modelled it accordingly in the Birth details archetype.
EVALUATION.birth_details has been built as an intentional, maximal, clinical focus on birth information about the subject of care in an EHR, including the ‘Date of Birth’ (potentially multiple) and ‘Country of birth’ and other information about the pregnancy and birth itself. It is currently an early draft within an incubator, waiting for work on the metadata to be completed.
And the Birth details has been intentionally designed to align as much as we can with the EVALUATION.death_details, which has a similar pattern. Country of Birth can sit alongside self-identified EVALUATION.ethnicity and so on… towards that ecosystem.