1. 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

2. 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

3. Other domainsCertification domain Healthcare Trusted Certificate Security Model High security Certification service Consistent cryptography and policy standards Managed service Registration & certificate requests Published key certificates Encryption & digital signing Key pairs generated by end-users *local agents each responsible for their own user management but using international standards Local Registration Healthcare Certification service Non-Healthcare Certification service Healthcare Users Healthcare Directory

4. 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.

5. 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

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

7. 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

8. 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

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

10. 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

11. Internet Directory Architecture Health Information Sharing Practitioner CPR Health Reports Admin Reporting Birth Registry Birth Registry Consent Data Consent Tracking School Enroll. School Health Registry Audit Logs Trusted Agent Security Server Security Administration Patient Locator MPI MEI Immuniz. Data Immunization Tracking Purchasing, Billing & Accounting Account Data Clinic Schedules Clinic Schedule Specialty Data Specialty Guidelines CONTRA Indicators CDC Contract Rules Eligibility Enrollment Recall Data Recall US Mail Phone

12. Directory Architecture Integrated LDAP Models Trusted Agent Healthcare Facility Individual Users Insurance Carrier Insurance Carrier Other CAs Clearing House RA Health System Health System Chain LDAP Rep LDAP Local LDAP STD LDAP Healthcare Facility Access control policy Access control policy Access control policy Root CA Sub- CA Trading Partner Trading Partner Servers Internet

13. 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 Verified 3.Provider Identified, S/Mime Cert Retrieved, CRL Checked, Signature Verified 4.Group/Organization Identified, S/Mime Cert Retrieved 5.Physicians with specialty identified, CRL Checked, Signature Verified 6.Patients Identified, S/Mime Certs Retrieved, CRL Checked, Signature Verified

14. 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 CORRECT Communication information, S/Mime Certs, CRLs Dr. Jones, Administrator, Hospital A Dr. Jones, Physician, Hospital A Dr. Jones, Physician, Hospital B Case Example - Systems Communication

15. 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

16. 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.

17. 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

18. 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

19. 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

20. 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)

21. 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

22. 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

23. 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

24. Directory Schema Requirements:What Information Must be Recorded Role Information Standard Healthcare Roles Validity Period Time Qualifiers Location Qualifiers Delegation Qualifiers Condition Qualifiers

25. 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

26. Default Directory Intra-Enterprise Scope O=Company, C=US OU=Billing OU=HR... OU=People OU=Groups OU=Sales Chaining

27. 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

28. 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.

29. 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

30. 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)

31. 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.

32. 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@organizationCN.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

33. 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)

34. 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