Upload
mary-todd
View
218
Download
1
Tags:
Embed Size (px)
Citation preview
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