SAML SSO with Healthcare Context Proposal (Short)

Transcription

1 SAML SSO with Healthcare Context Proposal (Short) 1. Proposed Work Item: Health Context Sharing via SAML Proposal Editors: Alex DeJong, Siemens Healthcare Work item Editors: Jim McInnis, Siemens Healthcare Alex DeJong, Siemens Healthcare Date: 23-Sep-14 Version: v01.00 Domain: IT Infrastructure 2. The Problem UI interoperability provides the ability to launch one application from another. This includes the ability to authenticate the user to the launched application and, in many cases, passing context, such as a patient identifier. Sometimes this functionality is referred to as SSO between applications. HL7 CCOW has defined context switching which many products use for establishing user context (and SSO). HL7 CCOW based solutions tend to require a dedicated CCOW manager product and support in each of the products participating in the context. Implementations tend to be costly given the broad scope of CCOW. Many commercial products have implemented a simpler mechanism to allow secure launch of their products without an explicit username and password. These proprietary mechanisms typically use a combination of plain-text arguments for context and a hash (e.g. MD5) to protect the integrity of some or all of the arguments. A salted hash using a shared secret, username, password and/or date/time component, are used as the authentication mechanism. There is currently no standard mechanism defined across the healthcare industry to securely pass user and other healthcare context which results in incompatible solutions for healthcare customers requiring custom adapters to integrate products.

2 SAML has become widely used across industries to assert user identity and has a built-in mechanism to support additional attributions on the assertion. SAML leverages digital certificates as its security mechanism and has already defined many elements relevant to this use-case (e.g. issuer, conditions for expiration, audience restrictions)., There is currently a lack of guidance in the healthcare industry for how vendors can consistently implement SAML to achieve UI interoperability in healthcare workflows. This profile defines the use of SAML for UI interoperability. Because SAML is a broad set of specifications that can be used in many contexts, a profile that constrains the underlying SAML standards and simplifies the adoption across healthcare products is necessary. By providing a definition of healthcare context parameters typical in many healthcare workflows, this profile helps to ensure out-of-the-box SSO compatibility between compliant SAML SPs and IdPs as implemented by different organizations. Benefits for products using this profile: Leverages SAML industry standard and middleware software support for this standard. Provides guidance for use of the SAML SSO within healthcare. Provides mechanisms for expressing healthcare domain attributes (e.g. patient information, image accession and study information). 3. Key Use Cases A scenario in a healthcare organization could look like this: A physician walks up to a workstation on the floor and logs into the hospital s web based Clinical Information System (CIS). After selecting a patient in the CIS and reviewing the patient s information, the physician wants to view the X-ray image, which can be accessed via a link in the CIS. The CIS passes patient and a DICOM image study identifier as the context. The DICOM image is natively rendered within a Picture Communication and Archive System (PACS) application. Similarly, the physician might want to review information available in a regional Health Information Exchange (HIE). Patient context, such as MRN, gender, date of birth, etc. would be passed to the browser-based HIE portal to load information available in the HIE for the given patient. Many other variants are possible with many different types of systems. 4. Standards & Systems To ensure a secure flow, this proposal advocates use of the SAML SSO Web Browser Profile for the interactions as described in the previous use cases. The CIS is the SAML Identity Provider (IdP) while the image viewer and HIE application are SAML Service Providers (SPs). When selecting the link, the web browser uses the SAML protocols to securely sign on by generating and passing a SAML assertion and using an HTTP post to the PACS viewer. The PACS viewer validates the token and uses the context to show the correct image. The following documents are reference standards on which the profile is built:

3 SAML 2.0 Core Specification: SAML 2.0 Bindings Specification: os.pdf SAML 2.0 Profiles: Health Level 7 (HL7) Clinical Context Object Working group (CCOW): CCOW Subject Specification 1.5 Additional references that might be useful and could be referenced in the profile: SAML 2.0 Technical Overview: 5. Discussion Siemens Healthcare has authored a SAML interoperability profile to ensure SSO interoperability across its Healthcare products. It has successfully implemented this profile with various vendors and consulting teams to realize seamless end-user interoperability in healthcare products while providing a secure login and passing clinical context such as patient and other relevant information as part of the scenario. The profile is built on the following SAML standards: - SAML Web Browser SSO Profile - SAML Post Binding - SAML attribute names for common healthcare context parameters The context attribute naming convention is compliant with the Health Level 7 (HL7) Clinical Context Object Working group (CCOW) naming as outlined in the CCOW Subject Specification 1.5. In addition, the following rules apply to allow for easy interoperability: All attribute names are case insensitive (i.e. Patient.Id.MRN is the same as patient.id.mrn). If SP required attributes are not provided by the IdP, the SP shall report an error. Attributes provided by the IdP but not recognized by the SP shall be ignored by the SP. o Note: It is thus not possible to use attributes that restrict access, e.g., indications that a user may view a subset of information only, as older applications might ignore them and open up for broader access than allowed. Product attributes must use the defined attribute names as defined in the table shown Name Cardinality Description User.Co.Membership 0..n Membership represents the user's group memberships. User group membership values should consider use of URI or LDAP notation. For example: ldap://companydomain/cn=physicians,ou=groups,o U=Site-A,DC=DC1,DC=company =com, or WinNT://CompanyDomain/someone.important.

4 Patient.Id.MPI 0..1 Patient s medical record number, per PID-2. Master Patient Index (MPI) or Patient Number (PN). MPI can be used to uniquely identify a patient across an enterprise. Patient.Id.MRN 0..1 Patient s medical record (MR) number, per HL7 PID-2. Patient.Id.MRN.AssigningAuth ority 0..1 Patient s medical record number's location, per HL7 PID- 2.4 Assigning Authority, Hierarchic Designator (HD) datatype. The recommended content includes both the authority name and ISO identifier. The value of the attribute would be set to the assigning authority of the Patient.Id.MRN. This is the mechanism to specify the assigning authority (or location) of a patient with a fixed attribute name. Examples: Encounter.Id.AccountNumber 0..1 Patient Account number (AN). Encounter.Id.VisitNumber 0..1 Patient Visit Number (VN). Patient.Co.PatientName 0..1 Patient.Co.Sex 0..1 Patient.Co.DateTimeOfBirth 0..1 DICOMStudy.Id.InstanceUID 0..1 DICOMSeries.Id.InstanceUID 0..1 DICOMStudy.Co.Accession_N umber 0..1 Patient.Id.MRN.AssigningAuthority=Westche ster_clinic indicates that the MRN is assigned for the Westchester location. Patient.Id.MRN.AssigningAuthority=Westche ster_clinic^ ^iso indicates that the MRN is assigned for the Westchester_Clinic that has an identifier assigned by ISO. Patient s legal name, per HL7 PID-5. Examples: Lastname^Firstname^Middle^Suffix^Prefix, Marchant^Olin^^^^ Patient s gender, per HL7 PID-8. Patient s Date and time of birth, per HL7 PID-7. The value of the DICOMStudy.Id.InstanceUID item corresponds to either: The DICOM Study Instance UID (0020,000D) attribute of a composite DICOM object The DICOM SOP Instance UID (0008,0018) attribute of a normalized DICOM object of the Detached Study Management SOP Class. Can only be used with a valid MRN or MPI. The DICOM series subject is an identity subject that represents a specific DICOM series object for a specific patient. Can only be used with a valid MRN or MPI. The AccessionNumber is an identification which appears at DICOM Study level, and this is generally used along with patient.id for image call-up of specific studies by radiology information system (RIS) or thirdparty applications. This is the identifier that makes it

5 Session.Co.InactivityTimeOut 0..1 Session.Co.LogoffURL 0..1 possible for information systems to link orders with images. Session inactivity time out in seconds Uniform Resource Locator (URL) which can be provided by the SAML IdP to inform the SAML SP where to redirect the user after the user logged off from the SAML SP in a SAML IdP initiated SSO flow. A SAML SP is not required to use the provided URL even when provided by the SAML IdP. All attributes are considered optional in the profile. Each product defines which specific attributes are required and products can choose to support additional attributes, not listed in the table. The set shown in the table above are commonly used in many UI interoperability use cases.