Technology Trends in Healthcare IT

Summer is a good time to assess the existing trends and project which ones will continue through the year. I would define the technology trends I see in Healthcare IT as “Mobile”, “Privacy”, and “Services”.

Within them I do include specific technologies that are today’s buzzwords.

• Mobile – portable Data, portable Applications, portable Profiles, portable Devices, portable Sensors, portable Sessions, portable Security-- mobile as a user experience – mHealth is the most used buzzword so far this year. 
• Developing Enabling Technology: REST, JSON, HTML5, WADO, FHIR
• Existing Enabling Technologies: CDA, HTML, PDF, IHE-XDM
• Privacy – Respect the individual, be Transparent with the individual, and Security of systems and data – privacy as a user experience – The Patient and Provider MUST trust that what they offer to Health IT will be maintained properly. Trust is easy to get the first time, very quick to lose, and almost impossible to recover from.
• Developing Enabling Technology: oAuth, Consent Rules, De-Identification
• Existing Enabling Technologies: Basic Consent, Audit Logs(ATNA), PKI, SAML, XACML, Encryption
• Services – Not necessarily as formal as SOA, but much like the SOA religion. Mostly services that enable HIE. Anything that could be a reusable service is "designed as" a service. Any service can be a local or remote or cloud hosted service. I think the concept of “Services” is more descriptive than “Cloud”, although to get best buzzword points "Cloud" mostly gets the point. 
• Developing Enabling Technology: REST, JSON, SimpleXML, oAuth
• Existing Enabling Technologies: XCA/XCPD, XDS, PIX/PDQ, Directory

Note that these three technology areas are overlapping and highly related. However they are on different tracks and require different development and maturing.

As always I have an indexed list of my articles by topic areas

Redaction fail - Lessons healthcare must learn from

Interesting article on the problem with redaction, possibly exacerbated by human redaction. The article focuses on Military/Political based classification systems and the de-classification system we have. This system is based on humans that are trained experts. Their training, expertise, and guidelines tend to be highly variable. The article even includes explicit examples where two different people came to exactly the opposite conclusions on redaction, thus their combination gave everything.

The best part of the article is the paragraph:

"The idea that you can slot all knowledge into neat little categories that perfectly overlap with our security concerns is already a problematic one, as Peter Galison has argued. Galison’s argument is that security classification systems assume that knowledge is “atomic,” which is to say, comes in discrete bundles that can be disconnected from other knowledge (read “atomic” like “atomic theory” and not “atomic bomb”). The study of knowledge (either from first principles or historically) shows exactly the opposite— knowledge is constituted by sending out lots of little tendrils to other bits of knowledge, and knowledge of the natural world is necessarily interconnected. If you know a little bit about one thing you often know a little bit about everything similar to it."

De-Identification focuses on the removal of identifiers. This is hard enough, but nowhere near as hard as removing intelligence. That is not to say that healthcare has it easy, we do have sensitive health topics that are just as hard to handle. We should just not equate government redaction systems with the systems we need in healthcare to support clinical trials, clinical research, public health reporting, etc.

See also: De-Identification

• De-Identification - Data Chemistry
• Guidance Regarding Methods for De-identification of Health Information
• The Emperor has no clothes - De-Identification and User Provisioning
• De-Identification is highly contextual
• Redaction and Clinical Documentation

Internet User Authorization: why and where

User identity, authentication, and the user’s authorization given to applications; are a hot topic in security and privacy. The latest darling on the block is oAuth, championed by Google, Facebook, Twitter, LinkedIn, Salesforce.com, and Amazon.

This technology has just been profiled by IHE in the Internet User Authorization (IUA) profile that is out for public comment right now. http://www.ihe.net/Technical_Framework/public_comment.cfm#IT

oAuth is good for:

This technology specification has some advantages over others, but mostly in the space of:

1. Internet facing web services
2. Web services available to the public
3. Applications that are installed on mobile devices using internet facing web services
4. Functionality that interact with social networking
5. Functionality that can utilize identity and authentication managed elsewhere
6. Web Browser or RESTful API

This does not mean that it is good for everything, nor that it is limited to these functionality. It is just good to understand where a technology fits best.

Both SAML and oAuth act rather similarly from a browser experience, although oAuth has a functionality that doesn't exist in SAML. I oAuth the authenticated user can endorse an application (mobile app or web-service) as having the authority of the user. That is the user can delegate their identity to an application, that can use that identity transparently in the background. This also comes with the ability of the user to revoke that authority. It is this functionality that differentiates oAuth.

SAML is still a better solution for:

1. Backend communications that need a user identity
2. Business-to-Business communications
3. Federation of Identity
4. Federation of Access Control decision points
5. When the Identity Provider is Active Directory – Active Directory Federation Services
6. SOAP web-services, although supported on Web Browser and RESTful API

It is more likely that an organization will host a Active Directory for their users and enable Active Directory Federation Services exposing SAML Assertions; than they will use oAuth. This might be a maturity thing that changes over time, or it might be a long term reality. SAML Assertions are generally seen as more business focused, where oAuth is more consumer focused.

I have covered this a bit more in What User Authentication to use?

IUA --> SAML + oAuth

The IHE IUA profile profiled a join between these two worlds. An Option in the IUA profile utilizes an IETF draft rfc that defines how to carry SAML Assertions within the oAuth infrastructure. Thus bringing together the benefits of both, although bringing along baggage that might be seen as the combination of the negatives.

The IUA profile is truly just an IHE profile. It only strives to profile the underlying standard to meet Heathcare needs. It is NOT a tutorial on how to use oAuth, or how to write your code, or how to configure a directory. These are all well documented today, and/or are opportunities for others to fill in. The IHE profile is simply taking the needs of healthcare and showing how to utilize oAuth to achieve that.

It recognizes the default oAuth use of bearer tokens, which are really only useful in the case where the oAuth token issuer is the same organization as the web resource being approached. This is because a bearer token is opaque and thus means the web resource gets no information about the user, the access control decision must be made totally at the oAuth token issuing. This is an okay solution, but didn't really enable much in the way of Interoperability. So IHE acknowledged this mode and allows it, but doesn't really utilize it in the profile.

The IUA profile primarily used JWT token types. These token types are readable, as they are encoded using JSON attribute encoding. The IUA profile shows how to carry the typical healthcare specific information within this package: User Role, Purpose Of Use, etc.

And Lastly the IUA profile added an option that uses an IETF draft for carrying a SAML assertion. In the case of IUA, this SAML assertion is profiled by XUA. Thus this is an encapsulation of a SAML assertion inside oAuth : IUA(XUA). 

Public comment is open until July 3rd. Please get your comments in.

References:

• IHE efforts in RESTful security
• IHE-IUA - Internet User Authentication for HTTP profiles
• Identity Proofing and Authentication -- Patient vs Provider
• Level setting on Level of Assurance
• Advanced Access Controls to support sensitive health topics – a simple solution to sensitive health. 
• Direct addresses- Trusted vs Trustable
• Identity - - Proofing
• The Emperor has no clothes - De-Identification and User Provisioning
• What User Authentication to use?
• IHE - Privacy and Security Profiles - Enterprise User Authentication
• IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
• Healthcare use of Identity Federation
• Federated ID is not a universal ID
• Separation of Layers: Security Error Codes
• Authentication and Level of Assurance