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.


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.

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 ( 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.

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 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

Thursday, January 1, 2015

This year will be better

I am not big into predictions, but I do want to hold myself to last years predictions. Lucky for me I didn't predict much.
  1. Less Blog posts in 2013 and 2014 -- Nailed it: I was close to 100 articles per year prior to 2013. In 2013 I only posted 56 articles, and 2014 only posted 28. Much of this is because I am busy doing more work inside of GE, in a good way. But it also seems I am getting less questions to answer, or those that I am getting I find an existing article that answers it. I am still willing to answer questions posted to my "Ask me a Question".
  2. Bluebutton+ will seem right, yet confuse. -- Nailed it again: It seems that those who loved Bluebutton+ decided to switch to riding the FHIR horse. And now they are going to cause yet-another year delay by merging the confusion of Bluebutton+ with the chaos of FHIR. I am not saying that FHIR is bad, just that we have about 4 more years of maturity before it will be useful for simple stuff - Like "Download", or "Transfer". I am also not implying that the Argonaut project is bad, it was necessary to get very needed and worthy funding to some FHIR projects. Throughout this confusion, I will continue on my quest to make reasonable Profiles of simple standards, yes mostly focused on FHIR.
  3. HIE Patient Identity.-- I'm going to say I failed in my prediction. There was progress, much like I predicted. But I really expected us to have a much better consensus on how to solve this one. I think I simply underestimated the 'business' priorities to keep it unsolved.
  4. Profiles.-- I think I will take partial success. There is still positive movement toward the need for Profiles, however very little. Mostly indistinguishable from last year, just  slightly better. What has helped toward progress is the efforts in FHIR to create a Profile mechanism at the technical level. These efforts have not really succeeded, and will change radically this year, but they do show the benefit of the concept of a Profile.
My Focus
My focus this year will continue to be on the internal projects. I am at the core of the GE Healthcare business implementation of the GE corporate "Software" initiative, known as Predix. Most of the GE 'standards geeks' have been pulled into this, well actually most of us pushed our way into it. Keith and I worked very hard to, not only get inside of this effort, but to convince them that it must be fundamentally based on #FHIR. We succeeded, in a big way and are now in leadership positions. One outcome GE intends, is to instrument and improve efficiency in healthcare, much like Predix is being used in the other industries - aka the "Industrial Internet". This same concept will also directly help our customers meet Meaningful Use. I can't really speak much more about it, but I am excited about it.

The bad part is that I will spend less time doing the external standards work I so enjoy, and will be spending more of my time in San Ramon, Budapest, and Bangalore. The first 8 weeks of the year, I am on-the-road for 6 of them.

I am still optimistic, the alternative is just not acceptable in healthcare. I will likely blog about as much as I did in 2014, possibly more. As to other predictions, I will just let my 2014 stand in for 2015. I will be spending my time on making progress. We must and will move forward.


Wednesday, December 17, 2014

Digital Signatures on FHIR

Within the FHIR community there has been many disconnected discussion on Digital Signatures. These discussions have made it formally an action item for the Security WG to come up with a better guidance than exists today. This discussion has also come up with a listing of the problems that FHIR presents, an incomplete listing. This discussion has come up with a few solutions, but none that work for everything.

Document Signatures

With Document Signatures, we have a completely self-describing blob that we hash, and that hash is included in a Digital Signature block. This signature block can be managed in at least three distinct ways:

  • Detached – Signature block is managed as an independent document from the document(s) it signs Possibly using a Document Sharing system like XDS which also has ‘association’ linkages that can identify the signature relationship between signed document and the signature document.
  • Enveloping – Signature block is managed as a document that contains the document that it signs. The signed document is ‘enveloped’ inside of the signature block. This ‘new’ object can be managed and communicated in many ways. The signed document and the signature are bound together through this containment. However to access the signed document, one must be able to take the signature envelop off of the document.
  • Enveloped – The Signature block is inserted inside of the signed document. This means the signed document must have a defined place to hold the signature block, and the signature must exclude this place. The signed document and signature are bound together through this form of containment. However to access the signature block, for validating the signature, one must have the ability to extract the signature prior to sending it to a standards based signature verification algorithm.
I will say more about this in the future, as IHE has just approved a new version of the IHE Digital Signature (DSG) profile for “Public Comment”.

FHIR are Resources

FHIR could use the above mechanisms, but the dynamic nature of FHIR causes many problems.

FHIR Resources can and will be made into Documents

First the good news: If one were to create a “Document” using FHIR, rather than CDA, it would (should/shall) have the same characteristics of a “Document” and thus be self-describing blob.

Resource fixup breaks Signatures

But most of the time with FHIR, the expectation is that the Document or any set of Resources will be decomposed and managed independently. Thus we don’t have a “Document” for long, we have a set of Resources that are ‘fixed up’ by the server. We have a set of Resources that are moved around, and thus more ‘fixup’ happens. The first problem that FHIR presents is this concept of ‘fixup’. What I mean by ‘fixup’ is this: Any FHIR Resource that contains pointers, either Reference or URI or Attachment or other; these pointers might need to be adjusted by any system that is going to persist or further process. An example is that sometimes a bundle will be created that contains all the necessary Reference resources, all pointed to through relative-URI. The recipient will break these resources out of the Bundle and as it stores them it will create a absolute-URI and thus adjust the uses of the previous relative-URI to the new absolute-URI. This is a specific example of ‘fixup’. There are others elements of a Resource that might need to be adjusted by a recipient. These ‘fixup’ are expected, and normal. They should not be changing the meaning originally intended. A digital-signature would see this as a change and thus flag the change as breaking the signature. If the change is expected and normal; then the signature needs to ignore these changes. However the signer does also need to make sure that the ‘fixup’ was done accurately.

An interesting, and simple, solution to one deployment scenario goes like this: For a client that wants to create a signature across a Resource that it is going to publish, it could manage the ‘fixup’ problem using the following method: From the perspective of a FHIR client

  1. The client creates a new instance of some resource(X) 
  2. The client Posts X onto server Y
  3. The HTTP Response indicate successfully created, returning the URL to X’
  4. The client retrieves that instance X’ from the server Y resulting in a local copy of X’
  5. The client confirms that the essence of what is intended to be recorded has been recorded. Thus allowing the server to do things like fixing up references.
  6. The client then calculates the signature S across that X’
  7. The client then creates a Provenance resource P pointing at X’, with the signature calculated S.
  8. The client could then retrieve the Provenance instance P’ and validate X’ and included S’ with the current X”

This does not address all problems. It does address one of the ‘fixup’ problems, the first server need to ‘fixup’ the resource. It doesn’t address cases where that server further needs to forward a copy of the Resource to a system that can’t access the server, as that introduces a new fixup problem. But it is an elegant solution to one of the problems we are presented with. And this just might be the highest important problem to solve.

I think the above interaction would work for a Bundle of Resources too. Just more involved.

Transforms break Signatures

Next problem that FHIR brings in is the ease with which it transforms a Resource from JSON to XML and back. There is new work going on in HL7 to now bring in a third form of RDF. And many applications will use JAVA, and thus only see the resource in the JAVA form. There is great effort in FHIR, enforced by the publication tooling, that these translations are lossless. But from a digital-signature perspective they are all different. Digital-signatures operate on the binary level, not the semantic level. When one actor signs some Resource, they can’t know (or dictate) that all users of that Resource use the same transform. The publisher might use XML, the reader might only be able to read using RDF. 

A proposed solution for this is to force the Signer to include in the Signature a signature block for all possible transforms. The drawback of this is that the Signer likely can't validate each of those transforms as valid.

Another proposed solution is for the Verifier -- the one using content and wanting to get proof that the content has been signed -- be forced to be able to use ALL transforms, thus verify the transform that was signed. There would be trust-in-the-server that it transforms all other versions reliability.

More issues and solutions to come

Surely there will be more. I encourage comments on my blog, but I also encourage participation in FHIR efforts. The FHIR efforts are being cataloged on the HL7 Wiki at 

Friday, November 28, 2014

Fwd: Call for Participation; #MHD - #XDS on #FHIR

The MHD profile, which is most quickly described as XDS on FHIR, is getting revised this winter. I have been working with a small group of IHE members to align the original MHD concept with the Resources that I worked with Grahame to model in FHIR, soon to be controlled by a joint IHE-HL7 workgroup. Since this profile is not following the normal IHE lifecycle, it is not ready for formal testing at IHE-Connectathon. But we want to do some testing at IHE-Connectathon, so we are going to use what IHE calls "New Directions". The new MHD pairs nicely with PDQm and IUA.

Note I removed the webinar details from this post, but they are available upon request.

As you are no doubt aware, there is a great deal of industry buzz around the application of RESTful technologies and FHIR Resources to IHE profiles. MHD is a profile that is considered a prime candidate, and according to the interest received to date, is likely to garner a high level of adoption.

We are contacting you as a potential participant in an exciting opportunity to collaborate on the testing & development of the new Mobile Access to Health Documents (MHD) IHE profile, utilizing HL7's emerging FHIR® standard. "XDS on FHIR" is one of several innovation projects comprising the New Directions program during the IHE North American Connectathon being held in Cleveland OH, January 26-30, 2015.

Be part of a handful of selected vendors that realize the potential of being an active contributor and an early adopter. Here is your opportunity to get the jump on your competitors and get in the game!

You are invited to join program sponsors IHE USA, HIMSS, NIST and HealtheWay in a webinar that will explain the "MHD on FHIR" opportunity in January, and what is required in order for your company to participate. We have prepared a slide deck for the webinar, which is attached for your advance perusal.

Please join us for the webinar on Tuesday, December 02, 2014 @ 12:00 Noon – 1:00 PM, CST (Central Standard Time). This webinar will be recorded .
The plan at a glance:
  • Testing of MHD on FHIR in New Directions will take place for 2 days only, on Wed January 28 10am-5pm and Thurs Jan 29 9am-noon during the IHE North American Connectathon week of January 26-30, 2015. The event will be held at the Cleveland Convention Center and HIMSS Innovation Center, 1 St. Clair Ave NE, Cleveland OH 44114.
  • Participants will be testing submission of documents using FHIR technology, as defined for IHE's MHD profile. Participants will be testing with a tool developed by NIST as well as with each other peer-to-peer.
  • A candidate for participation is a developer for a company that has successfully tested an XDS Document Registry, Document Repository, and/or Document Source actor at a North American or European Connectathon within the past 3 years. We would expect the participant to bring an implementation of an MHD Source to make a Document Submission, and/or an MHD Recipient to receive a Document Submission.
  • Prior to face-to-face testing on Jan 28-29, participants will be expected to participate in periodic calls to stay apprised of developments in the MHD specification and to test with the NIST tools as they are released.