Lori Reed-Fourquet, MS Good Health Network Presented to: IHE Monday, November 3, 2003

1. Healthcare Directory Services for Security, Communications, and Identification of Professionals and Patients Lori Reed-Fourquet, MS Good Health Network Presented to: IHE Monday, November 3, 2003

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

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

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

13. Healthcare Directory Case Example - End-User Communication • Payer Identified, S/Mime Cert Retrieved • Patient Identified, S/Mime Cert Retrieved, CRL Checked, Signature Verified • Provider Identified, S/Mime Cert Retrieved, CRL Checked, Signature Verified • Group/Organization Identified, S/Mime Cert Retrieved • Physicians with specialty identified, CRL Checked, Signature Verified • Patients Identified, S/Mime Certs Retrieved, CRL Checked, Signature Verified Communications must be signed and encrypted • Provider emails Claims/Claims clarification to payer • Provider emails test results to patient, Signed Message • 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

14. Healthcare Directory Case Example - Systems Communication Locate CORRECT Communication information, S/Mime Certs, CRLs Dr. Jones, Administrator, Hospital A Dr. Jones, Physician, Hospital A Dr. Jones, Physician, Hospital B Email must be signed and encrypted 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 Individual or Organization Receives the information • Decrypts the message • Checks the authenticity of the sender (CRL) • Checks Signature Validity

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

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 DirectoryIntra-Enterprise Scope O=Company, C=US OU=HR OU=People OU=Billing ... OU=Groups Chaining OU=Sales

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@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= StandardRole, LocalRole O= CN=(Practitioners), CN=Patients StandardRole, LocalRole OU= Issuing Authority Professional Branch (ie Pharmacists, Medical Doctors, Dentists) CN=(Practitioners) StandardRole, LocalRole CN=(OrganizationalRole)

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