We have a use case in England where we need to record specific information about access to a person’s home (e.g. door security code or other access arrangements, for example “neighbour so-and-so has a key”), but that has been specifically excluded from the CLUSTER.dwelling.v0 archetype (https://ckm.openehr.org/ckm/archetypes/1013.1.3285), which states that:
“Not to be used to record information about the dwelling that does not impact on the health or health care needs of an individual. For example, the security access code for a home nurse visit should not be recorded using this archetype.”
We appreciate the safety/privacy concerns about storing this information but feel that something “softer” may be required, for example, advice about how to obtain the access code if it is held in some other secure place.
How are others handling this kind of information at the moment?
I’m troubled by the notion that a person’s alarm code might be recorded in an electronic health record. This is clearly not the right place for it.
However, I can also understand that it may be necessary in some circumstances where a healthcare provider might need access in an emergency or as part of community care. There is significant tension here. I think that the security access needs a different system, including access rules, for this kind of information. For example, if security access is recorded in the health record, what protection will be made in clinical systems to safeguard it - different role-based access? What if it is changed, especially if by a locksmith or non-health worker, and the health record not updated - is this not an even bigger potential clinical safety risk?
That said, and assuming you can sort the logistics out, deciding on the scope of this archetype was not easy. It is still under review and not resolved largely due to difficulty in defining the scope. There are lots of things about a house that might be useful to know eg internet access etc, but don’t impact directly on health. If we included everything about a house then the archetype would be a record of a building, not aspects of a home that are needed to know when caring for the health of an individual - a balance we are finding hard to achieve.
So we did add the SLOT for ‘Additional details’, precisely to capture the other messy stuff. In the short term this could be the place for a CLUSTER for your local purposes, although it makes me mightily uncomfortable to suggest it, and I will very possibly need to deny I wrote this post in the future
I share your anxieties but it is common to have some sort of information in the clinical record about domestic access e.g. “Neighbours in number 99 have a key” or "Call daughter to get access "
We asked our EoL clinical group about this recently and it seems that a common approach is to store things like key access codes in a secure part of a trusted system e.g one of the GP systems or with the ‘out of hours service’ and only open to a small number of staff, but that the broader patient record (the EHR) should contain something under ‘Domestic access’ like ’ Contact xxx at yyy for key code details’. That feels like a reasonable compromise.
There’s quite a big difference between these general phrases and adding an alarm code. I have no problem with general guidance on who to contact - this is common sense and the humans are then the gatekeeper - but 'key is under the third flowerpot to the left or ‘the’ alarm code is concerning and should be avoided.
Pondering it further, the notion of how to gain access or find people who have access doesnt’ really fit under the concept of the attributes of a house either. Perhaps we need to consider it as part of the social connectedness/network modelling - an ‘in case of emergency’ record of some sort.
Sorry I was off last week so just reading your messages now - thank you for responding! It is really helpful to know what the general thoughts/approaches are about access information, which obviously needs to be very carefully thought out. As Ian mentioned, the clinicians we spoke to agree that access codes should not be recorded in the EHR but information about how to obtain the access code might be needed, particularly for use in an emergency. As I understand it, this could be advice to contact a trusted relative/neighbour/friend or a healthcare provider/organisation that stores the access code in their secure system. If it’s the latter, then the Social network archetype wouldn’t really fit here either, but I do appreciate the challenge of maintaining the scope of the Dwelling archetype.
Another thing that came up in the discussions with the clinicians was pets - specifically, information about who can look after them if the owner is taken into the hospital. So it would be good to take a wider look at this kind of ‘in case of emergency’ information and social network modelling as you suggested - it’s not easy so would be great to collaborate!
This information maybe should be stored in a Demographic Server, isn’t it? An openEHR server different from where the one where the clinical data is stored.
I doubt the demographic model covers social data as it is right now.
Though it would be interesting to think of a Social Reference Model considering these and other requirements.
This is not new to openEHR, since the RM doesn’t cover everything, for instance reporting, epidemiology, analytics, etc. are not part of any openEHR model but needed in real solutions, and it would be wonderful to have a RM for those, which could be archetyped.
Agree. A new Entity model is being developed in the background, to cover more semantics than the current demographic one. It is for now an R&D kind of effort, but can potentially turn it into a fully specified model. It is already providing some new ideas that we can use now.
I have not thought much about the attributes being talked about here, but such information could clearly be added into the Party part of the model, most likely on Agent or Person.
Then indeed archetyping would do most of the work.
What I understood the attributes discussed here are kind of an INDICATION if we want to generalize the requirements discussed here. Like how to reach a certain place or what to do in case of A, B, C, etc. (like what to do with the pet if the owner is hospitalized, or who to call/notify in that case, etc.)
Not sure if others agree but I am very happy to carry all of these details pets, access, etc in the EHR. I don’t see any of these as demographic entities.
The only issue with carrying house access arrangements was really about privacy/security concerns.
They could go in either place I think. But in the EHR, to be long-term useful, they need to be in a persistent composition that is kept up to date. That’s essentially the same as demographic / social information, except maintained inside the EHR instead of within a demographic person record that can be accessed from multiple systems.
Of course if no such system is available for flexible storage of these additional data points (local MPI probably won’t have them), then the EHR may be the only place available anyway…
From the initial messages it looks like an indication of what to do in case something happens. Not sure that falls in the observation semantics, is kind of a conditional instruction.
