Sign-On projektet. HL7-CCOW Context Management: A National Sign-on Profile



Similar documents
SAML SSO with Healthcare Context

SAML SSO with Healthcare Context Proposal (Short)

Strong authentication of GUI sessions over Dedicated Links. ipmg Workshop on Connectivity 25 May 2012

eid/authentication/digital signatures in Denmark

IHE Radiology Technical Framework Volume 3 (IHE RAD TF-3)

IBM SPSS Collaboration and Deployment Services Version 6 Release 0. Single Sign-On Services Developer's Guide

Enabling Single Signon with IBM Cognos 8 BI MR1 and SAP Enterprise Portal

Guide to Complete EIA SSO (Single Sign-On) Registration. 1. Open your Internet Browser, enter this address, and press Enter

Clinical Mapping (CMAP) Draft for Public Comment

OIO Web SSO Profile V2.0.5

Enabling SSO between Cognos 8 and WebSphere Portal

Guide to building a secure and trusted BYOID environment

Authentication Applications

French Justice Portal. Authentication methods and technologies. Page n 1

Enabling Single-Sign-On between IBM Cognos 8 BI and IBM WebSphere Portal

Enabling Single Signon with IBM Cognos ReportNet and SAP Enterprise Portal

Single Sign-On: Reviewing the Field

SECO Whitepaper. SuisseID Smart Card Logon Configuration Guide. Prepared for SECO. Publish Date Version V1.0

You can also find the conditions at

IHE Eye Care Technical Framework Supplement. Unified Eye Care Workflow Refractive Measurements (U-EYECARE Refractive) Draft for Public Comment

Contextual cloud-based service oriented architecture for clinical workflow

OIOIDWS for Healthcare Token Profile for Authentication Tokens

PROVIDING SINGLE SIGN-ON TO AMAZON EC2 APPLICATIONS FROM AN ON-PREMISES WINDOWS DOMAIN

How To Use Saml 2.0 Single Sign On With Qualysguard

esign FAQ 1. What is the online esign Electronic Signature Service? 2. Where the esign Online Electronic Signature Service can be used?

Revised edition. OIO Web SSO Profile V2.0.9 (also known as OIOSAML 2.0.9) Includes errata and minor clarifications

Chapter 4. Authentication Applications. COSC 490 Network Security Annie Lu 1

Single Sign On Requirements

User Pass-Through Authentication in IBM Cognos 8 (SSO to data sources)

HL7 Customization Guide

Advanced Administration

RSA Secured Implementation Guide for VPN Products

TABLE OF CONTENTS. Vendor Web & e-registration...2. Usage of Digital Signature Certificate...3. What is an etoken?. 4. General FAQ...

Enabling Single-Sign-On on WebSphere Portal in IBM Cognos ReportNet

IHE IT Infrastructure Technical Framework Supplement. XAD-PID Change Management (XPID) Trial Implementation

Device-Centric Authentication and WebCrypto

Illinois Health Information Exchange Client Readiness Technical Assessment Checklist

Revised edition. OIO Web SSO Profile V2.0.8 (also known as OIOSAML 2.0.8) Includes errata and minor clarifications

Implementation Guide SAP NetWeaver Identity Management Identity Provider

Pick Your Identity Bridge

SAP NetWeaver Single Sign-On. Product Management SAP NetWeaver Identity Management & Security June 2011

TIBCO Spotfire Platform IT Brief

Architecture, Implementations, Integrations, and Technical Overview

Appendix 1 EQUALITY IMPACT: SCREENING AND ASSESSMENT FORM

IHE Patient Care Device Technical Framework Supplement. Medical Equipment Management Device Management Communication (MEMDMC) Trial Implementation

Using SAML for Single Sign-On in the SOA Software Platform

HL7 and Service-oriented Architecture (SOA) Ambassador Briefing

All mail administration activities can be carried out using the Domain Management Console.

SEC100 Secure Authentication and Data Transfer with SAP Single Sign-On. Public

Sentinel EMS v7.1 Web Services Guide

This Working Paper provides an introduction to the web services security standards.

OIX IDAP Alpha Project - Technical Findings

Guide for Securing With WISeKey CertifyID Personal Digital Certificate (Personal eid)

Cybersecurity and Secure Authentication with SAP Single Sign-On

Contents. Supported Platforms. Event Viewer. User Identification Using the Domain Controller Security Log. SonicOS

Mashup Sites for SharePoint 2007 Authentication Guide. Version 3.1.1

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies

September 9 11, 2013 Anaheim, California 507 Demystifying Authentication and SSO Options in Business Intelligence

Ameritas Single Sign-On (SSO) and Enterprise SAML Standard. Architectural Implementation, Patterns and Usage Guidelines

ImagePilot. HL7 Conformance Statement. Manufacturer: 1 Sakura-machi, Hino-shi Tokyo , Japan

How To Check If A Pia Is Required For A Defense Education Activity Online Data Management System (Doea)

Fuld Skolerapport for Søhusskolen, i Odense kommune, for skoleår 2013/2014 for klassetrin(ene) 9. med reference Tilsvarende klassetrin i kommunen

Fuld Skolerapport for Hunderupskolen, i Odense kommune, for skoleår 2013/2014 for klassetrin(ene) 7. med reference Tilsvarende klassetrin i kommunen

Software Requirements Specification. Task Management System. for. Prepared by. Version 1.0. Group Name: Pink and Purple. Date:

WEX CREDIT CARD ONLINE ACCESS SET UP

Copyright Pivotal Software Inc, of 10

2016 R2. CPR Integration. Configuration Guide

Courtesy Translation

Den Gode Webservice - Security Analysis

OpenHRE Security Architecture. (DRAFT v0.5)

Information Technology Branch Access Control Technical Standard

Certification Practice Statement

IBM i Version 7.2. Security Single sign-on

OIO SAML Profile for Identity Tokens

API-Security Gateway Dirk Krafzig

Absorb Single Sign-On (SSO) V3.0

University of Pune Examination Department Online form for Examination Manual for Student Registration

WHITE PAPER. Active Directory and the Cloud

Identity Management for Interoperable Health Information Exchanges

A Nemaris Company. Formal Privacy & Security Assessment For Surgimap version and higher

Protecting Juniper SA using Certificate-Based Authentication. Quick Start Guide

DocuSign Single Sign On Implementation Guide Published: March 17, 2016

Enabling single sign-on for Cognos 8/10 with Active Directory

RealMe. Technology Solution Overview. Version 1.0 Final September Authors: Mick Clarke & Steffen Sorensen

Guide to Obtaining Your Free WISeKey CertifyID Personal Digital Certificate (Personal eid) WISeKey 2010 / Alinghi 2010 Smartcards

IHE Pharmacy Technical Framework Supplement. Pharmacy Medication List (PML) Trial Implementation

How-to: Single Sign-On

TROUBLESHOOTING RSA ACCESS MANAGER SINGLE SIGN-ON FOR WEB-BASED APPLICATIONS

etoken Single Sign-On 3.0

Transcription:

Sign-On projektet HL7-CCOW Context Management: A National Sign-on Profile Version Dato Ansvarlig Kommentarer 0.1 22/10-2009 CHE Minimal profilering, 1 side med nødvendige SSO specifikationer til HL7-CCOW 0.2 10/02-2010 CHE Udvidelse af profilering til EUA 0.3 08/03-2010 CHE Udvidelse af profilering med patient subject 0.9 08/03-2010 CHE JRI kvalitetssikring

Abstract The international standard HL7-CCOW [HL7-CCOW] is a specification of how context is shared between clinical applications. This document describes the Danish, national profile of the HL7-CCOW context management standard, version 1.5. The national sign-on profile describes a number of specifications within the HL7- CCOW standard. These specifications define the national data items used in order to uniquely identify clinical users and patients. Side 2 af 12

Table of Contents 1 Introduction... 4 2 Conventions Used in This Document... 4 3 Specifications... 4 3.1 Definitions, Requirements, and Constants... 5 3.1.1 HL7-CCOW compliancy... 5 3.1.2 Digital certificates... 5 3.1.3 User Subject... 5 3.1.4 Patient Subject... 6 3.2 Profiling limitations... 8 4 Appendix A: HL7-CCOW User Subject Specification... 9 5 Appendix B: HL7-CCOW Patient Subject Specification... 10 References... 12 Side 3 af 12

1 2 3 4 5 6 7 8 9 10 11 12 1 Introduction The HL7-CCOW standard for context management involves use of subjects as data holders for different clinical and systemic aspects of a context. The standard defines data items for each subject, describing the most important aspects of each subject. Subjects can be extended with data items as seen necessary, both by vendors of clinical systems, and by national and international parties. In the Danish healthcare system, a number of attributes are defined on a national level, such as medical autorization code and a nationally unique personal identification number (CRS-number, or CPR-nummer ) [AUTH][CPR]. The purpose of this profile is to define the relevant data items necessary in a Danish context, allowing all vendors and other actors in the domain to communicate the attributes using the same terms and definitions. 13 14 15 16 2 Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 3 Specifications This section describes SSO within [HL7-CCOW] in the Danish Healthcare domain and for supporting the national requirements for unique identification of users and patients. Briefly, this document defines the following specifications and clarifications within [HL7-CCOW]: 1. The implementations SHOULD NOT make use of the Certificate Annotation Subject defined in HL7-CCOW, but SHOULD instead utilize standard Operating System mechanisms for digital certificates. 2. IT-systems participating in a HL7-CCOW context session MUST ensure that data items are not already specified in this profile or the HL7-CCOW standard before defining custom data items a. The User Subject is customized with a number of data items, defining a common glossary for attributes used nationally, e.g. medical authorization code and person identification number. b. The Patient Subject is customized with a specification of a national person identification number and two types of provisional person identification numbers. Section 3.1 of this document describes the clarifications in greater detail. Side 4 af 12

38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 3.1 Definitions, Requirements, and Constants 3.1.1 HL7-CCOW compliancy All HL7-CCOW implementations in the Danish Healthcare sector MUST: be HL7-CCOW compliant as defined in [HL7-CCOW] Be compliant with the clarifications to the HL7-CCOW standard as specified in this memo 3.1.2 Digital certificates The HL7-CCOW standard specifies a Certificate Annotation Subject, where a password protected certificate file can be stored. The purpose of this subject is to allow clinical systems to give the user access the certificate in a standardised way. The use of the Certificate Annotation Subject is permitted, but implementations SHOULD NOT use the Certificate Annotation Subject for two reasons. First, a number of actors in the healthcare sector are currently using mobility solutions for digital signatures, and in the implemented solutions the digital certificate of the active user is available for use either through standard methods or an exposed API. Second, the viability of physical tokens is currently being explored in a number of projects, and it is very likely that a solution where hardware based certificates are part of the solution will be implemented in one or more healthcare domains. The Certificate Annotation Subject is strictly software oriented, and hardware based certificates, e.g. smart cards or other physical tokens, cannot be used in conjunction with this subject. 3.1.3 User Subject The custom data items are named following the naming convention specified by HL7- CCOW. Please refer to Appendix A: HL7-CCOW User Subject Specification for the HL7-CCOW specification of the User Subject. Clinical systems participating in a HL7-CCOW context session MUST use the following data items instead of specifying custom data items with the same semantic meaning: User Subject Identifier Item Name User.Id.[sdsd.dk]Cpr Number User s national identification number (No meaning for HL7); Central Person Register number Type Semantic Constraints on Values ST None No Case Sensitive Side 5 af 12

User Subject Corroborating Item Name User.Co. [sdsd.dk]idcardid User.Co.[sdsd.dk]Se ssionid Key to the ID-card used to acquire access to the national services Hashed value uniquely identifying the security session established by the user (e.g. hashed value of the Kerberos TGT) Type Semantic Constraints on Values ST None Yes ST None Yes Case Sensitive 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 3.1.4 Patient Subject The Patient Subject is defined with a set of identity data items and a number of corroborative data items. Please refer to Appendix B: HL7-CCOW Patient Subject Specification for a complete reference to the Patient Subject. In a Danish context all patients are uniquely identified with nationally unique personal identification number (CRS-number, or CPR-nummer ) [CPR]. In the case where it is not possible to obtain this identifier 1 a provisional identification number is assigned to the patient. This clarification of the patient subject defines how these numbers MUST be set in the Patient Subject. The HL7-CCOW standard has slated all of the Patient Subject identity data items but the Patient.Id.IdList for deprecation, and the standard encourages vendors to use the IdList data item instead of the other patient identifier data items. In order to ensure future compatibility with HL7-CCOW this profile not only encourages but requires the use of IdList, and applications setting the patient context therefore MUST use the standard repeating data item Patient.Id.IdList. Patient Subject Identifier Item Name Patient.Id.IdList A list of patient identifiers for a patient. Type CX Semantic Constraints on Values Each entry in this list (MAY be one entry only) MUST follow the specification of CX item values as defined below. Case Sensitive The data type CX is a composite value consisting of a number of elements, including an optional check digit, and is specified in the HL7-CCOW standard [HL7-CCOW section 11.2]. The data type is illustrated in the table below as adapted by IHE from HL7-CCOW: No 1 E.g. if the patient is unconscious and carries no identification papers Side 6 af 12

92 Table 1 Components of the HL7 Type CX (source: [IHE-App, Appendix E]) 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 Please refer to [IHE-App], Appendix E, for a complete description of the data type and examples of use. Only the ID (component 1) and the Assigning Authority (component 4) are mandatory. The optional components are not specified in this profile, and applications SHOULD omit them, but are not required to do so. This profile specifies how the Assigning Authority-component of entries in the Patient.Id.IdList MUST be assigned, when an application sets the CPR-number for the patient. Assigning Authority MUST be unique within a given HL7 implementation, and therefore this profile specifies the relevant authorities in the user-defined HL7- table 0363. There are three possible assigning authorities for the unique patient identifier number in a Danish context (the real CPR-number, a local provisional CPR-number, and a national provisional CPR-number), and they are listed in the table below. Applications setting the Patient.Id.IdList data item MUST specify the Assigning Authority exactly as defined in the table below: Table 2 extension of the HL7 user-defined table 0363: Assigning Authority. Literal Description Usage scenario Value CPR The Central Office of Civil Specify this Assigning Authority Registration (the CPR-office). The when the CPR-number is the CPR-office is the national authority real identifier of the patient. for CPR-numbers. LCPR Local authority for provisional CPRnumbers. The local authority is typically the first clinical system an anonymous patient is submitted into, or a common IT-system that generates locally unique provisional CPR-numbers. NCPR National authority for provisional CPR-numbers. The national authority for provisional CPRnumbers is used when a patient with a local provisional CPR-number is transferred to another domain (either the patient or information about the patient) Specify this Assigning Authority when the CPR-number is provisional and created locally. Specify this Assigning Authority when the CPR-number is provisional and created nationally. Side 7 af 12

111 112 113 114 115 116 3.2 Profiling limitations The profile specifies only the context needed to handle the tasks regarding single sign-on. In HL7-CCOW the User Subject is the primary data container for the user, and the profile specifies data items for this subject in order to provide enough data items to cater the needs in a single sign-on context both locally and on a national level. Side 8 af 12

117 118 119 120 121 4 Appendix A: HL7-CCOW User Subject Specification The User Subject contains two data items as specified in the standard [HL7-CCOW]. For reference purposes the User Subject specification is included below: User Subject Identifier Item Name User.Id.Logon.Suffix User Subject Corroborating Item Name User.Co.Name User s logon name (No meaning for HL7) User s name (No meaning for HL7) Type 2 Semantic Constraints on Values Case Sensitive ST None Value is case sensitive. For example, ksmith and Ksmith are two different logon id values. Type Semantic Constraints on Values XPN None No Case Sensitive 2 HL7-CCOW specifies a number of types, including ST = String and XPN = Extended Person Name Side 9 af 12

122 123 124 125 126 127 128 129 130 131 132 133 134 135 5 Appendix B: HL7-CCOW Patient Subject Specification The Patient Subject contains four data items as specified in the standard [HL7- CCOW]. For reference purposes the Patient Subject specification is included below: Patient Subject Identifier Item Name Patient.Id.MRN. Suffix Patient.Id.MPI Patient.Id.NationalId Number Patient.Id.IdList Patient s medical record number, per PID-2 Patient s identifier in the Master Patient Index, per PID-2 Patient s national identifier number, per PID-2 A list of patient identifiers for a patient, per PID-3 Type Semantic Constraints on Values ST HL7 Table 0203 Identifier Type = MR ST HL7 Table 0203 Identifier Type = PT or PI (as agreed upon by context sharing systems) and Assigning Authority represents the MPI system CX HL7 Table 0203 Identifier Type = PT and Assigning Authority represents agreed upon National Authority CX May be a repeating set of CX item values (per Section 1.7), each of which contains one identifier that denotes the same patient (Driver s license and social security number may be among these identifiers) Case Sensitive According to the HL7-CCOW standard, an application participating in a context session shall set a value for at least one of the items defined above, whenever it sets the patient context. This is to ensure enough data for a correct mapping between all identifier data items for all participating systems. It should be noted, that Patient.Id.IdList is the primary data item for identifying the patient; according to the HL7-CCOW standard the three other data items (MRN.Suffix, MPI, and NationalIdNumber) are all slated for deprecation in the future. No No No No Side 10 af 12

135 136 137 The following data items MAY optionally be set by an application setting the patient context: Patient Subject Corroborating Item Name Patient.Co. PatientName Patient.Co. AliasName Patient.Co. DateTimeOfBirth Patient.Co.Sex Patient.Co.DLN Patient.Co.SSN Patient s legal name, per PID-5 Alias name for the patient, per PID-9 Patient s Date and time of birth, per PID- 7 Patient s gender, per PID-8 Patient s driver s license number, per PID-20 Patient s Social Security Number, per PID-19 Type Semantic Constraints on Values XPN Table 0200 No XPN Table 0200 No TS None No IS Table 0001 No DLN None No ST None No Case Sensitive Side 11 af 12

138 139 References HL7- http://www.hl7.org/implement/standards/ccow.cfm CCOW SST http://www.sst.dk/uddannelse%20og%20autorisation/autorisationsregister.aspx RFC2119 http://www.faqs.org/rfcs/rfc2119.html CPR http://www.cpr.dk/cpr/site.aspx?p=34 AUTH http://www.sst.dk/uddannelse%20og%20autorisation/autorisationsregis ter.aspx (Language: Danish) IHE-App http://www.ihe.net/technical_framework/upload/ihe_iti_tf_6-0_vol2x_ft_2009-08-10.pdf Side 12 af 12