Lori Reed-Fourquet, MS

Good Health Network

Presented to:

IHE

Monday, November 3, 2003

Healthcare Directory Services for Security, Communications, and Identification

of Professionals and Patients

Background

• <1990 Genetics/Molecular Biology/Data Analysis• 1990-1993 Health Outcomes Analysis/VLDB/Expert Systems• 1993/1994 Health Information Network

– Distributed/CS Database– EDI– Communications– CHIN/CHIMIS

• 1995-1998 ATP Community Secure Information Sharing Proof-of-concept (Biometrics/PKI/RBAC/LDAP/HL-7 MPI & Community Exchange Message)

• 1999-Present Healthcare PKI/TTP Implementation/Interoperability• Vice Chair ASTM E31.20 Committee on Data and System Security for Health

Information • US Delegate to ISO TC215:Health Informatics WG4 Health Information Security

– Task Force for Healthcare PKI– Task Force for Privilege Management Infrastructure– Task Force for Implementation Specifications for ISO17799– Task Force for Standard Healthcare Roles– Task Force Leader for Healthcare Directory

Other domains Certification domain

Healthcare Trusted Certificate Security Model

High security Certification service

Consistent cryptography and policy standards

Managed service Managed service

Registration

& certificate

requests

Published key certificates

Encryption & digital signingKey pairs generated by end-users

*‘local agents’ each responsible fortheir own user managementbut using international standards

Local Registration

HealthcareCertification service

Non-HealthcareCertification service

Healthcare Users

Healthcare Directory

HC PKI TS/Standard

• Define essential elements of a health care PKI that would support secure movement of information across national boundaries:– authentication of health care providers and

their roles– Identify extensions to X.509 Certificates

– Get agreed set of policies and procedures for authentication and verification of health care providers accreditation.

Health informatics –Public Key Infrastructure

• Specification Split into Three Parts - and Parts 1, 2 and 3– Part 1: Framework and Overview

• Defines PKI concepts, components and interoperability issues with respect to healthcare

– Part 2: Certificate Profile• Defines specifications for certificate fields and healthcare-specific

extensions

– Part 3: Policy Management of Certification Authority• Defines minimal requirements for certificate policies and certification

practices

Scenarios

• 15 Scenarios expressing requirements for:– Authentication– Confidentiality– Integrity– Digital Signature

Healthcare Certificate Types

• Public Key Certificates– Cross/Bridge Certificates– Certification Authority Certificates– End Entity Certificates

• Individuals (Details to follow)• Organizations (Details to follow)• Devices• Applications

• Attribute Certificates

Healthcare Certificate Types: End Entities

• Individual– Regulated Health Professional– Non-Regulated Healthcare Employee

• Sponsored Healthcare Professional– Midwives, Transcriptionists

• Supporting Organization Employees

– Consumers• Anonymous• Identified

• Organizations– Regulated Healthcare Organization– Supporting Healthcare Organization

HCRole Extension

• Goal: a single healthcare-specific extension enabling assertion of the healthcare profession, regulatory identifiers, professional identifiers, consumer identifiers, and employee roles

Attribute Certificates

• Recognized as goal for assertion of authorization information

• Delegation

• Volatile Credentials

• Multiple Issuing authorities

• No management specifications due to immature testing/deployment stages

Internet

Directory ArchitectureHealth Information Sharing

Practitioner

CPR

HealthReports

AdminReporting

BirthRegistry

BirthRegistry

ConsentData

ConsentTracking

SchoolEnroll.

School HealthRegistry

AuditLogs

TrustedAgent

Security Server

SecurityAdministration

PatientLocator

MPIMEI

Immuniz.Data

ImmunizationTrackingPurchasing, Billing &

Accounting

AccountData

Clinic Schedules

ClinicSchedule

SpecialtyData

SpecialtyGuidelines

CONTRAIndicators

CDC

ContractRules

EligibilityEnrollment

RecallData

Recall

US Mail

Phone

Directory ArchitectureIntegrated LDAP Models

Trusted Agent

Healthcare Facility

Healthcare Facility

IndividualUsers

InsuranceCarrier

InsuranceCarrier

Other CAsOther CAs

Clearing HouseClearing House

RA

HealthSystem

HealthSystem

ChainLDAP

RepLDAP

LocalLDAP

STDLDAP

Healthcare Facility

Healthcare Facility

Accesscontrolpolicy

Accesscontrolpolicy

Accesscontrolpolicy

RootCA

Sub-CA

Trading Partner

Trading Partner

Servers Servers ServersServers

Servers

Servers

Internet

1. Provider emails Claims/Claims clarification to payer

2. Provider emails test results to patient, Signed Message

3. Provider communicates order/result to another provider, Signed Message

4. Email to Group/Organization

5. Broadcast new Clinical Practice Guidelines to Physician Specialties, Signed Message

6. Broadcast new Patient Disease State Management Guidelines to Patient, Signed Message

Communications must be signed and encrypted

Case Example - End-User Communication

Healthcare Directory

1. Payer Identified, S/Mime Cert Retrieved 2. Patient Identified, S/Mime Cert Retrieved, CRL Checked, Signature Verified3. Provider Identified, S/Mime Cert Retrieved, CRL Checked, Signature Verified4. Group/Organization Identified, S/Mime Cert Retrieved5. Physicians with specialty identified, CRL Checked, Signature Verified6. Patients Identified, S/Mime Certs Retrieved, CRL Checked, Signature Verified

Health Information Referral Service sends clinical information or administrative information to provider, Signed Information Content

Electronic Prescription generated, signed, and sent to pharmacy, Signed Content

Email must be signed and encrypted Individual or

Organization Receives the information

•Decrypts the message

•Checks the authenticity of the sender (CRL)

•Checks Signature Validity

Healthcare Directory

Locate CORRECTCommunication information, S/Mime Certs, CRLs

Dr. Jones, Administrator, Hospital ADr. Jones, Physician, Hospital ADr. Jones, Physician, Hospital B

Case Example - Systems Communication

Directory Scenarios – Security Services

Authentication • Application configured to require SSL3 client-authentication certificate from trusted

CA. Certificate mapping links presented certificate to user directory entry, and user identified.

• Roles of authenticated user identified via LDAP query. Role-based-access-control decision made based upon roles registered in directory

• Roles of authenticated user identified via Attribute Certificate. Role-based-access-control decision made based upon Attribute Certificate.

• User presents token-stored certificate for authentication into application environment (strong authentication note:biometric protection vs pin protection and directory support for this).

• User presents software certificate for authentication from a mobile environment. Application requires secondary password verification against the directory.

• User authenticates via LDAP with user-id and password. Biometric authentication URL identified by application and consulted for secondary verification.

• Patient authenticates to application with user-id and password or digital certificate. Secondary biometric URL identified and consulted to assure identity.

• Practitioner delegates authority to act on their behalf under certain conditions via attribute certificate. Directory consulted to verify privilege path

Directory Scenarios – Security Services

Signature Verification• Physician writes a prescription signing with his/her

signature key. Sends the prescription to the pharmacy encrypted via LDAP look-up. Pharmacist verifies the signature and data content against public key via LDAP look-up. Certificate checked for Revocation and that issued by a trusted CA.

• Patient signs consent for authorization to view medical record. Signature and data content verified against public key via LDAP look-up. Certificate checked for Revocation.

• Look up identity of OCSP Service contact information, certificates etc.

Directory Scenarios – Security Services

CA Certification process support• CA Updates CRL• Subject of certificate is entered into Directory

along with all attributes held within the certificate.

• CA posts public key/certificate to Directory for Signing key, Authentication Key, and Encryption Key

• CA Hierarchy is listed in Directory• CA Contact information listed in Directory

Directory Scenarios – Health Infrastructure Services

Credentialling Process Support• Information that must be validated by

healthcare organization and regulatory bodies is listed in the directory to facilitate contacts. Base Education contact information, Continuing Education Contact Information.

• This information is also used for determining roles/privileges

Directory Scenarios – Health Infrastructure Services

MPI Support• Clinical information and history needed

as a component of secure communication with patient. MPI record is located after consulting Directory for MPI source

• Reference and feed PIDS from Corba

Directory Schema Requirements:Who

• Healthcare Consumers• Healthcare Providers• Healthcare Persons

– Employees– Trading Partner Employees

• Healthcare Provider Organizations• Healthcare Payer Organizations• Healthcare Agent Organizations (Trading

Partners)

Directory Schema Requirements:What Information Must be Recorded

• Healthcare Identifiers• Encryption Certificates • Organizational

affiliations • Organizational Roles• Local Roles/Job• Standard Roles

• Contact Information

• License Info• Credentials• Specialty• DEA info• Legal Business

Name– Changed Names

Directory Schema Requirements:What Information Must be Recorded

• HC Identifiers• National Identifiers/License Identifiers• Organization Identifiers• State Identifiers• Payer Product Identifier• Identifier Constructs• Issuing Authority• Number• Qualifiers/Subidentities• Locations of HC Infrastructure Services

– MPI– Biometrics

Directory Schema Requirements:What Information Must be Recorded

• Contact Information • Practice Location• Registered Address• Administrative Contact• Patient Guardian/Responsible Party• Job-Specific:• email• phone• address• secretary/support/supervisor

Directory Schema Requirements:What Information Must be Recorded

• Role Information

• Standard Healthcare Roles

• Validity Period

• Time Qualifiers

• Location Qualifiers

• Delegation Qualifiers

• Condition Qualifiers

Directory Architecture Requirements:Implementation

Guidelines

• Access Control• Directory Management Control• Account for Multiple Regulatory Drivers• Consistent representation of information

(what/where) • Support for healthcare process-specific queries

ie:• lookup id of employer• lookup communication• lookup role information

Default DirectoryIntra-Enterprise Scope

O=Company, C=US

OU=Billing OU=HR... OU=People OU=Groups

OU=Sales

Chaining

Directory Architecture Considerations:

Standard Namespace

• Performance– Replication for Workload Distribution– Replication for Service Management

• Distributed Management– Integration of Institutional Directory– Management of Institutional Roles

• Access Control– Add, Modify, Delete– View

Distinguished Name:Practitioners

• Professional with multiple license professions• Professionals with multiple practice locations

– UID = Issuing Authority Identifier:National/Regional Professional Identifier

– Common Name should preserve the legal name of individual, organization

• Surname, Given Names, UID• Chosen Surname, Given Name may contain Maiden Name

If differences, use the name as listed by medical license authority

• Alias Name for what they use – allow search by alias name (Usual Name)

• No titles in Common Name (ie MD, DVM…), keep Name titles of Jr, Sr, II etc.

Distinguished Name:Patients/HC Consumers

• Unique ID Regional Identifier, MPI, Regional Managed systems

– PIDS List of identifying attributes (20+ )– UID = Issuing Authority Identifier:National/Regional

Patient/Person Identifier– Distinguish by home address, add domicile identifier ID

Number, Common Name– Common Name should preserve the legal name of individual,

organization• Surname, Given Names, UID• Chosen Surname, Given Name may contain Maiden Name If

differences, use the name as listed by medical license authority• Alias Name for what they use – allow search by alias name

– No titles in Common Name (ie MD, DVM…), Jr, Sr, II

Distinguished Names:Organizations

• UID = Issuing Authority Identifier: National/Regional Identifier

• Common Name should preserve the legal name of organization

– Current Organization Legal Name, UID– Successor Name (alias?) add a link only for

obsolete organization name – Closure Date (COB)

Healthcare Roles

• In general, two types of roles can be distinguished: structural (or organisational) at the one hand and functional roles at the other hand. Structural roles enable certain services within the generic structure-function relationship. Reflecting human or organisational categories, structural roles describe prerequisites, feasibilities, or competences for actions. Functional roles are bound to the realisation of actions.

Healthcare Roles/Jobs

• OrganizationalRole (Special Structural Role expressing special relationships/Job Title, not intended to support Privilege Management)

– for contact, job description – Individual = CN.job_function@organization – using object class OrganizationRole. – Job_function is based upon organizational structure and positions – May add attribute certificates at this object class.

• standardRole (Structural Role) – Specialization of Group) – = Standard name of Role@organization_domain_name if local to

Organization, – if local to Locality (ie state) standardRole@Locality

• localRole (Specialization of Group) – used for new, or non-standard, or regionally, or locally defined roles – = organizationRole@organization_domain_name if local to Organization– if local to Locality (ie state) localRole@Locality

Community LDAP Interoperability

C=

L=

O= CN=(Practitioners), CN=Patients

CN=(OrganizationalRole)

StandardRole, LocalRole

StandardRole, LocalRole

StandardRole, LocalRole

OU= Issuing Authority Professional Branch(ie Pharmacists, Medical Doctors, Dentists)

CN=(Practitioners)

Directory Standards Summary

• Need to Support Contact and Security Information – Storage and Retrieval– Systems and End-Users

• Need to Support Common Information Content• Need to Support Common Processes for

– Directory Information Access– Directory Information Management– Directory Information Distribution– Directory Information Security

• Significant Overlap with Other Standards– Security, Vocabulary, MPI