Webinar on the NEW work from IHE IT Infrastructure - Including updates to XUA

This Webinar will introduce the audience to the updates done this year. Including the updates to the Cross-Enterprise User Assertion (XUA) Profile. These updates add three named options:

• Role-Based-Access Control – option supporting specification of user roles to authorize the transaction -- Supporting role based access decisions on the service side
• Consent/Authorization – a specific way to carry an indicator of relevant consent or authorization policies that would authorize the transaction-- Supporting push of consent policies and provider-patient relationship
• Purpose of Use – option supporting the specification of the Purpose of Use that describes the reason for the transaction -- Supporting better Accounting of Disclosures
• Other Descriptive Attribute to support consistent way to carry some additional descriptive values

Here is the general information for the Webinar:

IHE Domain- Review of IT Infrastructure Profiles & Technical Frameworks

Thursday, August 5, 2010 at 10:30 am — 12:00 pm CST

New & Past Participant Webinar: IT Infrastructure is one of the eleven clinical & operations domains in IHE. Learn more about the most current profiles and technical frameworks which the ITI technical committee is working for implementation at the IHE 2011 N.A. Connectathon. Note: Past profiles and technical frameworks will not be discussed in length on this webinar. Please refer to the 2008 & 2009 webinars or secretary@ihe.net.

Speakers:
Karen Witting, Charles Parisot, Rob Horn, Michael Nusbaum — IT Infrastructure Domain Co-Chairs

Register Online >>

Stepping stones for Privacy Consent

Over the last few weeks HHS/ONC have produced lots of reading material. I have not had any trouble falling asleep lately, but it sure is getting hard to get through all of this reading material. The executive summary is that there appears to be a reasonable and comprehensive approach to Security, but Privacy is left behind.

That is to say that HHS/ONC have caught on to the need to use Security Risk Assessment as the prime 'framework' for Security. With the blog post EHR Security: A Top Priority by: Dr. Deborah Lafky of HHS it s clear that low-hanging fruit needs to be identified and picked. This is the lesson that I had hoped they would learn. I have seen many organizations learn this lesson, and indeed have seen many organizations have to learn this lesson multiple times. And so it is with HHS, who learned this lesson back at the original HIPAA Security rule and again now with the current set of specifications including the update to HIPAA.

They also recognized that the Standards and EHR products need to have reasonable security 'capabilities', but that using these capabilities is a policy choice that the provider should be free to choose to do, based on their Risk Assessment. I have further drill down on the Meaningful Use Standards: Meaningful Use Security Capabilities Lacking, Privacy Capabilities NON-existent

The bad news is that they seem to have backed off on Privacy Controls, again. I do understand why they do this, but I don't agree with their approach. What it seems to me is that they feel that if they can't do Privacy right, then it shouldn't be done at all. I think this is an approach that will lead to continued non-action. Unlike Security, that has the Risk Assessment approach to come to the rescue, Privacy is harder. But trying to slice Privacy up into digestible portions is a delicate thing.

What should be done?

HHS/ONC should have focused Privacy within the HIE. I understand how difficult Privacy is to deal with inside the existing healthcare provider organization. There is already policy and procedures and sometimes technology in place to deal with the HIPAA Privacy requirements. This environment is going to be hard to change, eventually it must. But it is the green-fields of HIE that need to be designed from the beginning with Privacy.

From what I read, an Accounting of Disclosures is clearly needed for every communication of PHI in a HIE; so why not require that an EHR interacting with an HIE must record this? There are standards for this, ATNA can inform an Accounting of Disclosures. There is ongoing work to make this better and better (See the new IHE XUA++ supplement soon to be published for Trial Implementation), but the basics are in place. Accountability using ATNA Audit Controls is critical to success.


From what I read in the HHS white paper on Consumer Consent Options, there are some basics of consent policies. Indeed going with the stepping-stones idea, why not require the standards and EHR to support blanket opt-in or blanket opt-out regarding participation in an HIE. This policy would not need to be related to any existing Provider Organizational policy, it would be restricted to the interactions with HIE.

When I say blanket opt-in or blanket opt-out, I really mean without exceptions. I really mean without break-glass. I am too afraid to declare about Government access, such as quality reporting. Seems to me these can already be handled by access to the Provider Organization.  I have been saying this for almost a full year on this blog Opt-In, Opt-Out.... Don't publish THAT! The HIE would still need to choose if they want a default opt-in or a default opt-out; meaning an implicit consent vs explicit consent environment. Then there is the question of if opt-out means that documents are not submitted to the HIE, a very difficult topic.

This choice of exactly 2 policies, opt-in vs opt-out, is not that friendly to those patients that want more control, but lets at least deal with those that are willing to choose YES vs NO. Today we have nothing but chaos, and chaos favors statuesque. An interesting study on the economies of privacy showed:

"When you have privacy, you value it more,” said Mr. Acquisti. “But when the starting point is that we feel we don’t have privacy, we value privacy far less.” More

It is somewhat unsettling that I am agreeing with Deborah Peel . Awareness of Privacy is not enough, action is necessary. I simply want to push for some achievable stepping stones that clearly head in the right direction.
I am excited that the HIT- Security and Privacy Tiger Team has also recommended this, and More

An excellent blog article on this topic Health IT policy intensifies focus on consent.  This article very nicely picks apart the actions going on in DC.

Reference my blog article: The meaning of Opt-Out, Opt-In, Opt-Out.... Don't publish THAT!,  Consent standards are not just for consent, Consumer Preferences and the Consumer, and RHIO: 100,000 Give Consent.

Meaningful Use Security Capabilities Lacking, Privacy Capabilities NON-existent

I hope that anyone developing a Complete EHR or EHR Module goes way beyond the capabilities required in the Meaningful Use Standards - [Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology]. This is not just because I want to push these products beyond some bare-minimum; but rather that the capabilities that any system entrusted with objects that need protection need to go beyond the bare-minimum listed. I leave 82% of the text to people smarter on the clinical aspects such as Keith at Meaningful Use Standards Summary

When the IFR came out I declared that Meaningful Use clearly does not mean Secure Use. I then took a step back and evaluated the criteria carefully and submitted Security/Privacy comments on the IFR. This was at the time based on the same set of gaps that still exist. To be fare the Final Rule did fix many of the problems with the text that they did have, almost a complete fix of the problems with the existing text. From my understanding of the rules, an IFR can not be radically modified or added to; so HHS was not really allowed to close the gaps that still exist.

So, any EHR that has been designed toward a good set of security capabilities will likely have the right stuff. I think the current text is useful but still not really going to drive good product design, while it will drive unnecessary churn. If HHS had not tied their own hands with the IFR process, they could have referenced NIST SP 800-53 “Recommended Security Controls for Federal Information Systems and Organizations” (http://csrc.nist.gov/publications/PubsSPs.html). This is a very good set of criteria that has been the basis of, or derived from, many other good criteria. Most of what is in here can be found in the CCHIT security criteria as well. It is sad that healthcare seems to want to re-invent the wheel so much. My recommendation is to follow CCHIT criteria or better to follow NIST 800-53.

I do understand the market readiness of Privacy Controls, but it hurts to see these things continually kicked down the road. I am working hard to get these standards in place, then working even harder to get the standards that we do have implemented, and eventually will work really hard to get them deployed. I think that we are close, and that MU could start pushing some of these. I hope to find some of this in stage II. Consent, even just blanket opt-in/out (blog on consent); Accounting of Disclosures (blog on Accounting of Disclosures); Data Segmentation (future blog topic); and Limited Patient Access to their records.

Critical for everyone to recognize the certification criteria for a Complete EHR or EHR Module are ‘capabilities’. These capabilities will be chosen to be used or not based on a Risk Analysis. The Risk Analysis that has been a core of Meaningful Use and the HIPAA Security rule all along. A Risk based approach applies technology when justified. A Risk based approach does not apply technology simply for the sake of applying technology. At this point I will indicate that there are Bad and Ugly parts of the Final Rule that don’t recognize that some possible capabilities that will never be reasonably used should not be mandated.

The following is further comments on the Final Text..

The Good

The good news is that they did fix some important problems

1. They removed the whole religious war around REST and SOAP. I am sure I was not the only one to point this out to them. I am glad it simply was removed.
2. They got less proscriptive on encryption, and chose to leverage the great work of NIST in FIPS 140-2 Annex A.
3. They got less proscriptive on integrity controls, point at NIST FIPS and SP; but they still have some strange text that could cause unnecessary arguments
4. They removed the requirement for the EHR to alert based on user-defined events. This is not only a very open-ended requirement (user-defied events), but is a very specific functionality of audit log analysis. Not a bad feature to have in a full featured EHR, but clearly not a minimalist requirement
5. They added “Accessed” to the auditable events. This should have always been there, but I suspect it slipped between the terminology from multiple good security audit log standards harmonization.
6. They removed “Print” from the auditable events. Well, they went a bit too far in the comments. Print should be recognized as a form of Export. And any time the EHR knows that it is exporting PHI is an auditable event. The comments were about all the edge cases where the EHR is unaware of a export, such as taking a picture of the screen. This is far better handed through a clear distinction that auditable events are those events that the EHR is in control of. This clearly makes it obvious that an event that the EHR can not control couldn’t possibly be audited by the EHR.
7. They dropped the Cross Network Authentication. I very much agree that XUA/SAML is not ready to become a certification criteria. But I had recommended that they recast this requirement so that communications going between organizations are authenticated organization-to-organization, essentially what ATNA requires in mutually-authenticated-TLS. There is no requirement for this level of authentication in the criteria.
8. Accounting of Disclosures is optional – We all know that indicating that this is optional is as good as removing it. This one is hard to say is a good thing, because Accounting of Disclosures is so critical to Privacy; but the facts are that the standards are still being developed and that the Accounting of Disclosures that can come from the EHR is a reporting function of the Audit Log Management. The reality is that most actual Disclosures are not detectable by an EHR as they are events at the organization level. Thus the actual Accounting of these Disclosures is a higher level function than an EHR. Good Blog by Security Architecture This unrest is further expressed by this weeks announcement that HHS pulled the Health Data Breaches Proposed Final Rule from OMB review. No news yet on why.

The Bad

The Bad news is that there is still some small problems. None of these is really critical or going to cause trouble. Again reasonable minds will come to the same and right conclusion. So, don't worry too much about these items.

1. They are timid about Security Audit Logging. Not only do they reject ATNA, which is likely the right choice for now (but not for the reason they give); but they also fail to recognize critical auditable events. An Emergency Access override should clearly be an auditable event.
2. No change to Automatic log-off – Yes automatic log-off is needed, actually HIPAA has this covered and covered better. Termination of a session is excessive, removing access to PHI after inactivity is not.
3. The Encryption and Integrity Controls are still messed up. Yes it is great that they are referencing the good work of NIST. But they are still too prescriptive on how to use these cryptographic algorithms. They needed to take a step back and abstract further. Fact is they should have abstracted as far back as HIPAA. The only reason that Encryption or Integrity Controls should have been mentioned was to specify some minimum Interoperability criteria. This would have required that they indicate a protocol, such as TLS. For some reason they were afraid of this. The point would have been that the EHR have the ‘capability’ to use TLS, not that TLS was the only operational choice.
4. Detection of alterations of the audit log – This has got to be the strangest criteria I find. I have nothing against protecting the audit log from alterations. BUT, why only protect the audit log? Why did they remove all the other things that should not be modified without authorization? Actually the detection is of all alterations, not unauthorized ones, thus any event that is recorded will alter the audit log by being appended to it and this will cause an audit event that the audit log was altered which will be appended to the audit log which will be detected… THIS CRITERIA MANDATES THAT THE EHR GOES INTO AN INFINITE LOOP! The line should have been removed.
5. As indicated in (6) above; there is no requirement that systems talking across the internet authenticate themselves. I suspect this is an obvious gap that everyone will fill it. But it is an example of how the criteria are too low level. A simple ‘secure communications using open-standards’ could have solved this completely.
6. Authentication is not Authorization – this is a pure nit… The Authentication criteria should be only about authentication, and not have added authorization to the task. Authorization is already handled
7. Encryption of all network communications involving PHI. There is lots of comments on this one, and I disagree with the conclusions. Today PHI travels securely through many different ways, some private networks. The rule should have limited the scope of these transport encryption and integrity controls to the NEW communications requirements of Meaningful Use. This scope would have focused attention ‘green fields’. This is not to say that the old communications couldn’t be improved upon, but they would be improved at a more reasonable pace. As written the EHR must be able to add encryption to all communications, some communications that no Provider will use this new encryption capability because they already have a secure communications.
8. Transparent security capabilities – This goes with many of the points above. Security is often implemented in transparent layers. No developer spends any effort on developing code that checks that data base entries have been inappropriately modified; this has been a common database tool functionality for a decade. Indeed the requirement for SHA1 to be used could have developers spending lots of time trying to figure out if their database tool uses SHA1. If it is found that SHA1 is not used, then what? How is the developer to evaluate the difference? This is wasted time!!! I suspect that most will understand this as a waste of time. I will then assert that the same is true about other security capabilities. For example Hard-Drive Encryption. It is quite common now days to add a transparent hard-drive capability to a laptop. When this is done all applications on the laptop are protected, and actually these applications can NOT tell. So, requiring an EHR to have hard-drive encryption is going to drive unnecessary waste of time and energy. What about the use of VPN to provide transparent network security? These are far better implemented as transparent security capabilities in the organization level not in the EHR. I would like to push more and more in here as well including User Authentication, Node Authentication, and eventually much more.

The Ugly

The General Encryption rule has conditionals “unless the Secretary determines that the use of such algorithm would pose a significant security risk…”. This is wrong on so many levels. Why is this the Secretary role? Isn’t this the Risk Analysis role? The whole “General Encryption” criteria changes the game from a case where the Risk Analysis determines when a technology (like Encryption) is necessary; to a case where Encryption must be presumed needed unless the Secretary determines that it is not needed. Does this mean that the Secretary is going to evaluate each time a patient gets harmed because data could not be legitimately used? I really hope this one gets corrected somehow, and quickly.

Etc

Medical Records Retention requirements seem to be touched upon, but not fully. Change Tracking is not a security audit log scope, but it is a Medical Records Retention requirement. The HL7 EHR Functional model spent lots of time fully understanding Medical Records regulations as well as their separation from Security requirements.

Healthcare should join OASIS Privacy Management Reference Model (PMRM)

This is the latest effort to focus on understanding the requirements of Privacy Controls, and buildin a reference model to manage privacy policies and support enforcement. I have added my name to the group, but because of OASIS rules of membership classification I get no mention as I am only an "Individual Member" and not an "Institutional Member".  I am disappointed that I have been unable to convince other healthcare organizations to bring healthcare needs to this group. I think healthcare is an especially critical and yet complex problem. That is to say that I want the needs of healthcare to be known, but don't have any expectation that they will be solved for years. But if they are not known by this group then they could very well go down pathways that healthcare can't follow, such as DRM.

OASIS has announced the creation of a new Privacy Management Reference
Model (PMRM) Technical Committee. It's principal objective is to "develop
and articulate a Privacy Management Reference Model that describes a set
of broadly-applicable data privacy and security requirements and a set
of implementable Services and interactions for fulfilling those
requirements.  The first meeting of the PMRM TC will be held as a
teleconference on September 08, 2010. Institutional member companies
approving the TC charter include CA, ISTPA, NIST, American Bar
Association, WidePoint Corporation, and Information Card Foundation.
The PMRM TC is expected to be of interest to privacy policy makers,
privacy and security consultants, auditors, IT systems architects and
designers of systems that collect, store, process, use, share, transport
across borders, exchange, secure, retain or destroy Personal Information.

The TC will accept as input the existing ISTPA Privacy Management
Reference Model v2.0 -- a structure for resolving privacy policy
requirements into operational controls and implementations -- developed
by the International Security, Trust and Privacy Alliance (ISTPA). It
is anticipated that this document will be contributed to the TC for
further elaboration and standardization at OASIS.

Specific goals of the TC are to: (1) Define a set of operationally-
focused privacy requirements which can serve as a reference for
evaluating options for designing and implementing operational privacy
controls. These requirements will constitute a useful working set of
'privacy guidelines', which can both serve as general guidance, and as
a feature set against which the PMRM and any implementation can be
tested. (2) Define a structured format for describing privacy managementServices, and identify categories of functions that may be used in
defining and executing the Services. (3) Define a set of privacy
management Services to support and implement the privacy requirements
at a functional level. These Services will include some capabilities
that are typically implicit in privacy practices or principles (such
as policy management or interaction), but that are necessary if
information systems and processes are to be made privacy configurable
and compliant. (4) Establish an explicit relationship between securityrequirements and supporting security services (such as confidentiality,
integrity and availability services) and the privacy management Services.
... More

See also the OASIS Privacy Management Reference Model (PMRM) TC public web page: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pmrm

Tutorial on HL7 Security Cookbook at Boston HL7 meeting

The HL7 24th Annual Plenary and Working Group Meeting is going to be held in Cambridge, MA on October 3-8, 2010. There is a fine Plenary agenda focused on "Future of Healthcare Using Genomics as a Key Tool". 

In addition to the Plenary and all the workgroup meetings, there is yet one more reason to attend. I will be presenting the HL7 Security Cookbook as a Tutorial. I will be presenting Thursday Morning. The Security Cookbook is the process that HL7 is adopting to assure that as standards are written they have incorporated appropriate security considerations and document relevant risks that need to flow down. I discussed this in prior blog post How to Write Secure Interoperability Standards

The formal name I gave to this tutorial: Security Risk Assessment Cookbook: Incorporating Security in HL7 Standards (clearly it got shortened for the web site)

Brief General Description Of This Tutorial:
Healthcare today has some of the most diverse needs with regard to sharing of data and the need to securely move patient information among systems. Within Health Level Seven (HL7) there are multiple verticals that consider messaging, structures, data models, coding and the like. Security is the common thread that connects all of them. Increasingly, healthcare organizations and technology vendors are performing assessments (threat risk assessments, privacy impact assessments, business impact assessments, etc.) to ensure installed healthcare technology will have a positive impact on healthcare delivery. These assessments, often called risk assessments, are even mandated for healthcare delivery organizations in some countries. Unfortunately, key decision makers often have difficulty understanding the relevance of the risks identified, and often overlook them when writing standards.

This Security Risk Assessment Cookbook is intended to enable HL7 domain committees and working groups to publish standards that have taken privacy and security considerations into account. This guide introduces security risk assessments and a process to facilitate completing a security risk assessment for a specific standard. Using this process will facilitate the identification of gaps in a standard’s baseline security and privacy, allowing the working group to either update the standard on their own or to send a request to the Security Working Group for assistance in filling the gap. This will lead to standards that include privacy and security as part of their base, reducing the need to “bolt” security on later. As a result, the HL7 standards will better support patient safety and improved patient outcomes.

Who Will Benefit From This Tutorial?:

• HL7 committee members to understand how to consider Security when writing standards
• All those using HL7 standards to understand how to use the Security Considerations

Upon completion of this tutorial, students will know:

• How to publish standards that have taken privacy and security considerations into account.
• Introduction to security risk assessments and a process to facilitate completing a security risk assessment for a specific standard.
• Method of identification of gaps in a standard’s baseline security and privacy
• Method to send a request to the Security Working Group for assistance in filling the gap.
• How to interpret the security considerations when implementing systems based on standards

Healthcare use of Identity Federation

This is exciting times in Identity Federation. I have written about Identity Federation as a critical technology in : Federated ID is not a universal ID  Specifically I think that SAML is a specifically useful protocol for Identity Federation for the purpose of identifying users requesting cross-enterprise based transactions. This is specifically the purpose behind the IHE Cross-Enterprise User Assertion Profile. This profile does not fully leverage all of the power of SAML, but tries to constrain SAML just enough to get Healthcare going at using this technology. IHE is now extending this profile with some more attributes about the user. Specifically adding a descriptive string for the user, their organization, identifier of their organization, their National Provider Identifier, and such. Also adding their role and the purpose of their request, values that might be used for access control and/or audit logging (such as I describe in Accountability using ATNA Audit Controls).

There is also the recent release from the Whitehouse of "The National Strategy for Trusted Identities in Cyberspace".  From my read of this their goals are in the right place, they do seem to understand the potential miss-use, and they do seem to understand that the only way we can move forward today is to force the issue. This force is not to force a solution, but rather to force the discussion and encourage specific reasonable use-case developments. I think that Healthcare could be a very useful use-case, inclusive of Health Information Exchanges (HIE) and Personal Health Records (PHR).  My biggest concern with this initiative is that they seem to be leaning toward a Certificate (PKI) based solution, and may not see the power of SAML.

There have been many articles and blogs that discuss the issues, solutions, benefits, and risks.  I have specific concerns around any mandate, I certainly recognize that any one human truly does have many identities and has good reason to make sure that some of these identities are never cross-referenced. I understand that the Whitehouse initiative is not looking to a nation wide mandate on all citizens, but rather wants an open discussion to help inform how the federal government continues to evolve their use of trusted identities in cyberspace, essentially they understand that first they must 'eat their own dog food'. This is a good approach but they must recognize that the federal government infrastructure hits upon the non-federal infrastructure in many ways. For Healthcare this is very specifically the HIE.



There are some other solutions that are getting lots of press, and well deserved attention. Keith Boone blogged about his success at leveraging the OpenID mechanism to allow him to offload the user account management (including provisioning, de-provisioning, and such) from his purpose for having an internet present service. OpenID is a good tool to get started in this topic. Open ID is very low barrier to entry is very helpful, and the abiltiy to offload the user account management is a big plus. It however is not as formal on how to carry attributes and authorization decisions. This is not a good excuse to not start with OpenID.


I think the power of how OpenID and SAML can be used together is showed by a Clinical Trials project that Medtronic was involved with. Their solution is documented nicely on the Kim Cameron's Identity Blog. This is a project that offered their solutions to open-source and used both OpenID and SAML when the specific tools were the right tool to use. This is the kind of Healthcare use-case that I think should be encouraged by the Whitehouse initiative.

HHS Releases New Proposed HIPAA Security and Privacy rules

I am amazed that out of one side of HHS they ask for healthcare-IT to be adopted quickly, while they continue to release HUGE new documents. In this case it is an update of the HIPAA Privacy and Security rules, probably a worthy thing to do. But does it need to be so big and vague?  Why is 234 page really necessary? Yes the first 175 pages are introduction that is not legal, but still this is excessive. The deadline for the comments is 60 days past the official publication. So, I am sure no one will do anything in the next 120 days for fear that they are doing something that might be in violation of these new rules.

HHS has announced the release of a HIPAA Privacy & Security NPRM which will modify aspects of HIPAA as amended under the HITECH Act. The NPRM has not officially been published in the Federal Register, however, the pre-publication PDF of the rule was released and can be found at: http://www.ofr.gov/OFRUpload/OFRData/2010-16718_PI.pdf

I will be further dissecting this NPRM on my blog and responding to .

My point is not specifically against this new rule. But rather that HHS/ONC seem to be continuously ripping open the scab just as we start to feel like we understand what to do. If it is not security/privacy it is some new statement on code-sets, or document types, or etc...