Wednesday, December 16, 2009

Federated ID is not a universal ID

I run into people who miss-understand Federated ID as requiring everyone to change to a universally issued user identity with universally issued roles. This is absolutely not true. Let me lay some ground work then bring them together.

For the most part I don’t think that user identity is important in cross-enterprise transactions like EHR requests into an HIE. Not because they are a bad idea, or that they are not good security; but rather because most of the usecases that we are looking at, and the interactions that are being executed are system-to-system or organization-to-organization. In this mode the two systems (or organizations) need to trust that the other system has done the appropriate pre-conditions and will do the appropriate post-conditions. This is Policy and Procedure: Don’t let a system connect that you don’t trust has the appropriate governance. What this means is that the client machine has done appropriate user authentication, authorization, and is otherwise a secure system. The communications is highly authenticated (TLS) on both client and server. The result returned back to the client will be properly handled, exposed only to authorized individuals, and the maintain audit logs of all accesses from that point forward. If we add a user identity to this transaction, it is mostly for a little bit better audit log on the service side.

The other side of this is that even if a user identity was provided it would be about the user that is right-now connecting. If this is a request from a clinical system (e.g. EHR) the result will be stored and others on the clinical system will gain access. So although the initial connection could be access controlled, the other future accesses within the EHR must be trusted to do the right thing. I worry that people see the user assertion and end up with a false sense that all accesses are singular accesses back to the original system. Thus there is a false sense of security, rather than a healthy-suspicion that doesn’t let the whole-system connect at all until the downstream workflows are checked out too. There are other transactional complexities that simply adding an assertion doesn’t help. But there are also applications other than an EHR that can operate on single-read-only-use (more on this later in this post)..

If we look at an EHR today, it has user authentication and access controls that have been built up over time to meet the requirements of being an EHR. The user authentication likely is highly flexible to support some rather strange workflows. One of the strange workflows is the exam room, where an administrative person walks the patient to an exam room and sets up the exam-room-terminal with the right patient then ‘locks the screen’. Next the nurse comes in to take complaints and vitals logs in, enters them, and logs out. Next the doctor comes in for the exam, again logs in to enter data and logs out. Each of these people are authenticating, but the workflow on the desktop is all about the patient. These authentication methods and authorization methods are sufficient to protect the PHI that is maintained inside that EHR. It is possible that an organization has gone to an enterprise class authentication system like Active Directory or more generically Kerberos or LDAP, but this is not required.

Lets look at interacting with an HIE or other organization that requires a SAML assertion. A SAML assertion is issued by an Identity Provider that supports SAML. This Identity Provider is configured to understand specific targets of the SAML assertions (known in SAML terms as an ‘audience’). The configuration will include mapping tables that indicate that when creating a SAML assertion for use within a specific HIE that some list of attributes need to be added to the assertion. One likely attribute is the HIE-role values which is assigned based on the Role or attributes within the Identity Provider. Thus if I am known as a Physician in my local LDAP Directory, but the HIE wants the role to come from a different valueSet where my role within the HIE would be “Care Giver” then it is up to the Identity Provider to do this mapping. This is a common thing for Identity Providers to do, as role vocabulary is not stable within any organization (not just healthcare) nor is it likely to be stable inside the HIE. What is important to recognize is that the SAML assertion is issued by an Identity Provider that does this mapping. The native user directory does not need to have the HIE-roles. When this SAML assertion is received by the Service Provider it is validated which checks that it was issued by an identity provider that is on the trusted-identity-provider-list. This allows the Service Provider to support many different Identity Providers, likely one for each clinic and hospital connecting to the HIE. Given that all of those identity providers have normalized their roles to the HIE-role vocabulary it is clear what permissions the user should have in the context of this transaction in the HIE.

I now bring together these two ideas. Given that the EHR has a mature user authentication and authorization system that is likely highly customized to the clinical workflows it is not likely that system can be replaced. The good news is that this is a mature system. So, one first step is to have the EHR be the Identity Provider. It is simply XML with a digital signature. Yes, the HIE better do proper checkout of this Identity Provider, but after this happens the HIE would trust it. I wrote up in a white paper for IHE on this topic in 2005: “XUA Implementation Demo 2005 Guide.doc” .

This may work long-term, but likely enterprises will choose to go to an enterprise class user-authentication system to gain all of the advantages of single-sign-on and much quicker user provisioning and de-provisioning. But once this transition is done, then that enterprise class user-authentication system should be specified as a cross-enterprise class user-authentication system. The WS-Trust protocol would then be used to get SAML assertions issued.

Now is when I must add the exception to the rule. The above discussion was around clinical access to an HIE by an EHR. I think this is the most important HIE access and the one that brings the biggest benefit while being most simple. I think the same can be said about a PHR, although I have less sympathy for a PHR as they are generally less constrained on workflows (exam room) and are also rather newly designed. So a PHR could more easily provide user assertions, still I am not sure why that assertion is specifically useful. But there are other parties that are being connected to the HIE. I think these other parties may be more likely candidates for getting benefit from requiring assertions….

Monday, December 14, 2009

Observation on REST vs SOAP

Last week was especially frustrating. The technical topic of the week was REST vs SOAP, but what was not obvious to most observers is a frustration that has NOTHING to do with REST vs SOAP. You might be seeing this frustration on the faces, the emails, the voices, and the blogs of those of us who spend a majority of our time participating in OPEN and CONSENSUS processes. We place ourselves on the mercy and critique of others multiple times a day. Everything we do is included in openly published minutes, draft documents, ballots, ballot-comments and such. Our names are well known, our addresses and phone numbers are well known.

Along comes this nameless and faceless "community" that somehow gains power by coming to the party late and simply having an advocate appointed to a high office. These people are not involved in the many years it has taken to develop the standards. These people can not be communicated with. Their ideas are taken without question. We have no idea who they are. Even Vinton Cerf and Aneesh Chopra are names without any way to have a discussion with. I applaud John Halamka, even poking fun at/with him. I applaud John because he is approachable and forward. It is very hard to have the same respect for others that don't participate but simply throw FUD into the process late in the game.

Most of the discussion around REST vs SOAP has been this faceless "community" complaining that the HITSP selected standards for communicating clinical documents (XDS/XDR) is SOAP based. We hear that they want a RESTful equivalent. The first problem is to find a RESTful "standard" or "profile" that has been built in an open and consensus process. This specification is not just going to drop out of thin air. A highly important point is to make sure we have the requirements clearly identified. The Open and Consensus process is good for uncovering all of the requirements and making sure they are satisfied before we start to have hundreds of developers building products and networks based on that specification.

This is very different than what OHT and FHA-CONNECT have done by publishing a RESTful interface to these tools that speak using the HITSP selected standards on the backend. This kind of a RESTful interface is local and doesn't impact anyone outside of the local (which can be large) developers. I would really like to be sure that the existing specification is truly not sufficient before we create-new specifications that we then call parsimonious.

Friday, December 11, 2009

Double Standard?

I find it strange that John Halamka is willing to spend top-dollar for a Gortex suit because it has long term benefits that he sees will payout over time, while in the same blog telling the whole healthcare community that they should settle for a low grade solution even when that solution is known to be deficient in security,  determinism, versioning, reliability, flexibility, etc.

There have been many attacks on XDS/XDR as being overly complex including that they are SOAP based. These have also included questions of if HITSP should offer an alternative transaction that is RESTful.

The requirements that XDS/XDR satisfy are well documented in the IHE Technical Framework. I will highlight a few that are relevant to why the benefits of the SOAP stack are important:
  1. User Authentication supported by HTTP alone is inadequate for healthcare information. WS-Security includes support for many user authentication methods including Federated ID using SAML Assertions.
  2. URL representations of healthcare resources (e.g., Medical Record, Patient Chart, or provider ID, et cetera), can:
    • Expose PHI in web URLs (probably the most common security error made in web-based healthcare apps)
    • Create easily exploitable web pages (another very common security error). 
  3. Formal interface definition language in WSDL.  
  4. Support for end-to-end security while leveraging a flexible WS-Addressing and built in asynchronous support.
Although all of these are enabled by the SOAP stack, they are not mandatory and the minimal stack is profiled for XDS/XDR. The point is that adding the additional support from the SOAP stack is as simple as adding building blocks, where as one would need to code this into the application with a RESTful approach. Further point that is often lost in these discussions is that REST is an architecture, there is no standards that define REST. Where as SOAP is a standards based protocol.

We either clothe Healthcare in a ‘simple’ jumpsuit, or we build a long-term HIE architecture out of strong durable fabric.

Wednesday, December 9, 2009

Current Security and Privacy developments

This is a simple listing of all of the Security and/or Privacy developments underway. I am sure there is something missing, but I find it useful to track the efforts. This is grouped but not in any particular order. Please feel free to comment with updates. Getting access to the working drafts is not always possible given the governance of the controlling organization. I can assist with getting anyone engaged with the work item.
  • Country Specific
  • Profiling Organizations
    • IHE --
      • Update to XUA to add one or more options for attributes to enable Access Control. Potentially using XSPA, as well as experience from NHIN and epSOS.
  • Standards Organizations
    • HL7 --
      • Security TC
        • Security Domain Analysis Model
          • This project is intended to create and ballot a single HL7 Domain Analysis Model (DAM) integrating both security access control and privacy information models.
        • Risk Assessment Framework Cookbook
          • The scope of this project is to create a unified method and process to identify issues, categorize them using a standard and accepted risk framework, bring the risks to the attention of the Security Technical Committee (TC) and use the consulting and oversight of that committee to standardize the much needed solutions and at the same time leverage the limited resources available.
        • Privacy and Authorization Terminology
          • The scope of this project includes incorporation of additional RBAC permission vocabulary (e.g., Healthcare Financial Transactions), Privacy Consents and Constraints. Has passed ballot, now being reconciled.
      • CBCC TC
        • Update V3 Privacy Message
          • CBBC balloted a V3 Privacy message a couple of years ago that resulted in a normative standard; they may update this in the Spring of 2010.
        • Consent Directive CDA Implementation Guide.
          • The project is intended to produce a structured document specification to exchange signed Consent Directives.
        • Composite Privacy Consent Directive R2
          • In addition to the analysis of new requirements, this project will correct any problems detected in the current 'Data Consent R1' standard.
      • Joint work
        • confidentialityCode - clarification of the purpose of this attribute and the purpose of each vocabulary value. Hopefully this will NOT create unnecessary interoperability problems given legacy, IHE, and DICOM use of the same named attribute.
      • SOA - PASS
      • CCOW
        • SAML Assertions as proper user identity subjects
    • DICOM - (follow link for DICOM Standard) or (changes with annual publication)
      • DICOM supplement 95 -- Audit Trail Messages
        • fixes, radiology extensions, and addition of SYSLOG-PROTOCOL family
      • DICOM Supplement 142 -- Clinical Trial De-identification Profiles
      • CP-884 - DNS self-discovery for secure DICOM services
      • CP-892 - Add De-identifying Equipment to Contributing Equipment Sequence
      • CP-895 - Password based encryption for media security
    • ISO - TC 215
      • ISO/PRF TS 21547 Health informatics -- Security requirements for archiving of electronic health records -- Principles
      • ISO/PRF TR 21548 Health informatics -- Security requirements for archiving of electronic health records -- Guidelines
      • ISO/CD 22857 Health informatics -- Guidelines on data protection to facilitate trans-border flows of personal health information
      • ISO/CD 27789 - Health informatics -- Audit trails for electronic health records
        • Started based on RFC3881, but has diverged
    • IEC
      • IEC 80001 -- Risk Management approach to connecting a medical device to a healthcare network, including security risks.
    • OASIS --
  • Other Organizations
    • Joint working group HIMSS & NEMA
      • Next generation of MDS2

Monday, December 7, 2009

RHIO: 100,000 Give Consent

This RHIO is not based on XDS or BPPC, but the fact that they operate with a only an OPT-IN policy seems to validate that this approach should satisfy the 80/20 rule. I think that BPPC can and should be used to enable OPT-IN in an XDS like RHIO (HIE). This is not to say that BPPC is the long term solution, but rather that without a OPT-IN ability we will get nowhere on deploying the Health Internet. BPPC is 'good enough', and is a logical path toward something more advanced. HL7 is already working on that more advanced solution, and it is a logical extension to where BPPC is today.
The Rochester RHIO in New York has announced that more than 100,000 patients have consented to their physicians viewing their health information via the RHIO. Rochester RHIO started a pilot in 2007 with five practices and 27 physicians. Today, it serves more than 1,500 authorized providers including 500 physicians. Data exchanged via the RHIO includes lab reports, radiology images and reports, medication histories, and hospital discharge summaries. By January, the service will include emergency medical treatment data and information on health and human services for senior citizens. More

Wednesday, December 2, 2009

Web-Services RESTful vs SOAP

This isn't exactly Security or Privacy related but has been politically a hot potato that I must participate in because I am co-chair of the Security, Privacy and Infrastructure Workgroup of HITSP. The good news is that HITSP is getting a chance to deal with this formally in response to the "Common Data Transport" work item. This item first came to HITSP back when SOAP was king and no one had even heard of RESTful. Well the winds have changed and now RESTful is king and SOAP is a 'four letter word'. So I penned the following section for HITSP, much of the material does come from Wikipedia, but the text did jive with other resources I used.

3.1 Web Services

A web service is traditionally defined by the W3C as "a software system designed to support interoperable machine-to-machine interaction over a network. In common usage the term refers to clients and servers that communicate over the HyperText Transfer Protocol (HTTP) protocol. Such services tend to fall into one of two camps: SOAP Web Services and RESTful Web Services.

SOAP Web Services use Extensible Markup Language (XML) messages that follow the Simple Object Access Protocol (SOAP) standard and have been popular with traditional enterprise. In such systems, there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a web service.

More recently, REpresentational State Transfer (RESTful) web services have been regaining popularity. RESTful Web Services leverage more completely the HTTP protocol including: negotiations for media types, caching, authentication, and the HTTP methods as the verbs: PUT (replace or update), GET (list or retrieve), POST (create), and DELETE (delete). Unlike SOAP-based web services, there is no "official" standard for RESTful web service. This is because REST is an architecture, unlike SOAP, which is a protocol. Even though REST is not a standard, a RESTful implementation such as the Web can use standards like HTTP, URL, XML, GIF, etc.

Web API is a development in web services (in a movement called Web 2.0) where emphasis has been moving away from Simple Object Access Protocol (SOAP) based services towards more direct Representational State Transfer (REST) style communications. Web APIs allow the combination of multiple web services into new applications known as mashups. When used in the context of web development, web API is typically a defined set of HyperText Transfer Protocol (HTTP) request messages along with a definition of the structure of response messages, usually expressed in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format.

3.1.1 Selecting Web-Services

SOAP Web Services and RESTful Web Services are both very useful tools that have advantages and disadvantages. When defining a concrete implementation of a service it is important to pick the best tool for the specific job. The Common Data Transport Technical Note outlines some of these attributes that a transport may need to have. Not all of these attributes are always needed, so it is important to use the most simple tool that can get the job done.

Where the advantages of SOAP are necessary to meet the transaction requirements then a SOAP Web Service will need to be chosen.

RESTful Web Services
-          Best for Web-Application deployment
-          Leverages Browser for user authentication
-          Synchronous request/response pattern
-          Simple to program
-          Simple to deploy -- publish new URL
-          Secured using TLS, server or mutual authenticated
-          More friendly to mashup
-          Leverages HTTP header negotiations

SOAP Web Services
-          Best for Cross-Organization Interoperability
-          Best support for User Assertions
-          Secured using TLS, server or mutual authenticated
-          Supports end-to-end security with WS-Security
-          Intermediary support
-          Synchronous and Asynchronous
-          Well formed interface definition -- WSDL
-          Support for Reliable Messaging
-          Support for Binary attachments
-          Support for multiple attachments RESTful Web Services

HITSP has selected RESTful Web Services as follows:
  • T18 - View Laboratory Result from a Web Application
  • TP50 - Retrieve Form for Data Capture
  • T66 - Terminology Service
  • T81 - Retrieval of Medical Knowledge
  • TP89 - Sharing Imaging Results (Image retrieve) SOAP Web Services

HITSP has selected SOAP Web Services as follows:
  • TP13 – Manage Sharing of Documents
  • TP21 – Query for Existing Data
  • TP31 – Document Reliable Messaging
  • T63 – Emergency Message Distribution
  • T85 – Administrative Transport to Health Plan