# openEHR security **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2003-04-23 22:05 UTC **Views:** 8 **Replies:** 73 **URL:** https://discourse.openehr.org/t/openehr-security/15743 --- ## Post #1 by @Bill_Walton1 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 --- ## Post #2 by @Bill_Walton1 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 --- ## Post #3 by @Bernd_Blobel 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 > >     \*From:\* Sam Heard <mailto:sam.heard@bigpond.com> >     \*To:\* Bill Walton <mailto:bill.walton@jstats.com> ; >     openehr\-technical@openehr\.org <mailto:openehr-technical@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 > >         \*From:\* owner\-openehr\-technical@openehr\.org >         \[mailto:owner-openehr-technical@openehr.org]*On Behalf Of \*Bill >         Walton >         \*Sent:\* Thursday, 24 April 2003 7:36 AM >         \*To:\* openehr\-technical@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 Dear Bill, dear Sam Meanwhile, security constraint modelling succeeds\. This concerns policy modelling, policy negotiation, privilege management, access control, object security categorisation\. Unfortunately, the preparation of EU 6th Framework proposals was so time comsuming that I had no time to continue and to distribute the results\. The modelling is also part of the EU modEHRa proposal OIA \(Thomas and Sam\) will be involved in\. Best regards Bernd --- ## Post #4 by @Bill_Walton1 Bernd Blobel wrote: > Dear Bill, dear Sam > > Meanwhile, security constraint modelling succeeds\. This concerns policy > modelling, policy negotiation, privilege management, access control, > object security categorisation\. Unfortunately, the preparation of EU 6th > Framework proposals was so time comsuming that I had no time to continue > and to distribute the results\. The modelling is also part of the EU > modEHRa proposal OIA \(Thomas and Sam\) will be involved in\. Bernd, I'd not previously studied security constraint modeling but a quick Google put me onto some interesting research\. If you have any links to share, I'd appreciate it\. Thanks for the new \(to me\) tack\. Best regards, Bill --- ## Post #5 by @thomas.beale 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: --- ## Post #6 by @Sam Bill --- ## Post #7 by @Thomas_Clark 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 --- ## Post #8 by @Karsten_Hilbert \[\.\.\.\] > At all points NEED TO KNOW > governs access \[\.\.\.\] Except that the Need\-To\-Know paradigm doesn't work very well in healthcare\. The provider may not know what she needs to know at the time of the patient encounter\. The patient can't possibly correctly decide what her doctor must know in order to be able to make the right decisions \(of course, the patient is fully able to decide what she \*wants\* the doctor to know\)\. Etc\. Medicine is neither the military nor a secret service, literally \(it's not mass media either, on the other end of the spectrum\)\. Just a clinician's muttering \.\.\. Karsten --- ## Post #9 by @thomas.beale This is a very useful post \- I have thrown in some comments below \- mainly as a means of stimulating further discussions, not providing answers\. I hope that the security experts amongst us will be motivated to think seriously about solutions for openEHR\. Thomas Clark wrote: > 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\. > By "secure data store" \- I think you mean security mechanisms in the persistence infrastructure \- i\.e\. database level encryption, database\-level user authentication \(i\.e\. distinct from application or network secure login\) etc\. At one level, it seems to me that these things are organisational security issues in the sense that they are the same for all enterprise information reseources \- and we don't need to say anything special in the EHR specifications\. On the other hand, we are talking about distributed patient\-centred health information here, not employee emails\. Do we need a formal model of the virtual EHR \(i\.e\. distributed pieces of EHR\) in which security facilities are defined \(at least abstractly\) for persistence and exchange? I think we do\. Everyone has a lot of ideas about this, but I don't think we have seriously thought about defining a distributed EHR model on which we can hang security definitions \- we only \(so far\) try to define security "in\-the\-small"\. > 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\. > at this level do you see the physical EHR fragments \(i\.e\. piece of EHR at each physical location\) as being the "object" at which these systemic security features should be defined? > 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\. > I think we need to separate out the security needs which are specific to EHRs from those which would apply to any enterprise information\. One principle that we think needs to be observed is that clearly secure access to peoples EHRs will be violated, however infrequently; therefore access audit trails do need to exist so that the a\) the EHR subject can be notified that there was a breach; b\) the means of violation can be identified and fixed and c\) hopefully the violator can be identified and appropriate action taken\. We at least need to guarantee that a\) occurs \- this requires that all violations are knowable and known\. > 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\. > I don't believe there will be any problem with update within any given health care facility \- it will work in a very similar way to a configuration management \(CM\) system, in which \(in general\) there are multiple, competing, simultaneous modifiers\. These systems work like clockwork already in many enterprises\. The difference in health is \- of course \- security \- in a normal CM system, there are not differential security settings on the controlled items\. I would not claim to have worked out all the details, but I suggest that the basic idea is that the "checkout" operation of a piece of EHR by any user be where the security be applied \- the user role be compared to the access group definitions & sensitivy markers on the relevant EHR data and Access Control service setting; the checkout \(like a pure read\) either proceeds or not\. The biggest issue in my mind is the secure control of the information \_during the checkout period\_, and also post check\-out\. In a CM system, there is the concept of a "user workspace" which is where information is checked out into\. In EHR\-land, this needs to be a \_secure workspace\_ \- one which is a totally controlled part of the system\. The challenge is what to do with EHR information which needs to be checked out for a long time \(longer than a session\), made persistent in the workspace, etc etc\. I don't think this is insurmountable, but it does need to be part of the design\. > 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\. > so what is the abstract model for this \- is one possible \- and what do local implementors have to do? > 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\. > intersting idea \- this is essentially identifying a 'consent proxy', same as e\.g\. an intellectually impaired person would have to do \- only for most people it would presumably be time\-limited\. But a proxy does pose new challenges as well \- who is legally responsible for access violations by people the proxy allowed \(incorrectly to access the patient data? Does the proxy have the right to dynamically change the settings at any time? Is an appropriate legal metaphor the "power of attorney"? > Nationwide role\-based access may be good for Public Health personnel but > and anyway, that kind of access would probably be to de\-identified/anonymised data \- so it will be through a different mechanism\. > 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\. > Sure \- but is there any need for any standardisation of role definitions across a health system \- i\.e\. that the meaning of "registrar" be the same everywhere? I would have thought it very desirable since EHR information can easily be shared over a wide area due to patients moving, specialist care/testing etc etc\. > 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 > we have work to do\! \- thomas beale --- ## Post #10 by @system Hi, What is needed are several scenario's or use cases\. I think we need those for two situations at least: \- within an organisation \- between organisations And then we need to take into account variations in possible architectures\. ? With or without an Authorisation server ? The situation where information is polled from a system containing all possible information ? The situation where information is published from a system containing all information Without a series of accepted restrictions the problem will be intractable\. \(N persons, O Roles, P Participations, Q types of information, R exceptions and S Contexts\) Gerard > 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 >> >>     From: Sam Heard <mailto:sam.heard@bigpond.com> >>     To: Bill Walton <mailto:bill.walton@jstats.com> ; >>     openehr\-technical@openehr\.org <mailto:openehr-technical@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 >> >>         From: owner\-openehr\-technical@openehr\.org >>         \[mailto:owner-openehr-technical@openehr.org]On Behalf Of Bill >>         Walton >>         Sent: Thursday, 24 April 2003 7:36 AM >>         To: openehr\-technical@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 >> \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #11 by @Mike_Mair Dear Bill, I gave a paper on 'the immunological model of access' control at the HL7 CDA conference last year in Berlin\. It is to be found at http://www.hl7.de/cda2002/progoverz.html , the last paper\. The power point version does not load well from this site, and is found at my own web page at http://www.eyetech.co.nz/?page=ehr.inc \(but it takes a while to load\)\. Interestingly, a presentation from Finland at the same conference had almost the same idea, although the access control aspect was not quite the same\. The proposed mechanism, based on a concept from immunology, would also work for a simplified version of the Openehr architecture\. I think the model has the potential to facilitate a global ehr and access system\. Regards Mike Mair --- ## Post #12 by @Thomas_Clark Hi Karsten, NEED TO KNOW is a 'working label' that has a meaning dependent upon the particular circumstance\. A Healthcare Practitioner selected to perform foot surgery has a NEED TO KNOW pertinent information about the patient's feet, especially the one the surgery is to be performed on\. This would include any condition that could impact the surgery and recovery, e\.g\., abnormal blood pressure\. A brain specialist would likely not have a NEED TO KNOW nor an interest in result related to the foot surgery, except for those 'cross\-over' areas that could impact the surgery, e\.g\., abnormal blood pressure\. In both cases the 'potential impacts' had better be identified and handled\. Security systems are commonly compartmented, e\.g\., if a requestor needs to have access to information contained in a compartment then a NEED TO KNOW is established along with security policies and procedures\. The Patient may or may not be in a position to contribute re NEED TO KNOW\. Where they are they must be included, e\.g\., where a specific Healthcare Practitioner is to be excluded per a Patient's request\. Failure to honor such a request may become expensive\. Certain privacy requests should also be honored, e\.g\., Patient statements made in certain Healthcare environments \(e\.g\., labor and delivery\)\. Access to Patient, and related, records should be restricted where requested unless a superior demand is present, e\.g\., legal action\. Identification and clarification of a specific is generally needed before NEED TO KNOW can be determined for individuals\. One can say, however, that the Flower Lady does not have a NEED TO KNOW but the CHEMIST might\. One is no; the other is maybe \(conditional\)\. The Patient's family Physician has a NEED TO KNOW, the Public Health Administrator may be conditional, and the Physician that lives down the block has to build a case for having some NEED TO KNOW\. \-Thomas Clark --- ## Post #13 by @thomas.beale Thomas Clark wrote: > Hi Karsten, > > NEED TO KNOW is a 'working label' that has a meaning dependent upon the > particular circumstance\. A Healthcare Practitioner selected to perform foot > surgery has a NEED TO KNOW pertinent information about the patient's feet, > especially the one the surgery is to be performed on\. This would include any > condition that could impact the surgery and recovery, e\.g\., abnormal blood > pressure\. > would simply the term "relevance" be better than "need to know"? \- thomas beale --- ## Post #14 by @Karsten_Hilbert Thomas > NEED TO KNOW is a 'working label' \[\.\.\.\] I see\. That, of course, changes the situation\. I thought you were referring to the well\-established paradigm \(well, the only well\-established paradigm known to me as an ESL speaker\)\. Reason I thought so was that you capitalized the phrase\. Regards, Karsten Hilbert --- ## Post #15 by @Thomas_Clark A prior comment\. \-Thomas Clark --- ## Post #16 by @Thomas_Clark Hi Karsten, NEED TO KNOW is perhaps an unfortunate label that may have been coined by military security, a unique environment\. It seems to have taken root because participants in that organization structure rarely ask questions or engage in "pertinent" discussions or intellectual debates\. Such is not the case in Healthcare, however some label is required to discuss and explain filtering and blocking processes \(not suggesting either as a label\)\. NEED TO KNOW as a label does imply that a NEED has to be established prior to granting access\. A bridging label between the Healthcare and Security communities would be nice\. \-Thomas Clark --- ## Post #17 by @Bill_Walton1 Hi Sam, Sam Heard wrote: > > BW: First, and perhaps you consider this a seperate issue that's out of scope for Access Control, but what about Audit Trails? > SH: openEHR has full version control of all components so we have this thoroughly covered. If you are talking about auditing what is viewed, our research in the early 90s suggested that clinicians were totally against this - and it is very difficult to be sure what is seen unless refresh times, screen size and scrolling are all monitored - the idea is terrifying! I'm talking here about logging system activity at run-time, not version control. Also, I note that there seems to be concern about the phrase Audit Trails. I agree that it's way out of scope to try to log exactly what's seen. What's accessed (at the file or field level) is another question. I'll have more to say about this in another email in response to / support of Thomas Clark's comments. > > BW: 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?" > SH: We do believe that it is essential to log access - but not to what unless there is an over-ride on the constraints set by the patient. This could result in an automatic email to the patient in the future. But not policing what the clinician who has access looks at. Hmmm.... I'm guessing this may be a difference at the national level in how the medical delivery systems work. I'll have more to say about this in the email response anticipated by the above, but here are some of the new requirements we having to come to grips with here in the U.S.... Under HIPAA, the patient has the right to request an accounting of disclosures and the physician must furnish that accounting. Moreover, HIPAA requires that disclosures of protected health information, even to others within the physician's office, be kept to the minimum needed by the requestor to fulfill their job duties. In addition, the patient has a right to request that specific information be kept confidential. Along with the Privacy and Security standards, HIPAA contains enforcement provisions and the commentary has been very explicit that sanctions are an essential component of any security scheme. It appears to me that, here in the U.S., we have to anticipate maintaining a log of accesses to allow a reviewer to determine whether or not HIPAA's requirements have been adhered to. > > BW: 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, > SH: In openEHR this is versioned like anything else... Excellent. So past Access Control Lists are kept and could be reused? This will become important for us (in the U.S.) because the fact that a physician had access to a patient's full medical history in the past does not mean they continue to have that level of access. > > BW: and 2) a history of accesses to the EHR itself. > SH: I agree as long as we are talking access - that is logged - and over-rides and who authorised them and for what reason ( perhaps unconscious in Emergency is appropriate. Patients could set the over-ride capability to be turned off. More on this in other emails, but I think there's more to it than over-rides. > > BW: 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. > SH: True - it will only be able to be stored as an HTML rendition unless there is an extract in openEHR - but you are right - this could be saved - this is difficult to police. Oops! I'd assumed there would be extracts in openEHR. HIPAA specifies, under the Transaction Rules that go into effect in October of this year, a number of EDI transactions between systems that would require this. HTML will not be sufficient. > > BW: 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). > SH: The fact is, unlike usual systems, there will be more restraints on reads than writes. I'm taking this to mean that there will be configurable permissions on type of access. Yes? > SH: Research access will be via the kernel with an approved program unless it is one-to-one reading of records when the patient's consent is required anyway. Hmmm.... Again, perhaps a difference at the national level. Research here is the U.S. typically requires extracted data to be transferred from a physician's system to the research organization's system. > > BW: 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. > SH: As above More to come under seperate headings. Best regards, Bill --- ## Post #18 by @Bill_Walton1 Hi Thomas, Thomas Beale wrote: /snip/ > 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\. With all due respect, Thomas, it it's unrealistic then, IMO, it can't be correct\. \(Pragmatism R Us ;\-\) \) I'd like to offer food for thought\. The fundamental assumption at work here seems to be that care givers will access the same system, thus driving the need for all users of the system to be assigned roles that are defined congruently\. Let's consider an alternative model\. When I travel from the U\.S\. to the U\.K\., I \(the physical being\) move from one socio\-cultural\-legal model to another\. That does not change who / what I am, but it does change my behavior because I operate under a different set of norms and mores in the new environment\. I accept new forms of interaction and find that familiar forms are no longer available\. Why should it be any different for the information about me than it is for me? If we work from a perspective that posits that health information will move from system to system and be used / modified based on the rule sets in place within the various systems, does that make the problem more amenable to solution? > 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\. I thank Bernd for opening my eyes to what should have been obvious to me at a much earlier stage\. The security problem with EHR systems is fundamentally the same problem faced in OLAP databases\. Or perhaps I should say that it's the OLAP security problem with a twist\. At least OLAP databases are typically confined to one environment / business\. It's clear that the EHR problem is more difficult in that EHR's must, IMO, be capable of moving between environments\. Perhaps, by requiring a more generalized solution, the EHR problem will actually be easier to solve\. I don't know if you've checked out Mike Mair's paper but it implicitly poses a very interesting question\. "Is a biologically\-based security model fundamentally better aligned with the needs of an information system about biological entities than alternative models?" I'm hopeful the list will have some comments on Mike's paper\. I think the question is worth some thought / discussion\. /snip/ Best regards, Bill --- ## Post #19 by @Philippe_AMELINE1 Hi, I must confess I didn't read very carefully each message on this thread ; however, I think that I may contribute by explaining the direction we are currently following\. First I think we must distinguish between care coordination \(inside an openEHR node\) and continuity of care\. Continuity of care means that you manage to index every contributions for a single patient \(these contributions can be openEHR contributions or other systems contribution, or even data here and there\)\. The acces rules must be very different in both cases since : \- inside a node \(care coordination\) the system belongs to the team and/or the careplace \(say it is a domain, maybe a meta\-domain\) and see patients passing through \(from in to out\)\. \- a continuity of care system necesseraly belongs to the patient \(when you consider a wide period of time, it is the only stable user\) and see medical teams passing through\. To adress this change of point of view \(from a steady referential to a moving referential\), we are building a system with the following rules : \- the continuity of care system is an index of existing contributions and is granted access rights to the nodes \- inside the continuity of care system, people that may access data are given a position inside the patient "health team" : the position depends on the people "job" \(doctor, other health professional, family, social worker\) and depends on his "distance" from the patient \(usual care giver vs unusual one\)\. Hence the access rights to the contribution are determined for each possible position and depends on the current role inside the personal halth team at the very moment\. You can like the way we do it or not, however, I don't think you can make proper access rights if you don't adress the issue of steady referential \(care coordination \- or groupware\) vs moving referential \(continuity of care \- every episod of care for every care team\)\. Philippe --- ## Post #20 by @Mike_Mair Dear Bill,     ""Is a biologically\-based security model > fundamentally better aligned with the needs of an information system about > biological entities than alternative models?" The view we developed when working on the ISO/TC215 access proposal \(1\.\) was that ownership was itself a cultural concept, and one extreme of a spectrum of reciprocal relationships between rights and obligations\. Pure ownership is all rights and no obligations, which is scarcely achievable\. It would imply, for example, the right to destroy records, which would probably be denied even where the paradigm of individual autonomy reigns supreme\. We suggested that there was no interoperability without an access control mechanism being shared \(how can you interoperate if you can't access?\), which was why we went for an actual technique for access control, which developed into the CDA 'detachable headers' concept in the later paper to which you refer at the foot of this mail\. The crucial components of this idea are that: \- 'role for access' be part of a culture defined 'set' of roles, recognized within a jurisdiction, and that these role sets and their access rules change within and between jurisdictions\. \-There would be a basic 'unit' of healthcare information which we called the 'attestable unit'\. Later we learnt that the CDA was just such a unit \- That the header should contain 'role for access \(role needed to access that attestable unit\)\. \-The header should be stored separately from the body, and should act as a pointer to it when 'activated' by an appropriate search\. \- Later we found that the CDA already had 'sections' to which different access levels could apply\. The culture defined \(and dynamic\) role set within a jurisdiction could connect in to a finite set of options within a finite structure, the CDA\.\. The immunoglobin \(biological\) metaphor seems very apt \('Gaia immunology'\), The audit trails of access are built in to the concept, since the data stays put on the server, which also collects an audit trail of 'hits'\.\. but the device itself, the CDA and its bifunctional structure are shared\. Thanks again for your interest\. Regards Mike Mair   1\.\. 'Access to Electronic Health Records' NZ access proposal to ISO/TC 215 Current Work Item Proposals Available from: user name 'wg1' Password 'berlin '\. NB Section 3\.2 had different authoring and contains conclusions that are inconsistent with the other sections \(the work item is not current at this time\)\. http://www.health.nsw.gov.au/iasd/imcs/iso-215/areas/atehr2000.pdf Original Message \-\-\-\-\- --- ## Post #21 by @Bernd_Blobel Bill Walton wrote: > Hi Thomas, > > Thomas Beale wrote: > > /snip/ > >> 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\. > > With all due respect, Thomas, it it's unrealistic then, IMO, it can't be > correct\. \(Pragmatism R Us ;\-\) \) > > I'd like to offer food for thought\. The fundamental assumption at work here > seems to be that care givers will access the same system, thus driving the > need for all users of the system to be assigned roles that are defined > congruently\. Let's consider an alternative model\. > > When I travel from the U\.S\. to the U\.K\., I \(the physical being\) move from > one socio\-cultural\-legal model to another\. That does not change who / what > I am, but it does change my behavior because I operate under a different set > of norms and mores in the new environment\. I accept new forms of > interaction and find that familiar forms are no longer available\. > > Why should it be any different for the information about me than it is for > me? > > If we work from a perspective that posits that health information will move > from system to system and be used / modified based on the rule sets in place > within the various systems, does that make the problem more amenable to > solution? > >> 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\. > > I thank Bernd for opening my eyes to what should have been obvious to me at > a much earlier stage\. The security problem with EHR systems is > fundamentally the same problem faced in OLAP databases\. Or perhaps I should > say that it's the OLAP security problem with a twist\. At least OLAP > databases are typically confined to one environment / business\. It's clear > that the EHR problem is more difficult in that EHR's must, IMO, be capable > of moving between environments\. Perhaps, by requiring a more generalized > solution, the EHR problem will actually be easier to solve\. > > I don't know if you've checked out Mike Mair's paper but it implicitly poses > a very interesting question\. "Is a biologically\-based security model > fundamentally better aligned with the needs of an information system about > biological entities than alternative models?" I'm hopeful the list will > have some comments on Mike's paper\. I think the question is worth some > thought / discussion\. > > /snip/ > > Best regards, > Bill > > \- > If you have any questions about using this list, > please send a message to d\.lloyd@openehr\.org > Dear friends, A crucial challenge for EHR security is the formalisation of policies and their rule\-based but also interactive negotiation\. This reflects some of the issues mentioned\. Formal policy modelling is a CEN workitem over many years\. Meanwhile \(due to time constraints by other businesses also this project takes years\), the issues mentioned are also content of a common 3 part CEN and ISO standard on Privilege Management and Access Control Management\. Formal policy modelling and policy negotiation are essential aspect of the specification\. Kindest regards Bernd --- ## Post #22 by @Bernie_Cohen Most of the serious issues in EHR security are essentially ethical, not legal, in nature\. When the NHS first introduced a nationwide Healthcare Network, the BMA Ethics Committee advised all practitioners to put NO patient\-related data on it because it had not been PROVED that the network's security mechanims could guarantee non\-violation of the ethical principles governing access to such data \(see Anderson, R\. A\., Security in Clinical Information Systems, BMA, 1996\)\. Of course, such a proof cannot be performed, not only because the security mechanisms are not formally defined, but because the ethical principles themselves are not formally stated\. In an attempt to overcome this obvious impasse, I prepared a tentative formal definition of some of the dozen or so governing ethical principles stated in the BMA document\. Unfortunately, this met with a deafening silence from both sides of the argument\. I suspect that something of this nature is still needed and that the need for it cannot be admitted by any of the stakeholders\. The latest round of discussions of this group merely confirm that suspicion\. Those who are interested in this line of enquiry may care to read my seven\-year\-old paper at http://www.soi.city.ac.uk/~bernie/hsp.pdf --- ## Post #23 by @Paul_Juarez Philippe, The approach you have identified makes a lot of sense to me and goes a long ways toward clarifying "ownership" of the record. I do think it would be helpful to develop standard taxonomy for distinguishing the two: EMR signifying within a closed health care system, and EHR signifying the continuity of care record which is the property of the patient. It seems to me that if this distinction is not made, "ownership" is going to boil down to issues like "intellectual property." The way I see it, ownership and access are two, separate, albeit, overlappying issues. Did I hear somebody mention Napster? >>> Philippe AMELINE 04/29/03 12:54AM >>> Hi, I must confess I didn't read very carefully each message on this thread ; however, I think that I may contribute by explaining the direction we are currently following. First I think we must distinguish between care coordination (inside an openEHR node) and continuity of care. Continuity of care means that you manage to index every contributions for a single patient (these contributions can be openEHR contributions or other systems contribution, or even data here and there). The acces rules must be very different in both cases since : - inside a node (care coordination) the system belongs to the team and/or the careplace (say it is a domain, maybe a meta-domain) and see patients passing through (from in to out). - a continuity of care system necesseraly belongs to the patient (when you consider a wide period of time, it is the only stable user) and see medical teams passing through. To adress this change of point of view (from a steady referential to a moving referential), we are building a system with the following rules : - the continuity of care system is an index of existing contributions and is granted access rights to the nodes - inside the continuity of care system, people that may access data are given a position inside the patient "health team" : the position depends on the people "job" (doctor, other health professional, family, social worker) and depends on his "distance" from the patient (usual care giver vs unusual one). Hence the access rights to the contribution are determined for each possible position and depends on the current role inside the personal halth team at the very moment. You can like the way we do it or not, however, I don't think you can make proper access rights if you don't adress the issue of steady referential (care coordination - or groupware) vs moving referential (continuity of care - every episod of care for every care team). Philippe --- ## Post #24 by @Philippe_AMELINE1 Hi Paul, hi the list, Thanks for your post \- I thought nobody took the time to read mine ;o\) I tried to keep my post in the range of openEHR, however, since you are pushing me one step further, I need to tell that, from my point of view, continuity of care is probably a step to cross, but not the ultimate goal\. Once you agree that the patient is the owner of a system \(say the EHR in the taxonomy you are proposing\), you have to ask yourself : "when, why and by who shall this system get used ?"\. If you think that Electronic Health Record is the right concept for continuity of care, it is probably because you realized that Health doesn't mean "no disease", and that even people with chronic disease are most often managing their health than they are subject of care\. The conclusion we made is that if the system belongs to the patient, it must be a tool for the person \(and not only the patient\)\. So, this very tool must be a he "health capital" manager\. Since the system we are working on is problem oriented, and it allows to establish health objectives \- and not only records, we called it : Individual Health Project\. Now the taxinomy is richer, with three acronyms EMR, EHR and IHP ;o\) Philippe --- ## Post #25 by @Matt_Evans2 > \[\.\.\.\] >> At all points NEED TO KNOW >> governs access > > \[\.\.\.\] > > Except that the Need\-To\-Know paradigm doesn't work very well > in healthcare\. The provider may not know what she needs to > know at the time of the patient encounter\. The patient can't > possibly correctly decide what her doctor must know in order > to be able to make the right decisions \(of course, the patient > is fully able to decide what she \*wants\* the doctor to know\)\. > Etc\. > > Medicine is neither the military nor a secret service, literally > \(it's not mass media either, on the other end of the spectrum\)\. > > Just a clinician's muttering \.\.\. > > Karsten > \-\- Karsten, I agree and have concerns about being expected to take responsibility without access to all the facts\. I suppose this may not be an issue as I suspect that most people won't restrict the information in their file\. However, to fragment a medical file into bits I can and can't see is similar to taking the view that mind and body are separate entities\. If something is restricted, will I know there is something there that I can't see? Or will I be blisfully ignorant? How can I know if a piece of information is irrelevant unless I can see it to assess it? More mutterings\! Matt --- ## Post #26 by @Thomas_Clark Hi Matt, Fragmented records and securing individual and groups of records is a common approach\. It is very much like taking a 300 page document and building a security system that enables security: 1\)covering the entire document 2\)separate security covering chapters and 3\)separate security for tables, graphs and figures\. Access to the document is the first step; access to a specific chapter requires separate authentication; access to tables, etc can require separate authentication\. This focuses a specific reader's requests to those portions that are "relevant"/"germane"\. "one authentication" systems, e\.g\., password to your windows PC or Linux workstation are really ancient security systems\. There are typically more ways to break\-in than log\-in\. Recall than system and network managers are often the targets of security probes because they can access your raw data at will; that may include your sensitive data\. If you grant access to the entire EHR for a Patient to anyone successfully passing a "one authentication" gate you are likely to experience some real "pushback"\. Your obligation as a designer is to ensure that "relevance" and NEED TO KNOW are essential elements of the security system and that a successful authentication carries with it an assurance that the requestor is provided access to only "relevant"/"germane" information\. \-Thomas Clark --- ## Post #27 by @Andrew_Goodchild Hi Guys, You know I think it would be more productive to realize that the granularity of access control differs from enterprise to enterprise, from state to state and from culture to culture\. Trying to demand that openEHR support a specific level of granualrity \(e\.g\. transaction vs\. entry vs\. structured item\) is too hard as it will never please everybody\. If anything openEHR should be agnostic about such things and just say that there is a "security service" out there which gives users "priveleges" and these priveleges tell the EHR what kind of data a user can see\. In some enterprises such priveleges might give access to whole transactions and in others it suppress certain kinds of information\. The definition of how priveleges are interpreted should be totally up to the implementing organization\. In our case for an application we are building we use priveleges to allow users to see different "views" on transactions \(e\.g\. an administrators view vs\. a clinicians view vs\. a mental health care team member's view\) and the priveleges are assigned based on the user's role and patient consent\. However, I would not impose this scheme on anyone else unless it worked well with their local enterprise requirements and culture\. cheers, Andrew --- ## Post #28 by @system HI, What is the EHR OpenEHR is building? What is the scope? Is it a complete EHR system? Or is it that part of the EHR system that stores health data and that retrieves it? I think it is the latter\. The question of privacy to answer boils down to: What elements in the domain model for the EHR do we need \(need to store and transmit\) in order for an other part of the system perform the access control function? The second question is: Access control needs Audit trails; which information elements are necessary in the domain model for the audit trail function to work\. These two questions are not to difficult to answer\. In other words: the OpenEHR can assume that the Access Control function operates as if it is a fire wall that executes a set of rules and that the Audit trail is the log with violations \(Exceptions\) the fire wall had to grant\. The operation of the 'firewal' and audit trail are outside the scope of Open EHR\. Gerard > Hi Guys, > > You know I think it would be more productive to realize that the > granularity of access control differs from enterprise to enterprise, from > state to state and from culture to culture\. > > Trying to demand that openEHR support a specific level of granualrity > \(e\.g\. transaction vs\. entry vs\. structured item\) is too hard as it will > never please everybody\. If anything openEHR should be agnostic about such > things and just say that there is a "security service" out there which > gives users "priveleges" and these priveleges tell the EHR what kind of > data a user can see\. In some enterprises such priveleges might give access > to whole transactions and in others it suppress certain kinds of > information\. The definition of how priveleges are interpreted should be > totally up to the implementing organization\. > > In our case for an application we are building we use priveleges to allow > users to see different "views" on transactions \(e\.g\. an administrators > view vs\. a clinicians view vs\. a mental health care team member's view\) > and the priveleges are assigned based on the user's role and patient > consent\. However, I would not impose this scheme on anyone else unless it > worked well with their local enterprise requirements and culture\. > > cheers, Andrew > >> Hi Matt, >> >> Fragmented records and securing individual and groups of records is a common >> approach\. It is very much like taking a 300 page document and building a >> security system that enables security: >> 1\)covering the entire document >> 2\)separate security covering chapters and >> 3\)separate security for tables, graphs and figures\. >> >> Access to the document is the first step; access to a specific chapter >> requires separate authentication; access to tables, etc can require separate >> authentication\. This focuses a specific reader's requests to those portions >> that are "relevant"/"germane"\. >> >> "one authentication" systems, e\.g\., password to your windows PC or Linux >> workstation are really ancient security systems\. There are typically more >> ways to break\-in than log\-in\. >> >> Recall than system and network managers are often the targets of security >> probes because they can access your raw data at will; that may include your >> sensitive data\. If you grant access to the entire EHR for a Patient to >> anyone successfully passing a "one authentication" gate you are likely to >> experience some real "pushback"\. Your obligation as a designer is to ensure >> that "relevance" and NEED TO KNOW are essential elements of the security >> system and that a successful authentication carries with it an assurance >> that the requestor is provided access to only "relevant"/"germane" >> information\. >> >> \-Thomas Clark >> >> From: "Matt Evans" <mge@totalise\.co\.uk> >> To: <openehr\-technical@openehr\.org> >> Sent: Thursday, May 01, 2003 2:30 PM >> Subject: FW: openEHR security; Directed to Thomas Beale >> >>>> \[\.\.\.\] >>>>> At all points NEED TO KNOW >>>>> governs access >>>> >>>> \[\.\.\.\] >>>> >>>> Except that the Need\-To\-Know paradigm doesn't work very well >>>> in healthcare\. The provider may not know what she needs to >>>> know at the time of the patient encounter\. The patient can't >>>> possibly correctly decide what her doctor must know in order >>>> to be able to make the right decisions \(of course, the patient >>>> is fully able to decide what she \*wants\* the doctor to know\)\. >>>> Etc\. >>>> >>>> Medicine is neither the military nor a secret service, literally >>>> \(it's not mass media either, on the other end of the spectrum\)\. >>>> >>>> Just a clinician's muttering \.\.\. >>>> >>>> Karsten >>>> \-\- >>> >>> Karsten, >>> >>> I agree and have concerns about being expected to take responsibility >>> without access to all the facts\. >>> >>> I suppose this may not be an issue as I suspect that most people won't >>> restrict the information in their file\. >>> >>> However, to fragment a medical file into bits I can and can't see is >> >> similar >>> to taking the view that mind and body are separate entities\. >>> >>> If something is restricted, will I know there is something there that I >>> can't see? Or will I be blisfully ignorant? How can I know if a piece of >>> information is irrelevant unless I can see it to assess it? >>> >>> More mutterings\! >>> >>> Matt >>> >>> \- >>> If you have any questions about using this list, >>> please send a message to d\.lloyd@openehr\.org >> >> \- >> If you have any questions about using this list, >> please send a message to d\.lloyd@openehr\.org >> > \_\-\_|\\ Andrew Goodchild > / \* DSTC Pty Ltd > \\\_\.\-\.\_/ Brisbane, Australia >     v http://staff.dstc.edu.au/andrewg/ > > \- > If you have any questions about using this list, > please send a message to d\.lloyd@openehr\.org \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #29 by @Bill_Walton1 Hi Gerard, Gerard Freriks wrote: /snip/ > In other words: the OpenEHR can assume that the Access Control function > operates as if it is a fire wall that executes a set of rules > and that the > Audit trail is the log with violations \(Exceptions\) the fire wall had to > grant\. > > The operation of the 'firewal' and audit trail are outside the scope of Open > EHR\. While I support the concept of seperating the access control functionality from the storage / retrieval functionality, I'm afraid I have to disagree, with all due respect, to the segregation of the audit trail and to what I understand your definition of what needs to be contained in the audit trail\. The notion that the audit trail only log exceptions will be a non\-starter here in the U\.S\., I think\. The "appropriateness" of an access to a record can only be determined ex post facto in many cases\. An example may help\. Suppose a nurse prints a copy of one of her patient's records during her shift\. Is this appropriate access? On it's face, at the time of access, it would appear so\. Suppose further, though, that the nurse later sells that copy to a third party who uses it to the patient's disadvantage\. Now it's clear that the access was for inappropriate purposes\. No system can pre\-judge intent\. If the access is not logged, there will be no trail to the event that led to the inappropriate disclosure and the system will have contributed to the patient's disadvantage\. Further, unless the list of accesses is maintained as part of the EHR, there's no guarantee that the patient will have access to that information\. Thus, I believe the audit trail functionality must be "in scope" for openEHR, at least to the extent that the group intends it to be viable here in the U\.S\.\. Best regards, Bill --- ## Post #30 by @system I understand your remarks\. But\. The following information must be added to get a fuller picture of how I envisage things: \-0\- The context for my remarks is the discourse, using human and computer processable documents, between health professionals over time and space\. My context is not updating databases using messages\. \-1\- Electronic systems must provide at least the same quality in all aspects when compared with paper based systems\. The quality can be better but never less\. \-2\- Of course persons entering the system are logged \-3\- And only information is readily available to which one has rightful access because one is working in the same department the patient is in\. All access to the information will not be logged in the audit trail\. \(paper based systems don't record where the eyes hit the paper and ink\) I assume a high degree of social control in a department\. \-4\- Audit trails in the sense that is recorded why, what, when, from where, by whom has used the exception path to reach information are needed when the requestor is overruling the access controls\. \-5\- the preferred way of obtaining information must stay \(as it always was\) direct contact between health professionals either orally or by writing\. My fear is that because anything can be recorded and tracked or traced we feel obliged to do so in the electronic domain\. Example: The Data Registrars Office in the Netherlands is of the opinion that access to electronic medical records can be granted only by using two ways authentication \(password AND biometrics\) The only justification is that it is possible\. But it is unaffordable and to complex to organise in the healthcare domain\) \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #31 by @thomas.beale Bill Walton wrote: > > > BW: 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\. > > SH: True \- it will only be able to be stored as an HTML rendition unless there is an extract in openEHR \- but you are right \- this could be saved \- this is difficult to police\. > Oops\! I'd assumed there would be extracts in openEHR\. HIPAA specifies, under the Transaction Rules that go into effect in October of this year, a number of EDI transactions between systems that would require this\. HTML will not be sufficient\. Can anyone clarify this bit of the debate \- I have lost track of what is being said here\! > I'm taking this to mean that there will be configurable permissions on type of access\. Yes? yes \- probably quite sophisticated ones\. > > SH: Research access will be via the kernel with an approved program unless it is one\-to\-one reading of records when the patient's consent is required anyway\. > Hmmm\.\.\.\. Again, perhaps a difference at the national level\. Research here is the U\.S\. typically requires extracted data to be transferred from a physician's system to the research organization's system\. both scenarios are equally ok\. I would also have expected the one Bill mentions to be more likely \- especially as data transformation and anonymisatino are often needed\. \- thomas beale --- ## Post #32 by @thomas.beale Bill Walton wrote: >Hi Thomas, > >Thomas Beale wrote: > >>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\. >> > >With all due respect, Thomas, it it's unrealistic then, IMO, it can't be >correct\. \(Pragmatism R Us ;\-\) \) > >I'd like to offer food for thought\. The fundamental assumption at work here >seems to be that care givers will access the same system, thus driving the >need for all users of the system to be assigned roles that are defined >congruently\. Let's consider an alternative model\. > when I wrote "health system" above, I meant the whole health delivery system in a country or region, not literally an information system\. > >When I travel from the U\.S\. to the U\.K\., I \(the physical being\) move from >one socio\-cultural\-legal model to another\. That does not change who / what >I am, but it does change my behavior because I operate under a different set >of norms and mores in the new environment\. I accept new forms of >interaction and find that familiar forms are no longer available\. > >Why should it be any different for the information about me than it is for >me? > exactly right\. So many aspects of security, care process, what archetypes are used etc will change\. >If we work from a perspective that posits that health information will move >from system to system and be used / modified based on the rule sets in place >within the various systems, does that make the problem more amenable to >solution? > I think this is our base assumption\. All I wanted to say above is that access control rules somehow have to deal with the varying definitions of same\-named roles across widely differing jurisdictions\. I like Mike's paper too, I need to give it more thought\. \- thomas --- ## Post #33 by @thomas.beale Bill Walton wrote: > > > > BW: 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\. > > > SH: True \- it will only be able to be stored as an HTML rendition > unless there is an extract in openEHR \- but you are right \- this could > be saved \- this is difficult to police\. > > Oops\! I'd assumed there would be extracts in openEHR\. HIPAA > specifies, under the Transaction Rules that go into effect in October > of this year, a number of EDI transactions between systems that would > require this\. HTML will not be sufficient\. Can anyone clarify this bit of the debate \- I have lost track of what is being said here\! > > I'm taking this to mean that there will be configurable permissions on > type of access\. Yes? yes \- probably quite sophisticated ones\. > > SH: Research access will be via the kernel with an approved program > unless it is one\-to\-one reading of records when the patient's consent > is required anyway\. > > Hmmm\.\.\.\. Again, perhaps a difference at the national level\. Research > here is the U\.S\. typically requires extracted data to be > transferred from a physician's system to the research organization's > system\. both scenarios are equally ok\. I would also have expected the one Bill mentions to be more likely \- especially as data transformation and anonymisatino are often needed\. \- thomas beale --- ## Post #34 by @lakewood Hi Gerard, Good list of requirements\. My question concerns contact between Healthcare Practitioners and others which may include geographically remote locations and roving, e\.g\., in\-hospital via wearable or hand\-held units\. This contact would extend beyond that of the Practitioner\-Patient\. A good example would be Remote Surgery with requirements that amount to secure, continuous audio/visual connections\. Another would be my clinic where they have migrated to computer systems within the exam room and at other points of contact\. If a process, procedure, technology is already in use would it be integrated within the OpenEHR scope, requirements, goals and implementation? Judging from the difficulty getting something implemented it would seem that somewhere, sometime someone was able to justify the project and get it implemented\. \-Thomas Clark --- ## Post #35 by @Bill_Walton1 Hi Thomas, Thomas Beale wrote: > > Bill Walton wrote: > > > > > > BW: 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\. > > > > > SH: True \- it will only be able to be stored as an HTML rendition > > unless there is an extract in openEHR \- but you are right \- this could > > be saved \- this is difficult to police\. > > > > Oops\! I'd assumed there would be extracts in openEHR\. HIPAA > > specifies, under the Transaction Rules that go into effect in October > > of this year, a number of EDI transactions between systems that would > > require this\. HTML will not be sufficient\. > > Can anyone clarify this bit of the debate \- I have lost track of what is > being said here\! I was inquiring about the audit trail capabilities intended to be incorporated in v1\.0 of openEHR and Sam was very graciously trying to enlighten me\. His commment re: HTML made me expand the question to extracts\. I'm not sure I was sufficiently clear about my line of questioning, and comments by others make me wonder whether or not I should take this off\-line\. I am specifically trying to ascertain the applicability of openEHR to the emerging requirements here in the U\.S\. and do not wish to infringe on the group's bandwidth if there is a less intrusive way to handle my questions\. Please let me know how you'd like me to proceed\. And thank you all for your patience to date\. Best regards, Bill --- ## Post #36 by @Thomas_Clark Hi Bill\. The following link might be appropriate for ftp\-based messaging solutions: http://www.linuxmednews.com/linuxmednews/1046134538/index_html TITLE: "\.\.\. and open\-source Electronic Data Interchange" NOTES: \-"\.\.\. SolAce Server was designed to do reliable, secure messaging in compliance with the HIPAA Security Rule \.\.\." \-written in Java \-Thomas Clark --- ## Post #37 by @Alby_Creevey There a many other products that will provide the same sort of Secure Message Delivery as well\. \(HIPPA ain't an insignificant piece of work,,, but hey,, they might not have it right\.\.\.\.\) Guys,,,Don't get bogged down in the technical detail,, define the business process and rules first,, and the rest will follow\. --- ## Post #38 by @Matt_Evans2 Hi Thomas, I forgot I had set up an inbox rule for posts from this forum so have probably missed the last 40 or more posts\. Will have to go back through them all to see exactly what has been covered\. Thank you for your useful description\. I had meant to put my case as a clinican but as this is the 'technical' forum I don't know if it was the right place\. I agree that the described approach makes sense and offers a great deal of customsation regarding access\. What I am concerned about, I suppose, is how the system will be implemented\. These concerns stem from some examples I have heard \- for instance an orthopaedic surgeon only requiring information to perform an operation\. Perhaps this is an inaccurate example? My viewpoint is that I spend up to an hour when assessing a patient carefully extracting as much information as possible\. My colleagues rely on the thoroughness of this information to look after this patient\. We also rely on full access to the entire medical record \(ever recorded\) in order to safely and holistically care for our patients\. I would hope I would have full access to the medical record in order to fulfill my clinical responsibilities\. In my field, it is not unusual for patients to either provide unreliable details or to conceal facts\. We often rely on recorded facts rather than what we are told\. In these circumstances I have concerns about the patient's right to keep private parts of their records\. I believe that the suggestion that a patient may essentially exclude sections of their notes from viewing represents a major shift in the way we work\. I would also argue that it's difficult for a patient to know when this concealment may put themself or others at risk\. Is the intended approach that the viewer would know there was information that they could not view or that it is simply hidden? Matt --- ## Post #39 by @Bill_Walton1 Hi Thomas, Thanks for the link\. I've enjoyed your posts\. Best regards, Bill "Thomas Beale" <thomas@deepthought\.com\.au> Bill Walton > Hi Bill\. > > The following link might be appropriate for ftp\-based messaging solutions: > > http://www.linuxmednews.com/linuxmednews/1046134538/index_html > > TITLE: "\.\.\. and open\-source Electronic Data Interchange" > > NOTES: > \-"\.\.\. SolAce Server was designed to do reliable, secure messaging in > compliance with the HIPAA Security Rule \.\.\." > > \-written in Java > > \-Thomas Clark > > From: "Bill Walton" <bill\.walton@jstats\.com> > To: <openehr\-technical@openehr\.org>; "Thomas Beale" > <thomas@deepthought\.com\.au> > Sent: Sunday, May 04, 2003 8:14 PM > Subject: Re: Access controls and Audit trails \(was Re: openEHR security\) > > > Hi Thomas, > > > > Thomas Beale wrote: > > > > > > Bill Walton wrote: > > > > > > > > > > BW: 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\. > > > > > > > > > SH: True \- it will only be able to be stored as an HTML rendition > > > > unless there is an extract in openEHR \- but you are right \- this could > > > > be saved \- this is difficult to police\. > > > > > > > > Oops\! I'd assumed there would be extracts in openEHR\. HIPAA > > > > specifies, under the Transaction Rules that go into effect in October > > > > of this year, a number of EDI transactions between systems that would > > > > require this\. HTML will not be sufficient\. > > > > > > Can anyone clarify this bit of the debate \- I have lost track of what is > > > being said here\! > > > > I was inquiring about the audit trail capabilities intended to be > > incorporated in v1\.0 of openEHR and Sam was very graciously trying to > > enlighten me\. His commment re: HTML made me expand the question to > > extracts\. I'm not sure I was sufficiently clear about my line of > > questioning, and comments by others make me wonder whether or not I should > > take this off\-line\. I am specifically trying to ascertain the > applicability > > of openEHR to the emerging requirements here in the U\.S\. and do not wish > to > > infringe on the group's bandwidth if there is a less intrusive way to > handle > > my questions\. Please let me know how you'd like me to proceed\. And thank --- ## Post #40 by @Bill_Walton1 Hi Alby, Alby Creevey wrote: > There a many other products that will provide the same sort of Secure > Message Delivery as well\. \(HIPPA ain't an insignificant piece of work,,, but > hey,, they might not have it right\.\.\.\.\) I'll be checking into it\. The test phase for HIPAA compliance re: the Transaction Rules has just started and should yield some publicly available information in short order\. > Guys,,,Don't get bogged down in the technical detail, define the business > process and rules first,, and the rest will follow\. HHS \(Dept\.of Health and Human Services of the U\.S\. Food and Drug Administration\) has, through the promulgation of the HIPAA Privacy Rule \(compliance date of 4/14/03\), Transaction Rule \(compliance date of 10/16/03\), and Security Rule \(compliance date of 4/20/05\) defined a new set of business rules for Health care providers, plans, and clearinghouses here in the U\.S\.\. The new rules are seen by practioners as introducing new costs and risks in a business that's already under attack on many fronts\. If automation emerges that can help them reduce the costs and risks, the likelihood is that they'll adopt it quickly\. This is being viewed as an important opportunity by EHR vendors, one that could see the rapid and widespread adoption of EHR systems\. IMO, it's an even larger opportunity for the open source community given the financial pressures the provider community are already under\. So now it's time to see if we're up to the task\. Best regards, Bill --- ## Post #41 by @lakewood Hi Matt, Comments in text\. --- ## Post #42 by @Karsten_Hilbert Uhm, > Faced with handling a potential > SARS Patient worrying about retrieving precise, accurate information from > them about non\-SARS history might be wasted effort and highly frustrating, \[\.\.\.\] > Presuming that the Patient just arrived from the recesses of China an > initial effort might be an attempt to:   ^^^^^^^ > > 1\)determine if that recess has an EHR/EPR/EMR based system that can > be accessed, assuming that your site supports OpenEHR\. \[\.\.\.\] > 11\)attempt to update the recess\-local EHR/EPR/EMR database > 12\)continue OpenEHR record processing and update \(local and recess\-local\) You surely got to be kidding me ? How about getting the patient to an appropriately equipped/staffed hospital ? I do see your technical point, though\. Karsten --- ## Post #43 by @Thomas_Clark Hi Karsten, A SARS Patient example was chosen because initial screening detects people with elevated temperatures, e\.g\., airport screening\. Once detected early access to records should be facilitated\. Information contained in these records is likely to be more extensive, accurate and precise than information from a Patient who is suffering an attack\. Reminds me of my car accident two years ago in which I received an obvious bump on the head \(swollen\)\. The Emergency Room nurse retrieved my name and address and then asked if I was in pain\. Being Irish is a detriment at times, but I managed to respond that I was indeed in a lot of pain, was unable to stand, could not drive a car, and a prior neck injury was causing considerable distress, all of which was already on the record \(same hospital and ambulance technician record\)\. Having experienced the flu on prior occasions I can confidently say that things I say during this time period I will neither remember nor understand why I said them\. Including these statements in the record probably is not a good idea nor is basing a diagnosis, other that 'He is out\-of\-it', on this information\. The presumption that a Patient is 100% lucent in a stressful situation is subject to debate, e\.g\., accidents, flu, labor and delivery\. Retrieve the information from the Patient; analyze it; compare it with the record, if available, but give it a proper weighing\. Don't forget the symptoms and the reasons the Patient ended up in the facility\. It is an information retrieval/analysis/credibility/reliability problem\. The information needs to be sorted\. Getting the Patient to an appropriately staffed hospital/clinic is a response to the above\. Such a response should not be based solely on information retrieved from the Patient, e\.g\., they may still want to attend that meeting\. \-Thomas Clark --- ## Post #44 by @Tim_Churches Cross\-posted from the openehr\-technical list: > The presumption that a Patient is 100% lucent in a stressful situation is > subject to debate, e\.g\., accidents, flu, labor and delivery\. > > Retrieve the information from the Patient; analyze it; compare it with the > record, if available, but give it a proper weighing\. Don't forget the > symptoms and the reasons the Patient ended up in the facility\. > > It is an information retrieval/analysis/credibility/reliability problem\. The > information needs to be sorted\. About a year ago a friend of mine suffered a myocardial infarct at the unexpectedly early age of 53\. Thanks to very swift thrombolysis, he survived with virtually no ill effects\. However, during his stay in hospital, he was amazed that he was asked the same basic set of questions over and over again by different people, despite them having his clinical record in front of them, with that information neatly recorded there by an intern\. He found that surprising\. When he related this to me, I expressed no surprise at all \- one of the first things you learn as an intern working in a hospital is that you should never trust the accuracy or completeness of someone else's entry in a medical record\. So wherever possible, you always check the facts\. Later, doing general practice locums, the wisdom of that view was confirmed\. But I learnt to rely on records made by colleagues whom I knew and trusted\. Now, this is, I suspect, a rather common attitude, and is something which seems to have been rather glossed over in all the discussions and studies of the benefits of an EHR\. There's no doubt that, eventually, medical culture would change sufficiently to trust what is in an EHR, but how long would that take? Has anyone systematically investigated this question? --- ## Post #45 by @lakewood Hi Tim, Never trusting the record is in itself justification for OpenEHR and interfacing it with all other EHR/EPR/EMR systems\. I do not 100% trust the contents of the records supported by the EHR/EPR/EMR systems\. The basic rationale is that the information is generated by related devices and human beings, e\.g\., the process of communication between humans is not without difficulties\. What these record systems do is generate and maintain accurate and precise records of what someone has reduced to an electronic format\. One could employ software applications that would attempt to make sense out of it and perhaps provide a more "relevant"/"germane" interpretation, but the record remains\. I can understand that Practitioners suspect the record\. Mine involves multiple Practitioners in multiple Healthcare organizations \(I have moved some\)\. They do not speak the same 'language', which is probably why the Patients are subjected to multiple identical tests for no obvious reason\. The record systems will not improve the "correctness" of the content\. A bad diagnosis remains just that\. The record system will make it available quickly and reliably\. Another software application may put together some of the pieces so that an improvement is possible, but then a Practitioner would probably have to design that as well\. Not trusting the content of the records is a Practitioner problem\. Electronic records are likely to remove most of the problem areas in existing systems, e\.g\., the copy machine ate that page\. A group of monkeys locked in a room with a number of computers taking record\-based inputs may create actual records but neither of us could really understand or use the data\. This comes from the same scenario applied to music\. Bach would have no competition\. I have one hope for the Patient's sake; the Practitioners should at least rotate the questions\. \-Thomas Clark --- ## Post #46 by @Tim_Churches \-\-\-snip\-\-\- > Not trusting the content of the records is a Practitioner problem\. \-\-\-snip\-\-\- Indeed, although in their defence, almost every Practitioner will have anecdotal evidence justifying their lack of faith in the record\. My question was, has anyone considered this issue in detail? How pervasive is the level of distrust, how variable is it with respect to system and data source, what will it take to change these attitudes? I suspect that information about quantitative test and investigation results contained in an EMR/EHR are probably quite well trusted \(hopefully justifiably\), but "softer", more qualitative information less so eg does the patient have any medication allergies? There is plenty of room for doubt and variable interpretaion regardless of whether that question is answered in the positive or the negative\. Of course, these are broad sociological questions, and these are the wrong forums in which to ask such questions\. I was just curious to know if anyone was aware of any specific research being undertaken to address these questions? yes, I am about to do a PubMed search now\.\.\. Tim C --- ## Post #47 by @lakewood Hi Tim, Do not have a link handy but I do recall that the EMR discussions in the NHS introduced this and discussed it at length\. Structuring data entry format went a long way toward improving it\. I'll see if I can come up with a link\. \-Thomas Clark --- ## Post #48 by @Karsten_Hilbert Thomas, apologies for I at times respond a bit too rashly :\-\) I was not trying to advocate to just base decisions on what the patient tells me\. I was just struck by the example: patient with elevated temperature, coughing and slight difficulty breathing \(generally feeling unwell\) just having arrived from a known SARS area\. My response was simply based on those facts and the only sane \(clinical\) response is to get the patient to the next infectious diseases ward relatively quickly for further assessment\. This is, of course, coloured by my working in a clinic, not a hospital department\. However, it would certainly be very wonderful to be able to access OpenEHR\(\)ed records from the backwaters of China but I wonder if I'll live to see that happen \(I'm 28\)\. So, yes, electronically available pre\-recorded information is very helpful and OpenEHR is immensely useful at any of those parts of dealing with the above patient\. > obvious bump on the head \(swollen\)\. The Emergency Room nurse > retrieved my name and address and then asked if I was in pain\. Being > Irish is a detriment at times, but I managed to respond that I was indeed > in a lot of pain, was unable to stand, could not drive a car, and a prior > neck injury was causing considerable distress, all of which was already > on the record \(same hospital and ambulance technician record\)\. Your current assessment of a situation is just as valuable as what is recorded somewhere\. I routinely do ask patients for about the same information \(or more specifically their current assessment of said information\) that they have provided previously\. It does help to establish a clinical path beforehand such as "We will attend to alleviating your current discomfort right away but I must re\-assess some information because some of the further treatment may alter your perception of it\." I have generally found patients very responsive to that explanation\. It takes about 2 seconds\. Karsten --- ## Post #49 by @Patrick_Lefebvre Hi everyone, As Thomas & al\. pointed, security addresses "a number of aspects", including security policy \(defining who does what\), data safety, and how security is ensured: so, including safety of the network, the application architecture \-including management of messages: asynchronous/EHRcom/XML, or synchronous/CorbaMed/IDL\-, the programs, and the platform\. Great\. I agree with Gerard Freriks's considerations \(legal, social control and organisational aspects\) but for now I only focus on the technical specification\. For now, I will focus on far restricted objectives\. One of EHRcom's startpoints is ENV 13606\-1999, and we all want to ensure ascending compatibility\. ENV13606 messages \(part 3 : "distribution rules"\) describe access policy in terms of objects \("Who", "When", "Where",etc\.\) whose instanciations define the allowed access context to message objects\. So, in the viewpoint of EHRcom release 1 in 2004, \* Will this \(or such an\) architecture be reused in EHRcom ? \* If no, will we have a tool to convert distribution rules into corresponding archetypes ? \* If no, how is it planned to ensure ascending compatibility ? Another basic, technical, concrete security point is: ensuring data \(transmission \+ authoring\) integrity in the message\. One solution proposed by ENV13606 was: systematic digital signature of each transaction\. Will EHRcom reuse this mechanism ? One last point is: our deadline for a \(definitive ? initial ?\) specification\. In EHRcom specs, what can we define for now as a stable 2004 milestone ? Maybe my questions are FAQs\. Thank you for your kind replies\. \-\- Patrick Lefebvre --- ## Post #50 by @Wayne_Wilson Tim Churches wrote: > \-\-\-snip\-\-\- > >> Not trusting the content of the records is a Practitioner problem\. >>    > > \-\-\-snip\-\-\- Indeed, although in their defence, almost every Practitioner will have anecdotal evidence justifying their lack of faith in the record\. My question was, has anyone considered this issue in detail? > Well, I only have anecdotal evidence as well \(isn't that just the case with most IT \!\)\. It comes from design work on a record retrieval system which collected all available electronic records into a single web display format\. This was in a large hospital setting\. The physicians were primarily interested in the most recent set of information, largely test results and expert analysis\. So we came to the conclusion that there were actually two sorts of records: formal or official medical record\. clincial care/treatment record\.   Now one would think that these two would be one and the same, but they actually serve quite different purposes as near as I can see\. One is used for all sorts of business purposes such as billing, legal, regulatory, etc\. The other is used for just one purpose, clinical care of the current episode\. So lack of faith may be just one of the reasons that history is retaken, there may be others\. --- ## Post #51 by @Thomas_Clark Hi Karsten, Thanks for the response\. Comments in text\. \-Thomas Clark --- ## Post #52 by @Karsten_Hilbert Thomas > Unless you are planning on an early retirement, etc\., it is feasible in > the short term\. It is an easy sell; try Canada\. Having been to remote areas of Thailand, Vietnam, India, Egypt and China myself \(as a traveller, however, not a health professional\) let me assure you that it may be an easy sell in Canada but not necessarily so in other regions\. > asking a Patient with a history of pain if they > are in pain has to be different from one that just started\. Surely, but it makes a lot of sense to ask the patient if the pain has worsened/bettered/shifted in location or type\. Or if other symptoms have become apparent since the first assessment\. > Patient expectations are reasonable, usually\. They expect some action > soon, and it should be proper and timely\. The difference between "soon" and "timely" often makes all the difference in perception of adequate immediate care between provider and patient\. Karsten --- ## Post #53 by @Thomas_Clark Hi Patrick, Good questions\! I have been looking at the issues at the record level: 1\)archival \(personal, facility, Secure Data Store; no direct government involvement\) 2\)who serves the records \(e\.g\., can't keep going to the archive\) 3\)record updates at the server 4\)EDI for the records 5\)Translation for the records \(temporary vs permanent foreign format\) 6\)Interfacing with Insurance organizations \(priority databases\) 7\)maintaining records at the Healthcare facility \(temporary vs permanent; single vs multiple record formats; caching records; facility records that incorporate non\-healthcare data; privacy, security\) 8\)inter\-facility, record\-based communications, e\.g\., conferencing, remote and roving participation 9\)replication and modification 10\)summary record formats, e\.g\., for the Patient and facilitators \(e\.g\., administrators\) Lots of development issues embedded here, both record implementation and information\. Moving content between record systems and retrieving, re\-formatting and transmitting information are the two main areas\. Possible solutions/directions: 1\)a 'carrier' system for Healthcare records, e\.g\., a 'wrapper' for Healthcare records that is capable of many formats and essentially passes the buck to the recipient system \(FibreChannel transmission; frame\-based communications\) 2\)multiply\-formatted information \(redundant\), e\.g\., identical information stored in multiple, dissimilar records \(different formats; each potentially serving different areas, legal systems, etc\) 3\)yet another Healthcare record format My suspicion is that facilities will be dealing with multiple record formats for a rather long time\. Deployed software uses foreign record formats and is unlikely to change when an OpenEHR format/protocol is announced\. My suggestion is to direct efforts at developing a format/protocol that interfaces to most of the existing formats and grows from there\. Would be nice to form a close relationship with device vendors on this\. The bottom line is that deployment requires something close to transparency, i\.e\., a facility should be able to ignore the fact that there are devices and systems working together that support different record formats\. \-Thomas Clark --- ## Post #54 by @Thomas_Clark Hi Karsten, Comments in text\. \-Thomas Clark --- ## Post #55 by @Karsten_Hilbert Hi Thomas, > Constructive\! Do you anticipate entering this type status information > into an OpenEHR record? Absolutely \! I do record such information even today\. > If so, what record? I do so now in the narrative part of the record, at times linked to previous data by plain and simple layout of data items\. Karsten --- ## Post #56 by @Thomas_Clark Hi Karsten, This is important since 'linked' messages, e\.g\., XML database, can be used to handle both status messages from a single Practitioner and multiple Practitioners\. The real problem is to decide/filter what gets in the permanent record\. This can have legal impacts in the local jurisdiction\. For example, charting is performed but most cases at some later time \(an issue since memory recall is suspect\) and is typically a paper record Some facilities are attempting to automate this as well as other practices\. What to do with this information for many remains an unsolved puzzle\. Narratives can be hard to handle in record\-based systems as can scannable entries, e\.g\., charts and images\. What you do is important and should/must be saved\. A possible approach is a collection of databases handling specific information with posting in a EHR/EPR/EMR, both surviving as permanent data\. This puts a focus on record format/structure, i\.e\., there are limitations imposed by implementation, jurisdiction, users, performance, networking, etc\. Small block sizes is desirable; records can be composed of multiple blocks; narratives from multiple Practitioners might be hard to handle\. Interesting problem\! \-Thomas Clark --- ## Post #57 by @Karsten_Hilbert Thomas, maybe I'm too dense but I cannot appreciate the complexity of the issue as you hash it out\. To me this is simply: 3\.5\.2003 10:35 am first seen patient medium pain frontal skull after contusion in traffic accident 5 mins ago, no neurological abnormalities right now, GCS 15 3\.5\.2003 10:45 check up pain on pressure to 2nd cervical vertebra, dizziness, nausea, claims fuzzy vision, left pupil dilated responding to light slower than right, now severe pain frontal/retroorbital/ right temporal region\. GCS 12\. Clearly, there's some new and some updated information in this narrative\. This is the point where I immediately ship the patient to the next CT/MRI scanning facility with on\-duty neuro/neuro\-surgery\. All this requires is an append\-only text field\. Of course, it can be handled much more fanciful inside the EMR, trying to link items, graphing trends on scales, etc\. etc\. The basics, however, can be handled by free text fields\. And even they do not just emulate the paper based record but offer one clear advantage: they are readable by me even if someone else wrote down the first assessment\. > Narratives can be hard to handle in record\-based systems as can scannable > entries, e\.g\., charts and images\. But they are absolutely necessary\. Karsten --- ## Post #58 by @Sam Dear All I would like to raise the issue that there are structural models required to deal with security \- what structural components are you going to have access to or not \- containers if you will\. And then there is content \- though only when organised appropriately \- so that information in an 'organisational' category can be made private\. THe later is much more problematic and I do not think can operate outside of any specific jurisdiction safely \- the former is safer\. As openEHR shares transactions as the lowest level of transfer, I would propose that our initial work is based on this level\. The fact that you can see a problem list \- but it only contains some elements \- is of concern to me\. I would rather not have access to the problem list and operate on that basis\. What do others think? Sam --- ## Post #59 by @Tim_Churches > > Dear All > > I would like to raise the issue that there are structural models > required to > deal with security \- what structural components are you going to have > access > to or not \- containers if you will\. And then there is content \- > though only > when organised appropriately \- so that information in an > 'organisational' > category can be made private\. > > THe later is much more problematic and I do not think can operate > outside of > any specific jurisdiction safely \- the former is safer\. As openEHR > shares > transactions as the lowest level of transfer, I would propose that > our > initial work is based on this level\. The fact that you can see a > problem > list \- but it only contains some elements \- is of concern to me\. I > would > rather not have access to the problem list and operate on that basis\. > > What do others think? Maybe I've missed something much earlier on this thread, but don't you need a target security policy and associated threat model before you start designing ways to implement it? The problem, of course, is that there is no single agreed policy, even in broad terms\. But to me, the best starting point is still Ross Anderson's exposition of the policy he developed for the British Medical Association \- for the CiteSeer reference see http://citeseer.nj.nec.com/anderson96security.html There are still major technical challenges in addressing that policy, 8 or 9 years after it was first published, particularly with respect to trusted computing bases \( the NSA version of Linux with mandatory access control offers promise there\) and statistical disclosure control \(where theory still lags behind ad hoc practice rather badly\)\. But the rest can probably be implemented using role\-based security concepts \- the level of granularity of roles required by the Anderson policy is still orders of magnitude finer than anything which has been fielded to date, I think\. Anyway, the Anderson paper is worth a read, or a re\-read\. Tim C --- ## Post #60 by @Thomas_Clark Hi Karsten, Comments in text\. \-Thomas Clark --- ## Post #61 by @David_Forslund > Hi everyone, > > As Thomas & al\. pointed, security addresses "a number of aspects", including security policy \(defining who does what\), data safety, and how security is ensured: so, including safety of the network, the application architecture \-including management of messages: asynchronous/EHRcom/XML, or synchronous/CorbaMed/IDL\-, the programs, and the platform\. Just a minor comment here\. "CORBAmed" and thus CORBA deals with both asynchronous and synchronous "messaging"\. I would also second the comment by Tom Culpepper about a service which goes a long way to mediate the security requirements in healthcare\. Dave --- ## Post #62 by @Thomas_Clark Hi David, Definitely a component to be included in the: facility\-facility\-DataStore\-Management network\. There are other candidates, i\.e\., want to avoid focusing on a single technology\. \-Thomas Clark --- ## Post #63 by @Karsten_Hilbert Thomas, >> To me this is simply: > Patient prior history missing\. Sure but that was just an example to illustrate that a text field can easily provide storage for reassessing narrative\. > Relying 100% on visual inspections and observations may not cut it, Of course not\. But even in the imaging\-crazed US American Healthcare industry www\.trauma\.org teaches one to dismiss a potential neck injury patient if there's no clinical evidence whatsoever for such injury \(clinical being hand/eyes/mind here\)\. > An append\-only text field might be great for a User Interface supporting > text input but handling this over a course of treatment by multiple > Practitioners gets a little tough\. Suppose four Practitioners decide to > update their narrative simultaneously and they all 'finish' simultaneously\. > What happens to the record? Uhm, you end up with as many additions to the record as there are updating doctors ? \(This is the multiple\-update problem well known in CS\)\. So, what's the big issue here ? I mean, what they all type is not going to be funny essays about their recent holidays but information relevant to the current encounter with that patient\. > Single\-user, semaphore\-based UI applications are just not good enough\. If > someone forgets to unlock the record and leave for the evening I hope you > have their cell number\. Why would the application have to lock the entire record ? Why would there not be a timeout for that lock, perhaps based on presence\-detection \(timeout\) \+ timebased login restrictions for the account that forgot to "unlock" ? Why is the front\-door swipecard system not sending a signal to the EMR: "X is leaving" ? \(This, again, does not apply todoay to "remote areas of Y"\.\) > Narrative in their 'final' form are of interest to the record designer and > they will likely not look like anything you though you entered, e\.g\., encrypted, > compressed, pdf file that becomes a history file \(unchangeable\)\. But it better make damn sure it \*contains\* everything I typed in the way I wanted to represent it with the given input means \(eg\. hand formatted into columns or such\)\. Karsten --- ## Post #64 by @David_Forslund I'm not sure which part this refers to\. For example, theRAD is a standard specification that can be implemented in multiple technologies\. Thanks, Dave Thomas Clark writes: --- ## Post #65 by @Thomas_Clark Hi karsten, Comments in text\. \-Thomas Clark --- ## Post #66 by @Jose_E_Leon UNSUBSCRIBE How to unsuscribe from this list? --- ## Post #67 by @Bill_Walton1 Tim Churches wrote: /snip/ > Maybe I've missed something much earlier on this thread, but don't you need a > target security policy and associated threat model before you start designing > ways to implement it? The problem, of course, is that there is no single agreed > policy, even in broad terms\. But to me, the best starting point is still Ross > Anderson's exposition of the policy he developed for the British Medical > Association \- for the CiteSeer reference see > http://citeseer.nj.nec.com/anderson96security.html /snip/ > Anyway, the Anderson paper is worth a read, or a re\-read\. Thanks for the link\. I definitely found it worthwhile\. Anderson has a page at Cambridge that's got a lot of good stuff worth spending some time on\. His work on Medical Records \(and other stuff too\) is at http://www.cl.cam.ac.uk/~rja14/#Med Best regards, Bill --- ## Post #68 by @Karsten_Hilbert > Tracking is super\-important\. Include the image\. Of course one does\. If you have the image you store it\. > My preference is for an object\-oriented database since I might want to > retrieve all ER\-related information quickly \(includes narratives and images\)\. What do you do when your object\-oriented application falls over ? Here, an open source application/database is even more important than in plain relational DBs\. > If content is there upon > retrieval it likely was not there upon creation\. I am completely puzzled by this assertion\. Please explain\. Thanks, Karsten --- ## Post #69 by @lakewood Hi Karsten, Comments in text\. \-Thomas Clark --- ## Post #70 by @Karsten_Hilbert Thomas, >> What do you do when your object\-oriented application falls >> over ? Here, an open source application/database is even more >> important than in plain relational DBs\. > > There should be sufficient redundancy in the application to enable a > recovery\. No, I mean when your application is dead, your vendor's dead and you don't have the source\. Isn't it much easier to extract the data from a RDBMS or do I just not know enough about how objects are stored in OODBMS' ? IOW: Is there something like the PostgreSQL shell "psql" that lets me easily browse my data in an OODBMS no matter what application/programming language put it there ? > Interesting example from the legal world: > 1\)Patient has never had a broken right arm > 2\)Patient enters a nursing room > 3\)Patient remains for six months > 4\)Upon discharge Patient has experienced a broken right arm > 5\)No entry in the record regarding the event and perhaps subsequent > treatment > > Hence, regardless of the competence of the record\-based system there will > be situations where some things will remain the same\. Hm, I understand the content of this paragraph\. I am not sure, however, what you wanted to say with it\. Did you want to say that it can happen that events do not get recorded ? Well, that's sure true but what wisdom does knowing that buy us ? Karsten --- ## Post #71 by @lakewood Hi Karsten, Comments in text\. \-Thomas Clark --- ## Post #72 by @Karsten_Hilbert Thomas, seems like you don't get my point\. I am not in the least concerned about what to do when my frontend or backend decide to go fishing on behalf of the nice day instead of humming along in the office\. You stated that you prefer object\-oriented databases\. I expressed the opinion that in the case of, say, bankruptcy of my closed source vendor I am stuck with this huge chunk of binary data called OODBMS\. I wondered if there's a tool available for OODBMS' \(like FastObject\) that works like psql for PostgreSQL and lets me browse the objects and their relations \*without\* the vendors application regardless of whether the objects were stored there by Java, C\+\+, Huskell, Objective\-C or fad\-of\-the\-day\. I want to make sure to be able to recover my data without the vendor's software offering that and at a point where I cannot pay the vendor large bribes to include such functionality since the vendor is gone\. This isn't, however, related to OpenEHR anymore, so maybe should be taken off the list\. Karsten --- ## Post #73 by @Ognian_Pishev1 Matisse are using standard SQL with their OODBMS and it seems to be working fine\. --- ## Post #74 by @thomas.beale Bill, there are two kinds of audit trails in openEHR \- the audit trail of a change to a transaction or other artifact \(eg\. access control group\) \- see the COmmon RM for the semantics; and audit trails of access\. openEHR has not yet defined these, and I don't know if it should \- I suspect they will differ everywhere\. I expect that it has to be defined by an archetyped structure, so that basic semantics can be stated, and the normal archetype mechanism used as for everything else\. I cannot comment on HIPAA compliance at this stage \- not enough time to study it in detail\. \- thomas Bill Walton wrote: --- **Canonical:** https://discourse.openehr.org/t/openehr-security/15743 **Original content:** https://discourse.openehr.org/t/openehr-security/15743