Health Data Breach Rules - Started but not enforced yet

The data breach rules for both PHR and for HIPAA covered entities is in effect, but will not be enforced until Feb 22, 2010. It is very unclear what will happen in the next 5 months if a breach happens.

New rules governing consumer notification when the security of their health information is breached go into effect this week. But federal agencies won't enforce the rules for several more months. Both rules were mandated under the American Recovery and Reinvestment Act.A final rule from the Federal Trade Commission, published Aug. 25 and effective Sept. 24, requires vendors of personal health records--and entities that offer third-party PHRs--to notify consumers of data breaches. In the rule, the FTC noted the quick deadlines that were statutorily mandated and imposed a grace period on enforcement. "Therefore, the Commission will use its enforcement discretion to refrain from bringing an enforcement action for failure to provide the required notifications for breaches that are discovered before Feb. 22, 2010," according to the rule. "During this initial time period--after this rule has taken effect but before an entity is subject to an enforcement action--the Commission expects regulated entities to come into full compliance with the final rule." ...More

IHE Releases White Paper on Access Control

IHE has released the second version of the Access Control white paper. This is a fantastic paper, self-serving because I did have a hand in it. This is a simple abstract view of Access Control, specially focused on scalability to federated systems. This paper also ties together many of the concepts being worked at this time.

This document looks at the issues of how to define and implement access control in healthcare networks that might even span across communities. The focus is mainly on issues that relate to the IT architecture and the flow of messages that are required for a distributed access control scenario. Therefore this paper will deal with the problems of (1) how to apply established principles of secure design and SOA security on the design of access control systems and, (2) how to model an access control solution in a way that is well suited for reasoning and evaluation. It also begins the discussion of how to deploy an access control solution using well understood patterns and interoperable system components as seen in appendix C.

Given the strong focus on models and methodologies for designing access control solutions for cross-enterprise data exchange in healthcare, the primary intended audience are system architects and developers who are involved in the planning, design, and realization of regional healthcare networks and comparable infrastructures where the secure exchange of patient related data among enterprises is an issue.

The concepts presented in this paper are evolving rapidly and are subject to manifold national and international standardization efforts. The goal is to expose the common concepts from all of these activities, match them with experiences from existing healthcare networks, and define common design methodologies and technological building blocks which allow for a variety of strategies and policies to be used. The building blocks are described on a conceptual level and on an integration level based on current state-of-the-art in security token handling.

It is assumed that the design of the overall healthcare data exchange infrastructure is aligned to the principles of a service-oriented architecture (SOA). It is furthermore assumed that a dedicated security architecture is set up which provides a circle of trust among the security and business services which are deployed among independent XDS Affinity Domains. Nevertheless even if the focus is on cross-enterprise health information exchange (HIE) all concepts provided by this white paper can be scaled down to the organization or even department level.

Outline of the White Paper

• Chapter 2 gives an overview of all recommendations that are made in the entire document. These start with high level generic recommendations, then shift into detailed recommendations taken from chapters 3 and 4, and then into recommendations for IHE gap filling taken from chapter 6. The detailed recommendations and gap filling may be somewhat confusing when read out of context. Their full context is introduced later in the document, where the recommendations can be found again. The glossary may be useful to understand the terms used in this chapter.Chapter 3 reviews fundamentals of access control, the state of the art, and introduces the Access Control System (ACS).
• Chapter 4 reviews policies and relevant attributes which are needed in order to design a proper policy-aware healthcare solution. It illustrates how different shapes of policy concerns might be harmonized and relevant attributes are bound to policies.
• Chapter 5 presents the methodology for designing an ACS by presenting an example use case.
• Chapter 6 fills the gaps in the current technical framework. There are specific recommendations for IHE activities. Some of what the model needs are already present in the IHE Technical Frameworks. There are other specific actors and transactions recommended for profiling, as well as some recommendations for educational whitepapers and recommendations against some other proposals that are likely to conflict with this recommended model and methodology.
  

Kerberos required in 2011 then forbidden in 2013

The HIT-Standards Privacy and Security selections include Kerberos for 2011 then Kerberos disappears in 2013-2015. This has caused much discussion and confusion, so let me summarize what is going on.

The committee is trying to say that if a healthcare provider does not have an enterprise class authentication in place today they need to do so and Kerberos (i.e. IHE-EUA) is the right solution (e.g. Microsoft Active Directory). Implementing a User Directory is a very good thing to do as it allows the organization to have a centralized identity system for users (i.e. HITSP/T64 -> IHE-PWP -> LDAP) with a centralized authentication system (Kerberos). Thus allowing for more consistent user provisioning and deprovisioning.

The key is that the EHR must leverage this User Directory for authentication and user attributes including security attributes. This is the only way that the providers get out from under having to remember multiple user identities and credentials for each system they use. This gets to a problem many providers have today in that they need to remember around 20 different credentials (user/pass). Often the short term solution given is to implement a Single Sign-On (SSO) solution, which masks the problem by putting a portal in front of each application that 'manages' the 20 different credentials but presents the provider with one credential. There are many problems with SSO, but the solution is likely better than nothing. To be clear, the solution selected by HIT-Standards is to implement a single identity solution and require that the EHR support this solution.

The problem with Kerberos is that the technology is not well suited for communications outside of the organization as it is very time-sensitive. For communications across organizational boundaries the solution is SAML identity assertions (i.e. C19 - XUA). The reason why SAML was not selected for 2011 is that the marketplace is not yet mature with SAML implementations, so by putting this clearly in 2013 the HIT-Standards are telling EHR vendors to get implementing it.

So, why does Kerberos dissapear in 2013? The use of Kerberos authentication will cause an irreconcilable conflict for the Federal providers (i.e. VA, MHS, IHS). Recent updates to NIST SP 800-63 (E-Authentication Guideline), which are still in draft, (http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf) disallow Kerberos at Level 2 assurance or above. That is, Kerberos is being relegated to Level 1 assurance (essentially no assurance at all). The relevance of this is that in 2011 Federal agencies will no longer be permitted to use Kerberos for authentication in any new systems they implement, since those systems will require at least Level 2 (more likely Level 3) assurance.

By setting Kerberos as a 2011 standard HIT-Standards is in effect telling the Federal partners that they are required to implement a standard which OMB forbids them from implementing. Now, clearly, the situation is different in the private sector, where they are not subject to OMB requirements. HIT-Standads does not want to create a path whereby the Federal and private healthcare sectors diverge on security standards.

So HIT-Standards tried to walk the line between all of these issues. The end result is: If you can implement a Central Directory, do so. If you are a vendor, support Kerberos/LDAP as a User Directory. Everyone start looking at implementing SAML.

Encryption now Mandatory

I have had many conversations lately about encryption. I want to try to clear up the misunderstood message. The message that people have been hearing is that there is now regulation that requires encryption. There are many places to find encryption in regulations, but what has happened lately is likely the source of the excitement over encryption.  The HITECH "Breach Notification" regulation is going into affect September 23, 2009. This rule sets out many responsibilities for a Covered Entity or their Business Associates that exposes PHI (breach). A really good article on this.

Where encryption comes into the picture is in the portion of the rule that gives a CE or BAA a 'get out of jail card'. There are cases where the breach notification does not need to be done. The rule includes that the encryption must have followed NIST Special Publications. For example for Data at Rest: NIST 800-111.
We have been recommending TLS security using RSA authentication, AES encryption, and SHA-1 integrity checking. HIT-Standards has requested that SHA-2 be used rather than SHA-1 in keeping with FIPS recommendations. So, we have a pretty good data transport encryption.

So, generally for mobile devices (laptops, PDA, USB-Memory, backup-tape, CD-ROM, DVD, etc) that have PHI in their storage, encryption following the NIST guidelines will allow the organization to not need to register the breach or notify the potential patients.  This is what "encryption is mandatory" actually means. For many of these the organization can apply a whole-disk encryption technology, backup technology that encrypts, or can purchase USB-Memory sticks that do on-board encryption. HIT-Standards included this as well in their criteria, under the Access Control category, even citing NIST SP 800-111.

Groups give Obama high grade for medical privacy

ARRA did include some significant items on Privacy, but really simply closed some gaps around the edges. I am less impressed with what was in ARRA vs the interest that HHS/ONC has toward working with industry and privacy advocates. HITSP is at the center of this development and I hope will result in a real ‘harmonization’ effort.

A coalition of privacy groups gave the Obama administration a grade of A- for progress in medical privacy because of provisions in the stimulus law strengthening safeguards over personal health information. “The privacy language makes the bill one of the best privacy laws in years,” said Lillie Coney, associate director of the Electronic Privacy Information Center (EPIC)  and coordinator for the Privacy Coalition. More

HIT Standards - Meaning of S&P selections

I represent HITSP on the HIT Standards Privacy and Security Committee. As part of this I help the group understand the specifications from HITSP. This is not always simple, as many have pointed out the various levels of indirection built into HITSP both simplify yet obfuscate. So, I have been asked often to explain exactly what did the Privacy and Security Committee mean?

For the most part they have simply looked at the HITSP standards selections and indicated where along a roadmap the standards are likely to be mature enough to be measured at the Provider, aka Meaningful User. Some of the Privacy and Security standards from HITSP are very mature, well implemented, and super critical to keeping healthcare information secure and protect patients privacy. Some of them are equally immature and unimplemented, although functionally very important. The committee added some additional standards because they felt it important to fill an area that HITSP had not yet been asked to fill.

The exceptions are:

1. Need to add more more cyphers to T17. This means that right away everyone must implement TLS Version 1.2 and SHA-2. This is a significant upgrade from what IHE has been saying for a long time. It is not inconsistent, as IHE simply says that at minimum one must have TLS_RSA_WITH_AES_128_CBC_SHA. HIT Standards is saying that you must also support TLS_RSA_WITH_AES_128_CBC_SHA256.
   
2. Need to support EUA (Kerberos) in first year, although it will not be sufficient in later years. The discussion clarifies that if you don't have an enterprise-user-authentication then do it with Kerberos, yet if you have one stick with it.
   
3. Somehow need to support use of AES for data-at-rest. There is no standards to point at besides AES, but the committee couldn't come to say nothing about the risk. So the best we could do is point at NIST SP800-111
   
4. Delay TP20 until last years because of standards development followed by implementation lag. The expectation is that access control is implemented, just not using the standards selected in TP20. In spirit there is strong support and need for TP20 conceptually, but the reality of the standards maturity and lack of implementations simply mean the requirement to use these standards is later.
   
5. Delay BPPC style consent till 2013. I am not sure how privacy is managed before then. The NHINs have already implemented basic BPPC (yes I just said "basic BPPC", which means opt-in/out only).
6. Delay use of digital signatures till 2015 when it is expected that use-cases will eventually justify the overhead of PKI
7. Add S/MIME security in 2015. I am not sure at all why this one is delayed, but then again HITSP hasn't touched the subject directly either. For the most part HITSP has chosen to consider e-mail as a commonly implemented infrastructure that they do not need to further profile, so HITSP simply says to use secure email.
   

The HITSP set is below. bold/italics indicates an exception above

• CAP119 – Communicate Structured Document
• CAP120 – Communicate Unstructured Document
• CAP143 – Managing Consumer Preferences & Consents
• SC108 – Access Control
• SC109 – Security Audit
• SC112 – Healthcare Document Management
• T17 – Secure Communications Channel
• T64 – Personnel White Pages
• C19 – Entity Identity Assertion
• C26 – Nonrepudiation of Origin
• T24 – Pseudonymize
• C25 – Anonymize (for Biosurveillance and Quality)
• C87 – Anonymize Public Health Case Reporting Data
• C88 – Anonymize Immunizations and Response Management Data

HIT Standards Committee Recommendations Public Input Process

Please see the Privacy and Security criteria listed in #3 of this release:

As part of the ARRA, ONC is required to publicize the HIT Standards Committee recommendations in the Federal Register and also provide for public input. Below is information on the public input process.

HIT Standards Committee Recommendations: During the August 20, 2009, meeting, the Committee’s recommendations focused on the following areas: Clinical Quality, Clinical Operations, and Privacy and Security. All recommendations may be found at http://HealthIT.hhs.gov/ standardscommittee. In addition, specific URLs for each recommendation have been listed below.

I. Clinical Quality

A. Background

The Clinical Quality recommendations pertain to the appropriate standardized performance measures that correspond to the HIT Policy Committee’s 2011 Meaningful Use Measures. The recommendations include 30 quality performance measures and the data types required for each, of which National Quality Forum (NQF)-endorsed measures can either be retooled for use in an Electronic Health Record (EHR) or will require attestation for the foreseeable future.

B. Recommendations:

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10741_880489_0_0_18/2011%20Measure%20Recommendations_Clinical%20Quality%20Workgroup_08202009.pdf

II. Clinical Operations:

A. Background

The Clinical Operations recommendations focus on standards for 2011 Meaningful Use, including quality data reporting, messaging formats, and all the vocabularies necessary for semantic interoperability.

B. Recommendations:

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10741_880490_0_0_18/Ferguson_Clinical%20Operations%20WG%20Recommendations%20Revised%20Summary.pdf

III. Privacy and Security:

A. Background

The Privacy and Security recommendations focus on authentication, authorization, auditing and secure data transmission standards as well as Meaningful Use measures related to HIPAA compliance.

B. Recommendations:

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10741_880497_0_0_18/PRIVACY%20AND%20SECURITY%20STANDARDS%20APPLICABLE%20TO%20ARRA%20REQUIREMENTS.pdf

Procedure: Individuals wishing to make comments on the Committee’s August 20, 2009, recommendations may present oral comments at the Committee’s next meeting on September 15, 2009, from approximately 1:00 p.m. to 2:00 p.m./Eastern Time, at the Omni Shoreham Hotel, 2500 Calvert Street, NW, Washington, DC, 20008. Comments will be limited to two (2) minutes per person. A separate notice announcing this meeting has been published in the Federal Register and provides additional information.

HITSP August 2009 face-to-face -- Security, Privacy and Infrastructure

The HITSP Technical Committee/Tiger Team Face to Face Meeting was held last week in Chicago. There were 120 attendees that participated in the continued work efforts and deliverables.

Standards Development Work

HITSP will be updating quite a few constructs and creating other constructs based on updates coming from Standards Development efforts. In all of these cases the standards work was initiated by HITSP:

IHE

• XDS-I --> TP48/89
• XDS.b --> TP13 == This is now Final Text and IHE has indicated that IHE.a is deprecated
• DSUB --> TP13? == This is new profile that fills a gap identified in TP13 for the ability to subscribe to topics about documents and get notified when new publications that meet the criteria
• MPQ--> (unknown) == This is a new profile initiated by the quality reporting groups that allows a trusted system to make queries that are not constrained to a single patient. There are two output types: Full metadata and list of matched document identifiers.
• XCPD --> TP13? == This is a new profile that fills a gap identified in TP13 for the ability to discover communities that contain information on a specified patient.

HL7

• Security Permissions catalog is out for ballot --> C19/TP20

OASIS

• XSPA specifications are continuing through the OASIS process.
• XSPA-SAML --> C19;
• XSPA-XACML --> TP20

HITSP needs to step up and submit new work requests before IHE Planning starts. It doesn’t look like there is much that will hit IHE this year from HITSP.

Consumer Preferences

The most exciting aspect of the meeting is that representatives from ONC participated in the meeting to provide guidance and help kick off the Consumer Preferences Tiger Team effort. The use-case will progress as an iterative work between ONC, HITSP, NHIN, and FHA-CONNECT. This will allow us to work through the details of what is desired with when it can be accomplished.

Consumer Preferences is a larger category than previously discussed. The overall use-case will include Privacy-Policy-Acknowledgement (aka Consent and Authorizations) but will also include the patients ability to publish things like advanced-directives. These second class of preferences will be worked out by Consumer Perspective and likely the Care Management workgroup. SPI will continue a workgroup that will focus specifically on the privacy policy issues which are likely to be a continued development of CAP143 and TP30. The discussions included the need to prioritize the overall landscape of potential privacy policy.

Clinical Research

The SPI committee will be working on a new Anonymization construct to support Clinical Research. The data set needs to be defined before the SPI committee can go forward.

There was discussion around pseudonyms. Much of this was to explain the differing uses of the words Pseudonymization, Anonymization, and de-identify. The prevailing approach in HITSP is:

a) De-identification is the overall process

b) Anonymization as the process used to lower the risk by assessing each data attribute in the context of the intended use which results in a specific handling of each attribute: pass through unmodified, remove as unnecessary, change dates to ages or ranges, etc.

c) Pseudonymization – create an alias for the subject (patient) that is not otherwise associated with the normal data.

Consumer Perspective

In addition to the Consumer Preferences work, there is the “Location” issue related to communicating from one PHR to another PHR. The use-case wants to be able to deliver all the data in one PHR to another PHR. We discussed the various topologies that a PHR would participate in.

a) Media – this is clearly the easiest as the PHR simply exports everything to the media and the other one imports from same

b) Sharing – In this case the patient has the one PHR export to the HIE or NHIN share all the data in document form. The second PHR can thus import from the HIE or NHIN.

c) Point-to-Point – In this case we don’t have an HIE or NHIN infrastructure to communicate and don’t have removable media.

-- One solution is for the patient to mediate through downloading and uploading. But this doesn’t involve infrastructural interoperability, just documents.

-- So the outstanding issue is to determine how one PHR would communicate to another PHR. Kathleen (Microsoft) offered that this is not a problem today as the PHR vendors all have agreements on how to do this. But I suspect we will be looking at this.

There are many groups that have a stake in this issue that Consumer Perspective will need to coordinate across.

Provider Registry: There is also much talk about a Provider Registry. This seems to be highly overloaded and seems to mean different things to different people. We discussed and understand it to be focused on the kinds of registry attributes that a Patient could utilize including access to the human-provider demographics as well as the organization-provider services offered. We made it clear that they should keep out of scope the types of interoperability connection information such as those used to attach a web-service endpoint (IP address, Authentication credentials, WSDL).

Patient Care Devices

Continua is well on the path to deliver their specification that will eventually allow HITSP to expand their work from a small set of devices to the much larger set of devices that are available over-the-shelf. I have been working with this group to help them understand the IHE security profiles and HITSP constructs. There is a desire to support very low power end-user devices and under this concern they want to move to more modern standards, as today’s solution is based on HL7 v2 messages. Right now they are trying to move the transport from HL7 MLLP/TLS/TCP to Web-Services/HTTP/TLS/TCP. There does not seem to be interest in moving from the HL7 v2 message to a more XML friendly message encoding form. This results in an HL7 v2 message delivered using Web-Services. This is not desirable to most of the community, so I continue to help Continua.

Capabilities and Service Collaborations

We worked with the group that is taking IS107 and building independent documents for each Capability. We walked through the list of capabilities looking for Service Collaboration opportunities as well as potential cleanup on Capabilities. Possibly new Service Collaborations are TP49/89, T24, and TP50. In all of these cases it is not clear if a Service Collaboration is the best approach, but they clearly need some work.

CAP135 and TP50 is a hard case to address as there are non-controlled systems involved as forms-fillers, and their use-cases don’t always include PHI.

CAP130 needs some kind of transport.

CAP 138 and CAP142 do not fit the qualifications of a capability. They are NOT a binding of transport and content. They are just transports that can be used for many different purposes.

I voiced a concern about the liberal use of Anonymization and Pseudonymization across the Capabilities. We need to get this back under control, and specifically called out only where we have analyzed the use-case and specified the constructs.

SPI needs to also look at the cross-walk table that is in IS107 where we indicated how security and privacy constructs were applied to the capabilities. There seems to be some misunderstanding of the purpose and how it was filled out.

Common Data Transport

This item was initially developed when the NHINs were having trouble getting all parties to use the same web-services versions. They have since moved to using the specification found in IHE ITI Appendix V. SPI leadership have asked that this extension be evaluated for it’s current business need and priority.

The group continued to analyze the current specifications according to the parameters found in the common data transport specification. There was only a few gaps in ‘reliable messaging’, the need for subscribe/notification (DSUB), and potential for a service directory.

Possibility that we might update the Tier-2 criteria to favor web-services based transports. Also possible that we might provide more information on the categorization of our constructs. I took on an action item to update our master construct spreadsheet with columns for: Topology, WS/REST/HL7v2/Other/NA, and Internal/HIE/NHIN/Media/other/NA.

Infrastructure

TP22/T23 – there is concern that HITSP has constrained the assigning-authority for patient identifiers to be an OID. HITSP did this to move the healthcare community along down a path where the assigning authority can be assured that it will be federatable. There is concern about this approach. We will either need to remove the constraint, or explain the constraint better. I suspect we will be keeping the constraint. This came up again this week as there is a group in HITSP that is gathering all the HITSP specified constraints and as a result they will be modifying TP22/T23 with the constraint identifier.

HITSP Consumer Preferences Tiger Team, SPI and Consumer Perspective Technical Committee members

Please find below and attached the call for participation for subject matter experts to join the HITSP Consumer Preferences Tiger Team. We are pleased to launch this new and exciting work activity. Please feel free to share this announcement with your colleagues.

Also as an update, in order to address the possible perception of bias that having two co-chairs from the same organization may introduce, the Consumer Preferences Tiger Team has changed its co-chair leadership. Moving forward Walter Suarez MD and Mureen Allen MD will be the co-chairs of that Tiger Team. Scott Robertson PharmD will continue to serve as a key advisor for that effort, but not in a co-chair position. We appreciate the commitment that these individuals bring to the Tiger Team leadership.

Call for Participation

Healthcare Information Technology Standards Panel

HITSP Consumer Preferences Tiger Team

The HITSP Tiger Teams and Technical Committees will soon begin to address the standards harmonization process for Consumer Preferences. HITSP is seeking to add subject matter experts to assist with this task.

Requirements for participation:

Your organization registers to be or is a member of HITSP. Your area of expertise can be in any of the following areas:

• Overall, standards for classifying and categorizing a wide range of consumer preferences related to privacy, security, care delivery and associated service needs
• Privacy and security standards for categorizing and coding consumer privacy preferences
• Privacy and security standards for controlling access to health information
• Standards for identifying/selecting specific consumer preferences including advance directives, DNR, proxies, surrogates, family member access, and others
• Standards for consumer preferences related to care or associated service needs, including communication needs (appointment reminders, lab results, others), conform measures, and others

The Process:

• HITSP is establishing a Consumer Preferences Tiger Team, which will operate under the joint guidance and direction of the HITSP Security, Privacy and Infrastructure Technical Committee and the HITSP Consumer Perspective Technical Committee. Co-chairs of the Tiger Team are Walter Suarez, MD and Mureen Allen MD.
• The Consumer Preferences Tiger Team will meet periodically via conference calls and F2F meetings to perform all the HITSP tasks related to the harmonization and interoperability standards review and selection to address the needs identified in the ONC Consumer Preference Requirements Document.
• The Consumer Preferences Tiger Team will:
  • Participate, review and comment on the ONC Requirements Document development, as appropriate
  • Develop a HITSP requirements analysis and standards selection document (or equivalent)
  • Identify, evaluate and select recommended harmonized, interoperable standards, including reuse of existing standards using HITSP Tier 2 criteria
  • Identify gaps and develop a roadmap process to address those gaps
  • Develop a HITSP interoperability specification, Capabilities, Service Collaborations, or any other appropriate HITSP harmonization construct to address the information exchange interoperability requirements.
• The Consumer Preferences Tiger Team will develop a more detailed Statement of Work, work plan and timeline, consistent with the overall ONC timeline set for this topic.

Meeting Logistics:

Typically HITSP will conduct a standing weekly conference call with web collaboration. The workload may necessitate additional conference calls. Additionally, there will also be one “Face-to-Face” meeting planned in conjunction with HITSP Tiger Team and Technical Committee activities during the remainder of 2009.

To Volunteer:

If you would like to volunteer to participate in this groundbreaking activity of the HITSP Tiger Team and Technical Committees please contact Allyn Clemons, HIMSS/HITSP Standards Harmonization Coordinator at aclemons@himss.org.

For more information please contact: Johnathan Coleman, Facilitator:

For background information regarding recent postings, meeting activities, and new member participation go to the HITSP web site at www.hitsp.org