Kudakwashe Dube wrote: > > > 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. > > this is happenin in openEHR. You will note that the current version of openEHR has an EHR_ACCESS class in it (see http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109004889781_854011_47Report.html) whose settings are defined by another class ACCESS_CONTROL_SETTINGS (see http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1155650882301_836618_5314Report.html). In a future release, this latter class will be specialised into classes representing the CEN EN13606-4 security model, the ISO PMAC model and other access control models that the EHR community wants to use. Because of the use of versioning in openEHR, a given EHR can start using one kind of Access control, and switch to a different model later on.
The actual implementation of this in a real system of course requires some security trickery, i.e. to prevent software or users bypassing the access control settings. It will require at least partial encryption of the data, based on keys that are provided to certain individuals or groups according to the access control list. >> 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? > well the roles won't match, and in a distributed environment, it could easily be the case that some users who access patient X's record at location B are not known as users at all at location A, where a copy of patient X's record exists as well. > >> 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. > many people have thought of schemes like this. The problem is not that they won't work, it's just that they won't work for patients or physicians. If EHR security is not a) comprehensible to both patients and carers and b) designed so that it is efficiently settable (i.e. without wasting much time during consultations) then it just won't be used. > > >> 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? > not really; the model should allow a patient to regard all health carers and users of her EHR as just belonging to the one 'health system'. If local models of access control are going to be used, it won't work for a distributed patient record. > > 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. > > or Artificial INtelligence ;-) See what I said above. - thomas beale
