I’m working on research on ways to provide privacy in EHR systems. So basically my idea is to provide privacy requirements for EHR systems as consent, integrity, auditing, auto logoff and so on. I saw in the documentation that there are some requirements that the systems developed by EHR must have. However, I would like to know how I can model this type of requirements within openEHR, for example if they would be through archetypes or reference models even if there are other ways to model these requirements within the openEHR platform specifications.
I’m new to the community, so my doubts may seem too simple
Hi Rodrigo,
Cool question. Could you give some examples as to what kind of requirements there are and what (mock) data would look like?
My first brainwaves go towards an admin entry archetype with a name like privacy preferences. But that’s only for individual’s preferences. Design requirements like auto loggoff are generally not part of the patient Electronic Health Record, since they don’t very by patient.
There is a CKM archetype informed consent btw.
consent: currently modelled by specific data sets defined by archetypes; future, will most likely be strengthened to be a special part of the EHR (look in CKM for these)
integrity: there are various features to support integrity, including versioning, possibility of digital signing; obviously proper DB management and general deployment environment contribute as well;
auditing: openEHR has internal audits built into the versioning system; in a platform ecosystem, many implementations rely on an IHE ATNA-based system log that records all reads and writes to the CDR.
There are many details related to this area, but also some features not handled as well as they should be in openEHR; hopefully the above list is a start.
Privacy is a very broad subject. But I was thinking of a way to model these requirements so that (who knows) they might become standard in an EHR system. I saw that there are some initiatives like the ones you mentioned above, so I would like to know how you would go about developing something similar?
some requirements I’m researching would be: Access Control, Emergency Access, De-Identification, Audit Control, Integrity, Secure Transmission, authentication, consent, Encryption and Decryption and Automatic Logoff. as you mentioned before, indeed some requirements are aimed at EHRs and others are directly related to patient data.
You are very welcome to contribute to this area in openEHR - like I say, it is not anywhere near comprehensively covered yet. One area might be a proper model of consent, as first order objects in the EHR that can be used computationally. Right now consent is only modelled as agreements in documents that are added to the EHR. Computationally processable consent would be a whole new thing.
That’s just one area - depends on your interest and needs. @joostholslag mentioned a bunch of other useful things as well. Maybe provide some more details about your interests and needs, and we can show you what is (and isn’t) there already.
This one is interesting to me and a major opportunity for openEHR. Currently afaik there is an EHR_ACCESS class, which allows storing acces control settings at the EHR level. The logic for enforcement is not specified in openEHR.
What we do a lot is authorise acces on the composition and instance of composition level by discipline “e.g. nurses may see the compositon.problem_list and for EHR of mrs. Janssen they have editing writes as well”. And “this compositon.report instance is viewable to nurse, doctor and physical therapist.”
This fine grained control is still missing from openEHR but is essential in federated/networked deployments where CDRs of different vendors need to be able to enforce each others policies. Open policy agent may be an interesting project to look at.
Actually I believe the enforcement by other CDRs can never be delegated, so it should be solved by encryption imho. I would like compositions in the CDR to be encrypted with another app to manage the keys not the CDR to solve the db admin problem. This does create major problem off course, specifically around querying data with AQL.
Another major question is how to do authorisation on parts of a composition (default should be just don’t off course, but there’s a good reason why we do support it in our legacy app)
Emergency Access
This one is really interesting as well, it’s 1. defined by system wide legal requirements, 2. The organisational policy 3. The personal preferences of the EHR subject.
De-Identification,
This one is also very interesting to me, especially in data analysis/export scenarios. I’m thinking supporting syntax for blacked out data values and individual words.
authentication
Authentication should be outside the scope of openEHR since it’s not healthcare specific so we should not try to do it ourselves.
Automatic Logoff
I feel this one is outside the scope of openEHR but should be a client app responsibility, since it may depend on many factors outside the control of the CDR, like type of device, location etc.
It is missing because no-one (in the industry) has ever managed to describe a formal model of it, beyond just the simple idea of ‘sensitive’ v ‘non-sensitive’ data (and maybe ‘emergency data set’).
One of the standard problems (recognised back in GEHR days - 1994) is that EHR data is all connected. Wanting to hide e.g. HIV or mental health Dx doesn’t achieve secrecy if the Rx list contains drugs obviously for those purposes. But if the Rx list is hidden, docs can’t do anything at all (at least not safely).
Our main need for point of care is to formally model authorisation and consent; for secondary processing, de-identification and related things (GDPR rules).
Just to re-iterate another ancient bit of wisdom: it has been found (US hospital studies) that banners on the screen reminding HC professionals that all their EHR accesses (of any kind) are logged and could be verified for appropriateness vastly reduced inappropriate EHR access. So access logging + basic psychology does quite a lot.
At the time I was thinking of something like modeling the standards service so that no moment of development of a EHR system could be used as a reference, for example, which fields would be used and what information could be passed on. However, I fess up that I still need to understand better how openEHR works.
