The two major agenda items of the November HIT Standards Committee were the lessons learned from the Implementation Workgroup activities and security testimony from multiple industry experts in four panels - Stability/Reliability, Cybersecurity, Data Theft/Loss/Misuse, and Building Trust.
We began the day with an overview of the 10 major themes from the Implementation Workgroup testimony. We discussed the ways in which these themes could inform our future work in the upcoming months as we review comments on the interim final rule, consider incremental improvements to the standards supporting meaningful use in 2013/2015, and we consider tools/technologies/education to enhance adoption.
Specific action items include:
*Work hard on vocabularies and try to get them open sourced for the entire community of stakeholders.
*Consider adding a simple REST-based transport method for point to point exchanges between organizations. We already have recommended SOAP (as constrained by HITSP Service Collaborations) and REST as approaches to transport. At present there is no specific guidance as to how REST shoud be used from a policy or technology standpoint.
*Work jointly with the HIT Policy Committee to establish a privacy framework that enables us to constrain the number of security standards.
*As we continue our work, try to use the simplest, fewest standards to meet the need.
*Continue to gather feedback on the 2011 exchanges (ePrescribing, Lab, Quality, Administrative) to determine if there are opportunities to enhance testing platforms and implementation guidance that will accelerate adoption.
Interestingly, several people approached me at the meeting to discuss rumors that the HIT Standards Committee would significantly change the existing 2011 recommendations based on the Implementation Workgroup activities. The purpose of the Implementation Workgroup was to gather feedback, create a set of guiding principles, and ensure we have the best process going forward to ensure the most appropriate standards are chosen. The Implementation Workgroup activities including the blogs, the testimony and hours of discussion have raised awareness of all committee members that will support our future decision making, not revision of the work of the past.
The security testimony was extremely valuable. Here are some of the "Gold Star" ideas
Stability/Reliability
* Many existing clinical products do not provide the functionality needed to support security best practices
* Systems with FDA 501k certifications are often managed by vendors and lack updated operating systems and anti-virus software
* The least important systems are often those which are compromised and provide hackers access to more important systems.
Cybersecurity
*Security is journey and many healthcare organizations are not well resourced to implement security best practices.
*Security awareness among providers is low.
*We should focus on "Evidence-based security policies and practices". Per the testimony, some dogma in security is not supported by evidence i.e.
- Passwords longer than about 5 characters do not reduce risk in any meaningful way
- Encryption of data at rest in databases and other large systems in data centers typically provide little additional security protection
Data Theft/Loss/Misuse
*Portable devices/Wireless are a major vulnerability
*Audit logs from vendor systems may be insufficient to detect misuse of data
*Role-based security is important. Roles vary in institutions, so it will be challenging to create a one size fits all standard.
Building Trust
*Security should be layered to create an in depth defense
*Data integrity is important to protect patient safety (ensure the record is accurate)
*We need baseline policies and standards for Authorization, Authentication (including identity proofing), Access Control, Audit
A great meeting. I look forward to our next steps - reviewing the interim final rule in mid December based on all the testimony and learning we've had to date.
3 comments:
You can find some concrete thoughts on simplification here
This is a comment on the sentence above, "At present there is no specific guidance as to how REST shoud be used from a policy or technology standpoint." At HITSP SPI a few weeks ago, we had a great presentation on REST that allowed the group to identify some key differentiators from OASIS WS that formed the basis for some policy decisions on the use of the technology. The two differentiators were related to: 1) the complexity of the data for which REST is optimized, i.e. the very simple attribute value pairs; 2) the ability to support security and privacy with REST, i.e. REST is optimized for minimally sensitive data by running REST over TLS, but more sensitive data requires the addition of non-standards-based negotiations between sender and receiver.
Therefore, one kind of potential guidance is that the simplicity of REST is of most value when the data content can be simply expressed in attribute value pairs and when the data is not of major sensitivity concern, e.g. heavily de-identified patient-related data.
I don't think this answers issues for HITSP that arise at the gray areas in the middle, i.e. when is the data too complex for REST and when is the data to confidential for REST?
Thanks for the summary. The HIT Standards Committee was quite effective on all issues, except one: the so-called simple transport. I am afraid that suggesting two incompatible protocols may have defeated the worthy intent in simplification. Every implementer would be forced either to support both ways, or incur incompatibilities. It does not seem to be worth this added pain as they are no significant difference in implementation simplicity between a REST-based transport method (with ad-hoc security/privacy) compared to a WSDL/SOAP based method with built-in standard security/privacy as defined by HITSP. This is precisely why WDSL have been invented and are widely adopted so that programmers have little work to do with SOAP. In addition, the missing middle layer in REST-based transport will make us fall short of addressing the real-world health safety use cases (e.g.: document replacement in case of errors, atomic multiple documents submission). It seems that the HIT standards Committee has not finished its homework in this area.
Post a Comment