Thursday, February 12, 2015

Is it really possible to anonymize data?

De-Identification is a Process, and one that can be done right or WRONG!

The argument 'for' or 'against' use of de-identification is a Red Herring. What the arguments are actually about is the point that a Process can be done badly. There should be no doubt that any Process can be done badly. Even a simple process like filling a glass of water can be done badly, even resulting in human harm.

The big misunderstanding is that De-Identification is an absolute. It is not, it is a Process used to lower 'risk' of re-identification. As a process it can be done badly. As a domain of 'risk' it can't achieve zero-risk, except to end up at the null-set. 

The standards in this space are clear about this risk factor. It is absolutists that insist on viewing de-identification as an absolute, that are causing the argument. This oversimplification is just as alarmist.

As Yogi Berra is said to say: "In theory, there is no difference between theory and practice. But, in practice, there is."  The Practice of applying de-identification has occasional failures, like all 'risk' domains. No one hears about the  times when de-identification is done successfully.All the failures are held up to the light and used to show that the solution fails.

This doesn't mean I am an absolutist that De-Identification is the solution. My perspective is that it is a "Tool". As all tools and processes; they must be used properly.

UPDATED
-----------------
It was pointed out to me, by the awesome Gila Pyke, that I failed to remind the reader that De-Identification is just ONE tool in a mature risk management process. As a risk management tool, and as stated above, the risk will not be brought to zero; as such the resulting data-set might still require protection. It is true that too often one presumes that a data-set that has been de-identified can be globally published. This is true if that was the target of the risk management, and that the risk to re-identification has truly been reduced to the level necessary for global publication. This is one of the misunderstandings that also results in the outlined failures. This is also a fundamental misunderstanding, failing, of the HIPAA de-identification clause.

De-Identification, Anonymization, Pseudonymization

Friday, January 30, 2015

MHD Connectathon Results

IHE Connectathon did informal testing of  Mobile access to Health Documents (aka #MHD - #XDS on #FHIR.We had 9 different implementations testing at the Connectathon. : Qvera, Caradigm, Relay Health, CareEvolution, CRG Medical, Allscripts, EMC, ONC – Dragon, and an individual effort.
 
MHD has a wide variety of deployment models, leveraging the simplicity of HTTP REST and the data model and interaction model defined in FHIR.  One use of MHD is as a front API to XDS, but the profile can also be used for point-to-point PUSH (similar to XDR), or access to a Community (like XCA), or just as a simplified API to an EHR or a Direct HISP.
Among this august group they succeeded to cross-test in 25 different pathways. Which might sound large or small depending on how you do the math, but I will assure you this is just shy of all possible combinations of the Actors implemented.

There was a much larger use of XML than JSON. All publication side were done using XML.

Most gratifying for me was that we were able to point the Document Source and Document Consumer implementations at the Publically Available FHIR servers. Using Grahame’s server and Ewout’s server. This was a fantastic proof that the IHE profile is truly a profile of FHIR, and not a deviation or special case. IHE still has some work to make this formal, in the eyes of HL7, but we now have the joint workgroup to help make this happen.

Overall the group identified a small number of open issues that will be fed into the Public Comment. Most of these are typos, most of them leftover from the first revision of MHD. Each of these we discussed how to resolve. The biggest issue on how to handle the Minimal Metadata vs Full Metadata, where we will leave it as is for now, but after HL7 FHIR DSTU2 we will pursue creation of two formal profiles to identify the differences.

The conclusion is that the MHD profile, once the issues are resolved, should move to Trial Implementation. Everyone understands that this is based on HL7 FHIR DSTU1; which means we will need to adjust again this summer when DSTU2 gets finalized.

This conclusion was so definitive that the MHD testers have been invited to join the HIMSS Interoperability Showcase, as participants within the normal workflows. AND the next IHE Connectathon in Luxemburg will be testing MHD more formally.

For more on mHealth

Wednesday, January 28, 2015

TLS (not SSL) Connectathon trials and tribulations

IHE Connectathon this year had a major disruption caused by TLS/SSL. In hindsight this was very predictable, but those that were feeling the pain were not those that understood what was going on.

The problem is that platforms (Operating Systems, Web Servers, Application Servers) have decided to forbid the use of SSL, as it contains too may vulnerabilities and has too many successful attacks against it. Successful attacks with scary names like "POODLE". This simple policy, forced by the platforms, has caused a large audience at IHE Connectathon to grind to a halt.

The solution is to go back to the IHE-ATNA profile that long time ago mandated the use of TLS 1; so Connectathon should never have allowed SSL anyway.

The short term solution is to recognize this problem, and get back to testing healthcare specific things.

The Following is the Notice written up last night:

There have been problems with the NIST XDS tools regarding the use of TLS. This note documents the issues and describes the changes to testing.

The ATNA profile requires the use of TLS v1 for protecting message exchange between systems. In the past we have seen TLS on-the-wire negotiations where one party requests TLS V1 and the other party requests SSL V3 and the connection is established at the SSL V3 level. This has been accepted in the past but it has been poorly understood. We now understand the following details.
  • In general this is controlled mostly by implementation platform and not vendor/tool code.
  • On Windows platforms, older versions allow the back off to SSL V3 and the newest absolutely requires TLS V1. I am not a Windows developer so I cannot point to specific versions based on my knowledge.
  • For Java based systems it is the JDK/JRE version that matters. Java 6 (1.6) will only negotiate to SSL V3. Java 7 (1.7) is able to negotiate TLS v1.
So what is important when dealing with our tools is to understand what Java version is being used in which tool on the test floor.
  • The Internet Public Registry and the three copies here in Cleveland (RED/GREEN/BLUE) all are running on Java 6.
  • Toolkit for Connectathon is running on Java 6
The immediate goal is to have vendors and monitors stop having to deal with this problem and get back to productive testing. So,
Vendors and monitors: any test that cannot easily be validated via TLS (TLS selection in toolkit) should be validated without TLS. Do not spend any more time dealing with TLS issues unless it relates directly to the interaction between two vendor systems!

This is not a statement of 'security is not important', it is a statement that we know how to secure the communications, so lets get back to the healthcare specific stuff. Much like my statement on FHIR and secuirty

Sunday, January 18, 2015

FHIR Security: Do (Not) Worry

I have been asked quite often to explain how to secure FHIR. I have two different answers, depending on what you are trying to do. These two different answers are driving confusion so I need to explain them.
  1. Don’t worry about security, It is simply a use of the existing Security layers built into HTTP.
  2. Worry about Privacy and Security first thing in your design, bolting it on later will not work well and will cause issues.
These two answers seem very confused, but let me explain the context of them. They should not be taken as absolutes, meaning sometimes you do need to worry about security and sometimes you don’t. They are actually very related. The basics of Security for FHIR are written up on the FHIR Specification.

Don’t worry about security

The first answer is the one I give to those in HL7 that are working on developing FHIR, or just getting their feet wet learning FHIR.

Developing FHIR Resource definition:

The committee members developing FHIR need to focus on developing well thought-out Resource Definitions. So I assure them that there is already security design built into the fundamental general-purpose standards that we are basing FHIR on. That we have a level of confidence that they can go ahead and design their Resources ignorant of how security and privacy will be enforced.

Resources should be ‘just right’ sized. Not too big.

There are exceptions for committee members that are developing FHIR. One exception that I am trying to get more recognition for is related to the size of Resources. Not really size, but in the number of elements included in the Resource definition. The security models that we are thinking about for protecting FHIR work best when they can make a YES/NO decision on a whole Resource content. If they have to hide some of the elements in a Resource, then you end up with a far more complex solution. It can be done, but not easily. And when things get hard, they generally don’t get implemented or get implemented wrong. So I recommend that anytime a Resource is getting too big, it should be evaluated on if there are mixed sensitivity.

Note that 'too big' is a general statement. For example the "Family History", which is really not big at all, but is full of things that all are likely to need different types of protection. I would rather see this broken up into a bunch of resources so that each family member in your family history is documented in an independent Resource, so that Privacy can be more easily enforced.

Prototypes and Learning

Those just learning FHIR also need similar assurances. In fact I am comforted that this is the group that tends to question my statements about not worrying about security. These people get started using FHIR, using HTTP to an open test-server. No security at all. No HTTPS, no User Authentication, no Access Control, no evidence that Privacy Consents will be honored. I am glad that these people start to really worry, they should. But they also need assurance that it is okay to learn FHIR on a test server that has no security. They however soon become part of the camp that needs to hear the Second answer.

Disturbing is that these people clearly haven't looked for the FHIR Security Page.

Privacy and Security by Design

Those who are writing applications that are going to use FHIR really need a totally different mindset. They must focus first on how Privacy will be respected, and how Security will be protected. This is the mantra of the “Privacy by Design” efforts.

Basics of FHIR Security

The basics of FHIR Security are documented on the FHIR Security page. This page will get improved over time. It includes ‘motherhood and apple pie’ of HTTP RESTful security. It however doesn’t include much detail for the implementer. So, how does one execute on this “Privacy and Security by Design” directive? The first answer is look at your programming toolkit and application platform documentation. It likely has instructions on how to turn on HTTPS, and forbid access to your server hosted Resources. Follow those instructions, there is nothing special for healthcare.

User Authentication (AuthN)

User Authentication is a bit more complex, but start again with your programming toolkit and application platform documentation. I would recommend that you look to supporting Federated Identity Management. This is an approach that treats the User Authentication step as a ‘Service’. That is, your application doesn’t get involved in the act of authenticating the user. Your application, through your web-server / application-server, force a user to be authenticated by a sub-set of ‘trusted third party identity providers’. Yes, you need to manage the list of ‘identity providers’ that you trust. This management is within your web platform, but you likely need to expose the configuration to someone, who is authorized as the administrator.

In this way, your application will redirect the browser session or application session over to a web user interface hosted by one of the ‘trusted third party identity providers’. This is where the user would authenticate, using whatever technology that ‘identity provider’ supports. This means you are not involved in the decision on how the user gets authenticated, but this is why you want to be careful about the management of the list of ‘trusted third parties’; as you really need to be able to ‘trust’ them. The advantage for you is that you never need to know their password, nore even that a password is what is used. The ‘trusted third party identity provider’ can be using very fancy biometrics, smart-cards, anything…

The result of this is that you receive back from this ‘trusted third party’ a ‘claim’. This claim is often encoded using SAML, if the identity provider is a business organization or government body. This claim is often encoded using “OAuth 2.0” and “OpenID Connect”, if the identity provider is a consumer focused Internet service provider (e.g. Facebook, Google, LinkedIn, Twitter, etc). Remember YOU get to determine who you put ‘trust’ in; so don’t worry that you will be forced to trust ‘Facebook’.

With HTTP REST, the use of OAuth is going to be easier; so quickest path is through OAuth. Note that there are bridging services that can convert a SAML claim into an OAuth claim.
  • There is efforts in the past to profile this: IHE IUA and Bluebutton++.
  • There are efforts now starting to do a better job: HEART and such.

User Authentication in an Application

The above is really about the overall architecture of user authentication in a web environment, and how to apply this to a web-server. If you however are developing a web application that will use a FHIR Server as the backend, then you need to look into your programming platform and application platform for how to support “OAuth 2,0”; also look for “OpenID Connect”. 
In this case you will need to handle a special OAuth 'token', that indicates that the user has authorized your application (the Authorization part of OAuth).

User Authorization (AuthZ)

This is a much more complex topic than I want to discuss in this article. The main problem is highlighted on the FHIR Security page. The solution is often a bunch of layers of Access Control decision and enforcement.

There will be many more blog articles, updates to FHIR, and new profiles that appear this year.

Conclusion

So, the key is to understand if you are just learning FHIR, developing FHIR Resource definitions, or developing an software that will be used on patient data. Sometimes you should be confident that security is not something you should worry about; sometimes it should be the first thing to worry about. In all cases, it is important to understand why you are not worried or deeply worried.

Resources mHealth Security


Wednesday, January 14, 2015

Applying CyberSecurity Standards to Medical Device Design

Medical Devices do indeed need to be designed to protect against CyberSecurity. This has been stated by the FDA for almost a decade. The reality is that many Medical Device vendors, and many  Mobile Health Application developers really don't know how to fully cover CyberSecurity. So it is really nice to see that NIST and a broader audience involved with the "National CyberSecurity Center of Excellence": have provided a document that shows HOW to apply the NIST CyberSecurity standards to Medical Devices.

Health IT: Medical Devices


The National Cybersecurity Center of Excellence (NCCoE), in collaboration with the Technological Leadership Institute at the University of Minnesota, has devised a project to improve the security of wireless medical infusion pumps. This is the first of a series of use cases focused on medical device security.
The draft use case is available for public comments through February 20, 2015.
USE CASE: WIRELESS MEDICAL INFUSION PUMPS (PDF)

Here is a sample of some of the cool information in the document. Here is  fragment of a table that points you at NIST SP 800-53 specific items:

Wednesday, January 7, 2015

FYI: Update on the creation of Joint workgroup between #IHE and #HL7 including #FHIR topics

The creation of the Joint workgroup between IHE and HL7 is progressing. I am very hopeful that this will be accepted and become a formal workgroup within HL7. See the message below.
 
 ------------------------------------------------------------------------------
IHE Domain Co-chairs,

Many of you are aware that we have been working on creation of a work group in HL7 to facilitate coordination required between IHE committees and HL7 work groups. This message is to update you on the status of that effort and to invite your participation in formation of the work group and its ongoing activities.

A proposal for creation of the Healthcare Standards Integration Work Group has been submitted to the Steering Divisions of HL7. It will be reviewed for approval during the Steering Divisions meeting at 7pm, Monday, Jan. 19 at the HL7 Plenary and Work Group Meetings in San Antonio. A copy of the proposal is attached. Anyone who is able to attend the Steering Divisions meeting as an observer is encouraged to do so.

The work group will hold sessions on Thursday afternoon (Q3 and Q4), Jan. 22. The agenda outlines will be 1) to address remaining committee administrative and governance issues, 2) to develop a plan for operationalizing the group by setting meeting schedules and general work plans and 3) to review the list of open issues and set priorities, task assignments and schedules for addressing them. Again, all interested parties are encouraged to attend. Please convey that invitation to any potentially interested parties on your domain committees. A detailed agenda and meeting location will be forwarded shortly.

Finally, we invite your ongoing participation in identifying and addressing issues that require communication and collaboration between your committees and HL7 work groups with overlapping interests. We have started a wiki page (http://wiki.ihe.net/index.php?title=IHE-HL7_Joint_Workgroup#Work_Items) that begins to list these issues. We invite you to add to the list and to flesh our details of the issues already listed there. If we can identify lead parties on IHE domain committees to work on each of the items listed, it will help the work proceed productively.

Please reply with any suggestions, comments, questions, etc.

Best,
Chris Carr

Monday, January 5, 2015

IHE MHD and DSG now open for Public Comment

Both profiles are updates of previous versions. I will soon write about the details. Here is a summary:
IHE IT Infrastructure Technical Framework Supplements Published.
Is this email not displaying correctly?
View it in your browser.

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment

The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for public comment in the period from January 5 through February 6, 2015:
  • Cross-Community Document Reliable Interchanges (XCDR) 
  • Cross-Enterprise Document Workflow Extension for Cross-Community Environment
  • Document Digital Signature (DSG)
  • Mobile Access to Health Documents (MHD)
The documents are available for download at http://www.ihe.net/Public_Comment/. Comments submitted by February 6, 2015 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation versions of the supplements. Comments can be submitted at http://ihe.net/ITI_Public_Comments/.