Hi Dr Sam Heard Thank you for this informative expose.
> This is an interesting area. Our approach in the openEHR development > space has been: > * To try and get a set of 'relative roles' accepted (presented > at ISO) across the health environment to enable standardised > policies to be available for people passing health information > to a particular environment. These included concepts such as: > * Guardian > * Trusted clinician > * Clinician > * Administration > * Subject of data (to allow exclusion under special > circumstances) I am particularly interested in Role-Based Access Control (RBAC) approaches and methods for healthcare information systems - roles being a prominent feature of the healthcare environment. I think the fact that policies could be developed, formalised and made publicly available is quite important. > * rol to be specified in terms of such roles (or roles > specific to an institution) to whatever level of > granularity is deemed appropriate. It would be interesting to see role-based security approaches and methods within the context of existing EHR standards (e.g., opnEHR) and their implementations. > 1. Access control policies must be written at each location in > language that an ordinary person can understand - hence the > five relative roles. This probably needs to be done in terms > of a known standard EHR architecture or it is just words. To what extent can the RBAC work in SELinux help to inform standard EHR implementations? Would these be totally different and is this link way off the mark - SELinux being an OS-level implementation of RBAC policies? > 1. That the EHR is divided into three core folders (openEHR > speak) > 1. a public folder that can be accessed without further > patient provided authority (severe allergies or > whatever else the person wants) > 2. the normal confidential record that requires specific > access permission (default location) > 3. a highly confidential area where patients can put > compositions that require a further authorisation > process. > This would probably be a "EHR zone vs Security level" scheme used in combination or within the context of the RBAC security scheme. This would also probably imply definition of system default "zone/level" access rights. I am wondering whether or why RBAC alone is not enough, especially, where there is enough flexibility at each level of granularity of the EHR. Also to what extent would be the "zoning" of the EHR be that clear-cut in terms of privacy and confidentiality? Is this not too rigid a structure for the EHR? I was also wondering whether flexibility and finer granularity could be achieved by having such a security zone/level scheme in each folder/sub-folder such that for each folder there are these three levels or altermatively the levels could be mutually exclusive tags for each item of the EHR. > The mechanism for getting to level 1, 2 or 3 access > will depend on the service environment, and whether > the person carries their own record or it is on a web > site somewhere. Question: Do security and privacy concerns differ with service environment and/or physical location of the EHR? > > 1. Limiting access control within a committed composition > (openEHR speak) or document is of dubious safety and I do not > believe it is acceptable to clinicians. Here we might see a > report from a cardiologist with a bit missing, or a medication > list with one omitted. This will mean clinicians have to ask > everyone they see every time they see them as they will not be > able to rely on the EHR. And automated decision support > becomes a nightmare! So it is important to keep access > coherent and for clinicians to be able to trust what they can > see. This does shade some light on some of what I said above. Would it help if access permissions are granted in a durative manner and access rights are hierachical, prioritised, role-based and scoped such that there is a scheme for auto-granting of rights that ensures that a cardiologist with sufficient permissions always gets all the info he needs to create a full report? however, auto-granting of rights may imply need for decision support. Regards ---- Kuda > Cheers, Sam > > Kudakwashe Dube wrote: > > Dr. Irving Buchbinder, > > > > The long-term goal of the project is to develop a standards-based EHR > > system and a patient-maintained EPR system such that the two will be > > able to interact with each other. We are at the initial point where we > > are reviewing existing EHR/EPR systems and standards around the world > > with the aim of making informed choices. My specific responsibility at > > this point happens to be investigating security, privacy and > > confidentiality aspects of healthcare information management. I am new > > to both computer security and healthcare information security, privacy > > and confidentiality - I'm just taking my initial steps in these domains. > > > > True, security and privacy are not the same. I have noted that in > > literature on EHR/EPR, there is reference to "security and privacy" and > > sometimes to "privacy and confidentiality". I am not sure whether these > > references refer to the terms' meaning in computer security or in > > healthcare profession/domain or whether or not the terms mean the same > > in both domains. We welcome technical clarification of these concepts > > (security, privacy and confidentiality) in the context of healthcare > > information management and/or EHRs. > > > > I am currently studying your distribution. > > > > Thank you > > > > Regards > > --- > > Kuda > > > > > > On Fri, 2008-03-14 at 14:52 -0400, Dr. Irving Buchbinder wrote: > > > > > Greetings > > > > > > How, specifically, can we help you. We maintain an open copy of our > > > distribution so you can look to see how privacy is maintained. > > > Security and privacy are not the same. What sort of project are you > > > doing? > > > > > > I hope we can help you.. > > > > > > On Fri, Mar 14, 2008 at 1:52 PM, Kudakwashe Dube > > > <kd.open.ehcr at gmail.com> wrote: > > > Hi All, > > > > > > I'm just beginning a research project on > > > security/privacy/confidentiality in EHRs. I will greatly > > > appreciate any > > > pointers to any material on this topic, especially with > > > respect to > > > openEHR. > > > > > > I've just noted that in the US, HIPAA is driving > > > security/privacy/confidentiality implementations in existing > > > EHR systems > > > and it seems its is turning out to be a policy/framework-level > > > security > > > standard for EHRs in the US that does not prescribe > > > implementation > > > issues. I am not sure whether or not EHR standards that > > > incorporate > > > HIPAA compliance have emerged yet. > > > > > > In the EU region, the situation seems different in the absence > > > of > > > HIPAA-type punitive legislation for enforcing healthcare > > > information > > > security and privacy. A number of EHR standards generally > > > incorporate > > > security and privacy considerations. I am not sure whether > > > there are any > > > security and privacy compliance requirements spec standards > > > and > > > implementation (incl. openEHR) in the EU region. I will > > > appreciate any > > > pointer to material in this regard. > > > > > > Thank you in advance > > > > > > Regards > > > ---- > > > Kuda > > > > > > _______________________________________________ > > > openEHR-technical mailing list > > > openEHR-technical at openehr.org > > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > > > > > > > -- > > > -- > > > Irving J. Buchbinder, DPM, DABPS > > > Director, FreeMED Software Foundation, INC > > > -=Technology advances. People stay the same=- > > > Leigh Rubin > > > skype at irvbuchbinder > > > > > > *** E-MAIL CONFIDENTIALITY *** > > > This e-mail may contain confidential and proprietary material for Any > > > review or distribution by others is strictly prohibited. If you are > > > not the intended recipient please contact info at freemedsoftware.com and > > > delete all copies. > > > _______________________________________________ > > > openEHR-technical mailing list > > > openEHR-technical at openehr.org > > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > > > -- > > Dr Sam Heard > Chief Executive Officer > Ocean Informatics > > Director, openEHR Foundation > Senior Visiting Research Fellow, University College London > Aus: +61 4 1783 8808 > UK: +44 77 9871 0980 > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
