Hi Thomas, I have been monitoring the messages and have a keen interest in security issues (background in secure operating systems and Enterprise storage). Patient Centered Healthcare Informatics is a main focus currently.
This thread is really going well! I would like to add to it: 1)Many of the current security systems address organizational security, e.g., hospital, clinic, practitioner.The goals in many cases conflict since issues related to the applications identified often clash. For example, assuming a compartmented security system in which all of these applications participate is usually unable to handle participation by a new application, e.g., patient security (US versus EU). Modifying or eliminating the existing system to accommodate a new application is probably over-reacting. Building a security interface to a separate system appears to be more efficient. 2)By their nature security systems are not flexible. Suggesting this one would likely result in extended conversations. 3)Security systems obscure both data and relationships, e.g., who did what, when, where and what happened. By necessity they implement walls. 4)Security systems are often compromised by information working relations and people, e.g., a secure, compartmented operating system can neither monitor nor control conversations at the coffee machine. Another example is control over printed secure data. 5)Secure systems are effective only when security process, procedures and data are monitored, controlled, protected and violations are prosecuted. 6)Security overhead is enormous and expensive. 7)Cost-effectiveness of security systems is essential. 8)Secure systems and networks have a hard time communicating. This is an overview meant only to cover my background. With an interest in Patient Centered Healthcare that includes security I believe that a Secure Data Store in conjunction with Patient unique applications can provide secure Patient -controlled, secure Healthcare records. Selection of and control over the Secure Data Store is exercised by the Patient with the market providing a selection of services. Data transmission can be accommodated using appropriate protocols and implementations such as the US HIPPA. Obvious modifications would include Patient permission and Public Health mechanisms. Organizations and Practitioners would be able to choose a security system that suits their purpose and is able to communicate with other over a set of standardized, secure data transmission systems using perhaps different send/receive filters, e.g., versioning, paths. At all points NEED TO KNOW governs access and data records are composed of multiple physical records with secured components, each component potentially unique. My preference is for appropriately encapsulated, time-and access-limited, secure objects, each entity (e.g., Patient, Hospital, Clinic, Practitioner) generating their own. This overall mechanism could include OpenEHR records accessible via standardized applications. It could include others as well. COMMENT: There is significant potential for misuse between two or more users of OpenEHR records. These records must have their own security mechanisms. They should be affected to some extent by other security systems that transmit them, e.g., security trailer tracing handling back to sources. Security monitors should be able to review and audit the trailers. Security verification should then close loopholes. Security consistency checks can verify multiple local and remote copies. UPDATES Updates to OpenEHR records looks like a problem. If several organizations, Practitioners and the Patients start communicating and updating OpenEHR records it can result in a significant update problem, e.g., delayed reports, as well as a major security problem. One might consider the assignment of an ADMINISTRATOR OF UPDATES to sort this stuff out, which also could result in use of Secure Data Stores to handle temporary files and other information. SECURITY REVIEWS This is a big one. In a potentially global system security can't be standardized. The systems and networks are usually different as is the user community. In this regard, security must be adaptable and reviews tailored to the local environment. ACCESS Role-based access is central. However, it must be limited, e.g., by the Patient. There should be other models as well. For instance, prior to surgery I would like to DEDICATE ACCESS to a practitioner who in turn IDENTIFIES members of a TEAM and ASSOCIATES (including organizations) involved in a current procedure. It would a time- and function-limited dedication. Nationwide role-based access may be good for Public Health personnel but role-based access for all Physicians in Canada is NOT a great idea, e.g., there probably would not be interest and dissemination of or wide access to secure, private information violates many security requirements. Emergency-based access is crucial. In a variety of situations one would not necessarily be in a position to grant access. A nationwide emergency access mechanism is definitely a good idea. CONCLUSION OpenEHR security should: 1)address record-based security issues 2)produce a structure that would support information transfer with other security systems 3)integrate access control from identified, global primaries 4)support security applications to monitor, review, audit and control individual and groups of records 5)support reporting and review to primaries Security systems attempt to structure data transmission ----- Original Message ----- From: "Thomas Beale" <[email protected]> To: "Bill Walton" <bill.walton at jstats.com> Cc: <openehr-technical at openehr.org> Sent: Friday, April 25, 2003 12:53 PM Subject: Re: openEHR security > > Hi Bill, > > good questions.... > > Security has been thought about, and is still being thought about! > Essentially there are a number of aspects: > A - what is the model of access control - the main problem here is > different definitions of roles in different "bricks-and-mortar" > institutions at which the one patient might appear (I shouldn't really > say bricks-and-mortar, since we include emergency health workers, social > workers, mobile nurses etc) > B - what is needed in the EHR architecture (i.e. what we call the > "openEHR reference models") to support security/privacy requirements? > What is the granularity of privacy control required > C - how is information to be protected when it moves? > D - the related issues of encryption, notarising (for legal protection > or investigation of previous clinical acts) > E - who sets the privacy settings which control how secure access occurs > at runtime? > > We have not yet written a comprehensive document on this. However, we > think we know a fair few things, mainly based on the ideas of other > people. Work has been done at the DSTC in Australia on many aspects of > security, including a national PKI proposal. Bernd Blobel has probably > described security and health information in the most detail that I know > of, in his various papers and recent book. The US GCPR project probably > made more progress on security in the CPR than it did elsewhere. > > So. What do we know? > - role-based access control is required. To make it work properly in a > shared care community context (e.g. a hospital, 50 GPs, aged care homes, > nursing care, social workers etc etc) then the roles need to be defined > congruently. I seem to remember some Canadian project coming to the > conclusion that really the roles need to be defined the same across the > entire (national) health care system. I think this is both correct and a > the same time unrealistic. I think we will be able to find ways of > having diversely defined roles without every health care facility having > incompatible definitions of "consultant", "treating physician" etc. > Bernd's work on this area is pretty detailed. > > - the EHR architecture does not need too much complexity added to > support consent-based secure access. We currently think it needs to have > the ability to store something like 'sensitivity' and access control > group id(s) at each 'significant' (i.e. not the smallest) node, the > lowest being the openEHR Entry. The access control groups will > themselves be defined in their own service. > > - when the decision is being made at runtime to grant or deny access to > a certain part of the EHR to a certain user, the user role (already > authenticated etc etc) and access group ids in the piece of EHR > requested are compared to the access group definitions. Further, some > way of establishing _relevance_ of this user accessing that bit of the > EHR is required - i.e. the link between the patient and the user who is > a treating physician, or on a team providing care. Other users who are > not providing care would probably be treated differently. Certificates > would be created if access is granted; these might be time-limited > (again I think Bernd has experience in time-limited access); they might > be more like keys if we are talking about sending the data outside the > secure environment in the form of an encrypted extract. > > - the patient or competent guardian must be the setter of consent, but > most likely with the professional advice of the physician. > > - the problem of what categories or ways a patient could set consent is > hard to define - I don't think anyone has worked it out. If a patient > wants to say "exclude family from access to my mental health EHR items" > - which items are "mental health"? Some obviously are, but if other > mundane items are useful to mental health clinical professionals, do we > exclude them or not? Or.... do we allow the patient to set consent just > on individual items? THis will not be realistic for most patients - they > would have to trawl the record after every addition setting consent all > over the place. Could it be set on the basis of problem? How does > "exclude all users except treating physicians from accessing HIV/ADIS > information". WHat information is HIV/AIDS related? Certain drug > prescriptions clearly are, but so are certain patterns of common > infections; a medically competent user could identify a person suffering > AIDS even if the obvious items were blocked. > > Philippe Ameline, the producer of the Odyssee product has some really > interesting ideas in this area - patients set traffic light colours in a > dartboard representing access control to each unit of the record. > > - I think notarising is relatively easy to solve technically - just a > case of working out a scheme whcih works in a distributed environment. > Hashes need to be generated for each item and sent to a trusted third > party notary service. > > > Audit trails are taken care of inside the architecture - have a look at > the definition of the classes Transaction (EHR RM), Entry (EHR RM), and > the change control classes (COmmon RM). All relevant party ids, dates, > times and locations are recorded (or so we believe!). > > > - thomas beale > > > > Bill Walton wrote: > > > Sam, > > > > Thanks much for sending that along. I haven't made my way through all > > the examples yet, but I like where you're going. A few questions / > > comments if you don't mind. > > > > First, and perhaps you consider this a seperate issue that's out of > > scope for Access Control, but what about Audit Trails? In addition to > > the choices / decisions you summarize on Page 3, I believe there's a > > key question the system needs to be able to answer: "Who has had what > > access to my records?" To answer this question it looks to me like > > the system needs to maintain two types of information: 1) a history of > > the changes to the Access Control List, and 2) a history of accesses > > to the EHR itself. Further, it looks like the EHR access history > > should include reads as well as writes. That way, the trail would > > lead to the providers that have, with permission, made copies of the > > EHR within their own systems. > > > > This is tied to the first question I think, but how does the system > > deal with the needs of Consulting Physicians and Researchers who are > > not going to provide care, but may need read access to the full > > record? If I read this correctly, the mechanism controls what > > information can be accessed, but not the type of access permitted > > (i.e., read vs. write). > > > > How do Emergency medicine providers get access to the records? It > > looks like there needs to be an override to allow the timely delivery > > of service in Emergency situations. It would seem to me that the > > existence of the Audit Trails above might calm fears of inappropriate > > access. > > > > Related to all of the above, it seems like there are probably a number > > of circumstances that would require that the control of the Access > > Control list itself be capable of being over-ridden or delegated. It > > looks to me like, as currently defined, the only roles that could > > grant access would be the patient and Next of Kin roles. But assume, > > for example, that a patient is hospitalized, needs a test performed > > that can't be performed in the facility, and has designated a Next of > > Kin that's not present. Perhaps it's just a difference between our > > systems, but in the U.S. I can imagine a need to delegate the right to > > change the Access Control list without delegating some of the other > > decisions (e.g., "pull the plug") that are associated with Next of Kin > > here. Again, as long as the Audit Trails are in place it seems that > > fears of inappropriate access might be effectively balanced against > > the needs of providers re: access to the records for the purpose of > > delivering the appropriate care. Or perhaps I'm misunderstanding the > > Next of Kin role. > > > > What's an EPR, what's in it, and what, if any, information overlap > > does it have with an associated EHR? You introduce EPR in the first > > example, but there's no definition provided and no reference to an > > external source. > > > > This is a really interesting problem space to me. I've been studying > > HIPAA (the Health care Information Portability and Accountability Act) > > and have become fascinated with the discussion over how best to > > balance the needs of the various parties involved in the provision and > > payment of healthcare services so as to improve the quality and > > decrease the cost of health care here in the U.S.. Talk about a > > non-trivial problem! Interestingly, it looks to me like all > > the nonsense can be traced back to the health record and some > > fundamental questions about who owns it, who controls access to it, > > etc. Thanks again for sharing. Hope to hear from you soon. > > > > Best regards, > > Bill > > > > > > ----- Original Message ----- > > From: Sam Heard <mailto:sam.heard at bigpond.com> > > To: Bill Walton <mailto:bill.walton at jstats.com> ; > > openehr-technical at openehr.org <mailto:openehr-technical at > > openehr.org> > > Sent: Wednesday, April 23, 2003 6:10 PM > > Subject: RE: openEHR security > > > > Bill > > > > Security and the EHR - ah theres a question! At least having a > > reference model of the EHR makes this something that might be > > tackled effectively. The current openEHR model has and access > > control feature on ARCHETYPED in the Common Reference Model. The > > idea being that anything that can be archetyped - that is, it is a > > coherent clinical composition or concept - can have its access > > controlled. > > > > It is envisaged that the EHR will have an access control list > > which can be transfered to other centres as part of an extract if > > required. This requires standardisation of access control groups. > > We have done some work in Australia to get a set of access groups > > that could be standardised across health care and I enclose a copy > > of this document for your consideration. > > > > Hope this is a start - very interested to work with you on this! > > > > Cheers, Sam > > > > -----Original Message----- > > From: owner-openehr-technical at openehr.org > > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bill > > Walton > > Sent: Thursday, 24 April 2003 7:36 AM > > To: openehr-technical at openehr.org > > Subject: openEHR security > > > > I apologize for not having had the time to dig in and find > > this out for myself yet, but I'd really appreciate it if > > someone could tell me if security has been addressed in the > > openEHR architecture and, if so, point me to the > > documentation. I'm trying to understand the system's > > capabilities to limit access not only to authorized > > individuals, but also to limit the access of authorized > > individuals to specific subsets of an individual's record. > > Thanks in advance for showing me where to dig. > > > > Best regards > > Bill > > > > -- > .............................................................. > Deep Thought Informatics Pty Ltd > mailto:thomasXXX at YYYdeepthoughtZZZ.WWWcom.AAAau (remove all caps) > > openEHR - http //www.openEHR.org > Archetypes - http //www.deepthought.com.au/it/archetypes.html > Community Informatics - http //www.deepthought.com.au/ci/rii/Output/mainTOC.html > .............................................................. > > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
