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
)