Data Segmentation - now I know where the term comes from

During the kick off meeting for the new S&I Framework project on "Data Segmentation" I found out why this concept of Patient Privacy Policy and Controls keeps being called "Data Segmentation". The key is a project funded by HHS a year ago that resulted in a white paper on September 29, 2010 titled "DATA SEGMENTATION IN ELECTRONIC HEALTH INFORMATION EXCHANGE: POLICY CONSIDERATIONS AND ANALYSIS" (Sorry for the shouting, they actually used all uppercase). This white paper was authored and presented at the S&I Framework "Data Segmentation" kickoff meeting by Melissa M. Goldstein, JD. Melissa did a fantastic job of explaining the content, and I now understand why the scope is what it is. I simply wish that the simplification of the subject would have been from later in the title "Policy Considerations".

Note that these resources are on the HHS site on Privacy and Security

The executive summary indicates

This discussion raises the issue of data segmentation, which we define for the purposes of
this paper as the process of sequestering from capture, access or view certain data
elements that are perceived by a legal entity, institution, organization, or individual as
being undesirable to share.  This whitepaper explores key components of data
segmentation, circumstances for its use, associated benefits and challenges, various
applied approaches, and the current legal environment shaping these endeavors.  

Data segmentation in the health care context can support granularity of choice with
respect to the following:

• What specific data are eligible for exchange (from individual data elements to defined categories of data, such as all behavioral health records); 
• Who has access to the information (from individual providers to other health care entities); 
• Under what circumstances access is granted (e.g., emergency access, treatment, etc.); and  
• For what period of time access is granted (e.g., unlimited, one-time access, etc.)  

The executive summary concludes

As such, it will be important for policy makers to consider various approaches to moving
not only the discussion, but also the meaningful realization of data segmentation, 
forward.  Data segmentation efforts to date have explored a variety of approaches that
show some early, but limited, success.  To accelerate this forward momentum, we would
suggest, among other pursuits, the following:
 

• Build a Bridge to Greater Autonomy: Rely on policy levers that will move us closer to the goal of supporting individual, subjective preferences for information management;  

• Provide Direct Financial and Other Support to Stimulate Change: Consider various means of supporting  the development of segmentation-enabling processes and technologies; and  

•  Generate Evidence: Given the significance of the transformation from paper to electronic means of data capture and sharing, establish and execute on a set of updated research priorities.   

We support the idea of casting a wide net in search of appropriate means of providing
patients more granular control over the exchange and use of their identifiable health
information, and point to the efforts underway in other countries as evidence that this is a
worthwhile endeavor.  While still a challenge, data segmentation holds promise for
accomplishing the ultimate goal of accommodating the needs and desires of the multiple
stakeholders engaged in the electronic exchange of health information.  

The report is very extensive.

IEC 80001 - Security Technical Report presentation

I presented the soon to be published Security Technical Report IEC 80001-2-2 "Guidance for the disclosure and communication of medical device security needs, risks and controls". There is an assumption that the audience has an understanding of the basics of IEC 80001-1 "Application of Risk Management for IT-Networks Incorporating Medical Devices". I have been involved in the creation of this set of specifications from the beginning and provided some background here on my blog.

This webinar was well attended for a security webinar with close to 150 participants. My blog has also been very actively referenced since then. So I can tell there is strong interest. Unfortunately the audio recording of the webinar failed, so the best I can do is offer up the slides. The full slide deck is available on Google Documents

ONC Announcement of E-Consent Trial Project Contract Award

This is a really great project by ONC to address the soft side of HealthIT and HIE. That being the interface with the human patient, specific here to educating and getting the consumers preferences.

C.2. PURPOSE
The Office of the Chief Privacy Officer (OCPO) within ONC proposes to award a contract to

a. Use innovative ways to
i. Educate and inform individuals of their option to give individual choice (e.g., automate informed consent process, patient-centered decision making process) in a clinical setting to share their health information electronically; and
ii. Ensure that individuals are knowledgeable participants in decisions about the sharing their electronic health information in a clinical environment.
b. Explore and evaluate ways of electronically obtaining and recording meaningful and informed choice from individuals in a clinical setting, regarding sharing their electronic health information.  

The project is designed to help identify some innovative best practices in ensuring that any choices patients make with respect to sharing their health information are indeed, meaningful: i.e., patients are adequately educated about issues that are important to them, and that they understand the choices they make as well as the consequences of those choices.  

I looked deeper in the document and was happy to see recognition of the existing works of IHE.

My biggest concern is that there doesn't seem to be enough guidance to the contractors to (a) look globally for how this is handled in other environments, and (b) to gather a set of reasonable privacy policies and their variability. In the case of (a) there are other environments that are ahead of USA on presenting Healthcare Information Exchanges, and thus there is some lead there on how they interact with the patients. 

In the case of (b) I worry that this project will focus only on what the patient wants to control, and will forget that the healthcare provider organization has the right to not accept all the controls that the patient desires. Typically this is due to real patient safety or provider safety concerns, sometimes it is because the provider organization knows they simply can't protect the data in that way. Sometimes it is because the provider organization does indeed use the data in secondary ways that do conflict with the patients preferences. This specific issue took much time to discuss in HITSP. It turned out to be a core part of TP30, that recognized that there is a need to record patient preferences that are not actionable directly but are there for a healthcare providing organization to utilize when they formulate the policy choices that they offer to the patient. It is only the binding of a patients accepted preferences to the providing organization that creates an actionable privacy policy that the organization is held to. (note I use organization here inclusive of Health Information exchange Organizations). 

I look forward to any opportunity to get involved with this project.

        From: ONC Health IT [mailto:onchealthit.@service.govdelivery.com] 

        Sent: Monday, October 03, 2011 9:01 AM
        Subject: Announcement of E-Consent Trial Project Contract Award

Announcement of E-Consent Trial Project Contract Award ONC's Office of the Chief Privacy Officer recently awarded a contract to APP Design, Inc. to find an efficient, effective, and innovative way to help patients better understand their choices regarding whether and when their health care provider can share their health information electronically, including sharing it with a health information exchange organization. The project team will design, develop, and pilot innovative ways to electronically implement existing patient choice policies, while improving business processes for health care providers. To learn more about the E-Consent Trial project, please see the Statement of Work. ONC's formal launch of the E-Consent Trial Project will be in October. Questions? Contact Us STAY CONNECTED: SUBSCRIBER SERVICES: Manage Preferences | Unsubscribe | Help This service is provided to you by The Office of the National Coordinator for Health Information Technology.

IHE IT Infrastructure Cross-Enterprise Workflow Supplement ready for Trial Implementation

This is a going to be a highly re-used fundamental profile. As it is published by the ITI committee it doesn’t do much, but when other committees put it together with a clinical workflow it becomes a powerful tool to drive workflows across enterprise boundaries. For example, enabling the kind of workflow that Keith discusses in A Patient's Viewpoint of Provider Workflow

 IHE Community, IHE IT Infrastructure Technical Framework supplement published for Trial Implementation 
The IHE IT Infrastructure Technical Committee has published the following Technical Framework supplement as of October 3, 2011:·         Cross-Enterprise Document Workflow (XDW)
Note:  This supplement will be tested for the first time at the IHE Europe Connectathon in May 2012
 
The document is available for download at http://www.ihe.net/Technical_Framework. Comments on this document can be submitted at http://www.ihe.net/iti/iticomments.cfm. We use this email distribution channel for periodic updates on IHE activities.  If you wish to respond to this message or to be unsubscribed from this distribution list, please send a message to secretary@ihe.net. 

a New S&I Initiative: esMD Call for Participation

The S&I Framework is kicking off yet another project. I exhausted with the number of projects that I need to participate in today, and I only participate in a few (Keith is our lead this year). This new project seems like 3 totally different use-cases rolled into one. So it is actually three new initiatives. I can’t quite understand what use-case 2 and 3 are. They are so broadly written that they could be almost anything. But use-case 1 is one I can help with.

Digital Signatures are a topic I have covered multiple times. I don’t know of anything new being asked for, so I will just point at the existing work on the topic. This work includes use-cases, standards assessment, vocabulary identification, and profiling of standards.

• IHE - Privacy and Security Profiles - Document Digital Signature
• Signing CDA Documents

HITSP covered this space and created C26 - Nonrepudiation of Origin

Note, the technology is easy; the hard part is getting over the administrative costs, infrastructure, and processes that are necessary to support Digital Signatures. In order to have digital signatures of any value one must have a strong certificate management infrastructure in place. One that issues Certificates to individuals, who are very careful with them. Certificate management infrastructure that can hold certificates for 100 years. This is expensive. This is the reason why few actually roll out Digital Signatures, and this is why IHE has not seen enough adoption of DSG to move it to final text. 

The other hidden complexity is timestamps, one must be able to trust the timestamp inside a digital signature. This is not the same thing as having synchronized time. This has to do with protections against malicious 'back dating' of signatures. There are technology solutions, usually implemented as a timestamp-service. This timestamp-service does nothing but apply a Digital-Signature of it's own. By agreement everyone trusts the timestamp applied by the timestamp-service. More technology, more certificate management and more trust.

I'm not going to be at the Face-to-Face, so let me know how it goes.

From: S&I Framework Admin [mailto:admin@siframework.org]
Sent: Friday, September 30, 2011 4:18 PM
Cc: Mohammed.Elias1@cms.hhs.gov; melanie.combs-dyer@cms.hhs.gov; Mera.Choi@hhs.gov
Subject: Announcing a New S&I Initiative: esMD Call for Participation Current S&I Framework Members,
ONC is pleased to announce the launch of a new S&I Framework Initiative – Electronic Submission of Medical Documentation (esMD).

You are invited to attend the esMD KickOff Meeting and subsequent discussions at the S&I Face to Face on Oct 18-19.  The esMD initiative will require inputs from several other S&I Initiatives, such as Provider Directories and TOC/CDA, so we encourage and request your participation and input to this important initiative.  For those of you who have not yet registered for the F2F Meeting, you can do so on this link: http://wiki.siframework.org/October+F2F+Meeting
Note: Registration for the Face to Face meeting has been extended through Oct 7th.  The Hyatt has also extended their discounted hotel room rates through Oct 7th. 
The Kick-off call for the esMD Initiative will occur October 18, 2011 at 9:30am EDT.  Please stay tuned for additional agenda details for the esMD sessions on Oct 18-19th, or monitor the esMD wikispace for updates: http://wiki.siframework.org/esMD+Workgroup.  On this page, you can also sign up as a Committed Member or Other Interested Party for the esMD Initiative.

Please note the attached esMD DRAFT charter. Below is a summary of the Initiative and expected Use Cases.

esMD Initiative: The Electronic Submission of Medical Documentation (esMD) pilot intends to give providers a new mechanism for submitting medical documentation to Medicare Review Contractors. The S&I Framework esMD Initiative will focus on Interoperability and Nationwide Standards needed to support esMD requirements. The objective for the initiative is to setup workgroups to develop the use cases listed below:
Use Case 1: Define technical issues and relevant standards associated with author level digital signatures and develop a list of recommended Standards and associated Reference Implementation Guide(s)
Use Case 2: Define Standards for Structured Data submission capability using esMD
Use Case 3: Define standards for electronic communication with Providers to request for Medical Documentation (Structured Outbound)
Based on current discussions among members of the HIT Standards Committee and feedback from members of the community, the following core outcomes have been identified for the esMD Initiative:

• Identify gaps in CDA Structured Document to support Progress Notes and Orders, and other documents as required for Medicare Review and similar activities

• Leverage work of Provider Directories, Certificate Interoperability, Transitions of Care, and Data Segmentation Initiatives as they apply to esMD

• Define technical issues and relevant standards associated with Author Level Digital Signatures

• Identify and address business process and infrastructure issues associated with Author Level Digital Signatures

• Identify and forward policy issues, if any, to appropriate policy bodies

• Develop a list of recommended Standards, potentially including new work by SDOs, to be incorporated in a Reference Implementation for esMD

Thank you,Melanie Combs-Dyer, esMD Initiative Coordinator;Mohammad ‘Sam’ Elias, esMD Project Manager;and the S&I Framework Support Team

Securing RESTful services

What is meant by RESTful? Ok, that is an old one; given that there is no such standard as REST. My understanding, RESTful is simply the philosophy of using HTTP built in command set PUT/GET/POST/DELETE (aka Create, Read, Update, Delete – or by others RLUS - Read, Locate, and Update Service). Thus the transport, encoding and command set are fixed. The theory is that you as a programmer then just focus on the special encoding above this command set, for example what is your query parameters and what is the result to look like. Thus freeing you from worrying about transport or command set, and ... security.

As far as securing RESTful services; IHE-ATNA already says how to do that – Mutually Authenticated TLS. I talk at length about this in Securing mHealth - the role of IHE profiles, specifically about the operational reality of using ATNA. IHE ATNA takes care of many risks, and does provide system authentication. Sometimes knowing the requesting system, is enough to know that you can trust that system would only ask for information that it knows the user is authorized to get. Surely using ATNA the service can trust that the client will include the user and purpose in the audit message recorded at the client side, because ATNA requires security audit logging.

What I want to address is deeper than simple HTTPS -- or even full Mutually-Authenticated-TLS. I want to address user and patient based access controls to very sensitive health information. Today RESTful is used mostly to access non-sensitive information. It might be important information, or simply might be maps, earthquakes, weather, etc. Most uses of RESTful are not trying to access as sensitive of information as healthcare information, certainly not information that can have privacy policies (Consents) that rule so finely over the data. Many are asking for RESTful to be used to access fully identified clinical information, and some are even asking that it be used to create or change this clinical information - such as the IHE Profile Proposal for a RESTful interface to XDS. These are the issues that I am trying to figure out how to equally secure RESTful vs SOAP.

In SOAP we have well defined ways to communicate the security context. IHE profiled the use of SAML assertion (XUA): who the user is, what their roles are, what they intend to use the data for, and any authorizations they hold. I cover this in the Bloginar on XUA. With SOAP based web-services this all comes along in the security layer built into SOAP, the WS-Security layer. RESTful doesn't have this layer, or at least not this well defined.

As to providing user identity, there is some hope, but no clear hope. Yes there is a Kerberos for HTTP (documented in EUA). Kerberos has issues when being used beyond a constrained environment, so it is not as suitable for HIE use.

Yes you can use SAML over HTTP. This is not documented in IHE as it is not implemented consistently in toolkits --- but this is used today for browser interactions. For example inside of GE all user authentication uses SAML identities mostly through the SAML "Browser SSO Profile", thus making it easy to work with external parties such as travel reservations. This method doesn't work great for a system-to-system API.  The good news here is that the OASIS committee that handles SAML is working on this very problem now. 

Most RESTful people want to use OpenID now days; which is a good choice for last-mile API; It just doesn't support the necessary user context attributes (role, purpose of use, authentication type) that access to sensitive information really needs. For this the OpenID community adds OAuth, which is fast developing but not mature. OAuth 2.0 looks really good in this camp.

The worst choice for user identity is to use an inline HTML form. This might work for interacting with a human, but as a programming interface it is very hard to work with. This solution locks you into one method of authentication, and one centrally managed user database. Thus proliferating the post-it note problem.

I hope to uncover the 'right' way to specify a RESTful service API for accessing highly sensitive healthcare information. I am not sure I can provide as good a security layer as is provided today with SOAP, but I am hopeful and open to suggestion. IHE will try to figure out all the possibilities, and all the operational environments. Much of the documentation I find is specific to one platform or the other.

I suspect that we will use something like OpenID + OAuth on the RESTful side, use WS-Trust to convert these tokens in the proxy service, so that on the backend we can use SAML to interact with the XDS or XCA backbone. I think this is a reasonable solution. I do expect that a RESTful API will be deployed for a specific use. It might be for the use by a large healthcare organization, or by a PHR vendor, or by a HIE; but the point is that this is an API into XDS/XCA that is hosted for a very specific purpose. Thus the very specirfic purpose can scope the security context well enough to make it easy on the Browser side, while satisfying the needs on the backend.

We could ignore the problem, but then what would "App" developers do? Guess at what they need to have implemented? Even a bad single choice is better than no choice. Even if we tell the App developers to include HTTP Basic Authentication, we will be sure that they can at least do that. Thus only hoping that they have thought beyond the minimal necessary to be compliant with the profile.

Please help. Please provide your choice. Please provide your environmental problem. The more information we have at the start, the better choices can be made.

Document Encryption

IHE has a new supplement “Document Encryption (DEN)” out for Trial Implementation that explores all the possible ways that encryption could be applied to Documents. This supplement went to great extents to define a large set of different use-cases, each with their own concerns regarding protecting documents. As such it also explored all the existing profiles capabilities to meet these use-cases, and thus identified a few gaps.

The following is a table (Table Q-2. Use cases for existing and new IHE profiles with encryption) found in the supplement (reformatted slightly to fit in the blog). For details on each of the use-cases, please see the document. In this table each use-case is shown in a row, and each solution from IHE is available in a column. Where the profile is designed to directly address the use-case an “X” appears, where the solution partially supports the use-case a “(x)” appears.

Use case	new Doc Enc	new XDM Media Enc optn	ATNA (TLS)	ATNA (WS-Sec)	XDM Email optn	PDI optn(CMS)
Point-to-point network exchange between machines	(x)		X	(x)
Network exchange between machines in different trust domains	(x)		X	(x)
Online exchange of documents where partially trusted intermediaries are necessary	X			X
Exchange of medical documents using person-to-person Email	(x)				X
Media data (DICOM) exchange between healthcare enterprises using physical media	(x)	(x)				X
Exchange health records using media	X	X				(x)
Media to media transfer	X	(x)
File clerk import	X	X
Unanticipated work-flows	X	(x)
Clinical trial	X	X
Multiple recipients of secure document	X	X
Sharing with receivers only partially known a priori, a group or a role	X	X				(x)
Partial encrypted XDM submission set	X

As such there are some use-cases that are not really fully satisfied by the existing profiles, so the supplement goes on to define how to (a) Encrypt an XDM media, and (b) Encrypt a Document alone independent of any transport.

As such it comes up with a nice table that explains when one of the IHE Profiled solutions is most useful. The following is Table Q-1, IHE Encryption Solution Overview

Profile	When to use?
IHE ATNA (point-to-point using TLS)	·  environment uses networking transactions (e.g., XDS/XDR); or ·  to be protected data concerns (representation of) XDS/XDR transactions and packages; and ·  confidentiality need applies between internet hosts (point-to-point)
IHE ATNA (end-to-end using WS-Security)	·  environment uses web-services (SOAP); and ·  to be protected data concerns (representation of) transactions and packages (e.g., XDS/XDR); and ·  (partial) confidentiality need applies to intermediaries between end-points (end-to-end); and ·  where encryption between hosts is not sufficient
IHE XDM Email Option (using S/MIME)	·  environment uses XDM with exchanges based on Email (SMTP); and ·  to be protected data concerns (representation of) XDM media content; and ·  confidentiality need extends from the sender up to the final recipient’s Email system (end-to-end)
IHE Document Encryption	·  environment uses any means for data exchange, in particular non-XD* means; or ·  to be protected data concerns (representation of) arbitrary data (documents), in particular non-XD* packages; or ·  confidentiality need applies between arbitrary end-points (end-to-end), in particular where intermediaries or unanticipated workflows are involved
IHE XDM Media Encryption option	·  environment uses XDM; and ·  to be protected data concerns (representation of) XDM media content (content and metadata) on physical media; and ·  confidentiality need matches path from creator to receiver (importer) of media
IHE PDI privacy option (using CMS)	·  environment uses PDI; and ·  to be protected data concerns (representation of) DICOM data on media; and ·  confidentiality need matches path from creator to receiver (importer) of media

Implementing the Document Encryption (DEN) profile should be very easy, as the profile is leveraging a commonly implemented standard. The standard used by the DEN profile is the same standard that the IETF profiled for use by e-Mail uses for S/MIME. The DEN profile clearly is not S/MIME, but rather a more general purpose use of this underlying standard. 

To help the implementer, there is a page on the IHE wiki that points to toolkits and implementation notes. On this page an implementer can find different solutions that they can simply leverage. There are examples of files that have been encrypted so that you can test that your system can decrypt them. There is very little need to implement the details when there are so many current implementations available. 

IHE expects that when others implement this profile, that they can use this information. As a wiki, the expectation is that as new information is discovered the community (that’s you) will update the page. Don’t wait for some ‘authority’ to fix something that is wrong on these wiki pages. Feel free to update them as necessary (common wiki behavior is expected).