Provider Directories and Direct

1. Provider Directories and Direct Session 5 April 12, 2010

2. Agenda • Provider Directory overview • Definition and value proposition • Data sources • IE WG recommendations and use cases • Provider directory requirements • Certificates • Panelists • Kim R. Pemble, MS, CPHIMS, Executive Director, WI Health Information Exchange (WHIE) • Linda Syth, COO, Wisconsin Medical Society • Vincent P. Lewis, Principal Architect, MedAllies, Inc. • Russel Weiser, Senior Consultant –Product Mgmt./Dev. Identity/Access Management, Verizon Business Inc. • Mike Weber, Manager – Product Management/Development, Verizon Business Inc. • Q&A • Poll

3. Provider Directory Definition • An electronic searchable resource that lists all information exchange participants, their names, addresses and other characteristics and that is used to support secure and reliable exchanges of health information. • Three directory concepts, which are often combined: • Discover certificates: A cataloguing of end nodes and corresponding certificates allowing for secure electronic routing between computers • Discover entity: Entity-Level Provider Directory (ELPD) - A directory listing provider organizations • Discover provider: Individual-Level Provider Directory (ILPD) - a (human readable) directory listing individual providers

4. Provider Directory Value Propositions • Simplified workflow, potential for increased automation – • Identification/verification of recipient information and electronic links via provider directory • Shared costs, higher-quality information • User systems no longer burdened with maintaining separate provider directories • Reduced demand on providers to respond to multiple requests to enter and update information • Enriched content transfer, reduced errors

5. Provider Directory Continuum Provider directories can evolve as grantees develop more complex data exchange capabilities . Provider directories to facilitatemanual lookup For direct “push” exchange Provider directories to facilitate automated direct lookup/ routing Provider directories to support both push / pull exchange Machine and human readable directories to support the future state vision of networked exchange. Includes both Entity Level Provider Directory (ELPD) and Individual Level Provider Directory (ILPD) capabilities Supports both push and pull use case scenarios across multiple HIE/HIO networks enabling NwHIN • A human readable directory to support direct • point-to-point exchange of health information. • A web-based directory of providers who wish to send & receive clinical messages utilizing the Direct Project protocols. • Can support push communication via • email to email, • EHR to email, • EHR to EHR A machine readable directory to support direct & networked point-to-point exchange of health information. A HISP-based directory of providers who wish to send & receive clinical messages utilizing the Direct Project and other HISP supported protocols. Utilized in operational HIEs New requirements added to trust framework over time: one-to-one  one-to-many  many-to-many

6. Potential Provider Directory Sources of Data • Licensing authorities • Integrated Delivery Networks • Hospitals/health systems • Clinics • Payers • Medicaid • Professional associations such as state medical societies, etc. • Public health • Vendors Align sources of data for directories to business interests to ensure relevance and accuracy.

7. Provider Directory Use Case Examples • Directed exchange transactions supporting Stage 1 Meaningful Use and as defined by Provider Directory Task Force: • PCP to/from Specialist (i.e., problem list, patient summary visit) • Ambulatory Physician to/from Hospital (i.e., discharge summary; emergency department visit summary; surgical report) • Ambulatory Physician to/from Laboratory (i.e., lab order, lab result) • Public Health to/from providers (i.e. Communicable disease, drug or device issue, etc.)

8. Provider Directory Recommendations – Guiding Principles • Business Processes - Start simple and with what’s needed to support concrete priority business process, not with data • Meaningful Use - Focus on requirements for stage 1 MU, but with an eye to supporting Stages 2 and 3 and beyond • Agility - Don’t over-design too early, remain flexible to changes in technology and business (e.g., ACOs) • Incremental – Start by identifying and clearly articulating the minimum set of directory capabilities and the most straightforward technical model needed to accelerate and enhance secure exchange as identified in current and anticipated Meaningful Use stages • Collaboration - Encourage regional/multi-state/national initiatives that leverage purchasing, policy and regulatory opportunities • Completeness - Clearly delineate sources and uses and users • Security – Protected health information must be transmitted securely, with assurances that actors participating in exchange adhere to a minimum set of standards to protect that information

9. Provider Directory Taskforce Recommendation Examples –ELPDs • Recommendations adopted by HITPC in December 2010; HITSC is currently working on standards recommendations • Recommendation categories include: • Users: What entities should use the ELPD? • Uses/functions: What general functionality capabilities should the ELPD support? • Directory content: What data is required in order to enable desired uses? • Operating reqs./business model: What operating reqs. will be needed to meet users’ needs? What are the potential business models for meeting needs? • Policy issues/actions: What policy issues are related to business models? What actions should be taken to address policy issues? • Full set of recommendations can be found by accessing 1/4/11 meeting materials here: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1474&&PageID=17114&mode=2&in_hi_userid=11673&cached=true

10. Provider Directory Taskforce Recommendation Examples –ILPDs • Recommendations presented to HITPC in March 2011 • If the HITPC accepts the recommendations, HITSC will be tasked with developing ILPD standards • Recommendation categories identical to ELPDs • Scope is at sub-national level • Maintenance and updates to ILPD managed at local/regional level; not necessarily managed/supported at national level • ILPD would have a relationship (many-to-many) with the ELPD • Full set of current recommendations, see meeting information for 3/2/11 here: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1814&parentname=CommunityPage&parentid=18&mode=2&in_hi_userid=11673&cached=true

11. S&I Provider Directories Initiative • Likely launching in May 2011 • Focused on: • Standard EHR API • Standard data model (corresponding to the API) • (Eventually) standard approach for federation/national access http://jira.siframework.org/wiki/pages/viewpage.action?pageId=4194700

12. Provider Directory Requirements for Direct Implementation • For Direct implementations, there are some required directory functionalities and some functionalities that are useful for exchange

13. Certificates and Provider Directories • Direct requires discoverability of certificates • HISPs ensure Direct specifications are met for discoverability of certificates – i.e., support for DNS or alternate methods such as LDAP • Use of DNS is a practical interim solution; in the end-state, certificates will be managed through national access to standard directories • From the Direct participant's point of view, a directory enables a seamless experience for managing and using certificates • Certificates appear as another field in the directory, along with name, address, etc. • A Direct message sender automatically applies the appropriate certificate by selecting a name from the directory • States should work with RECs to ensure that recommended EHRs work with the State’s Direct solution

14. Wisconsin Presentation

16. Initiatives • Address “White Space” • Leverage existing assets in WI • Seek to standardize collected data • Maximize reuse of data when appropriate and possible • Leverage networks and data to minimize duplication and redundancy • Emphasis on Workflow • Separate Process from Data

17. Provider Directory Current State Where is WI today: • Current Provider Directory with WI Medical Society (WMS) DRconnetion • Work Group – DHS, DRL, MMIS, WHIE, WHITEC, WISHIN, WMS • Functional Needs Assessment and Functional Requirements • Reporting • Operational

18. Direct Communications Point to Point Referral Results Delivery PHI for Various Continuity of Care Services Individual Health Organizations, Clinics, Providers, Payers, Pharmacies, etc. PHI For Referral, Admission, Results Delivery Physician Office(s), Clinic(s), including Independent and affiliated or owned Health Information Service Provider Services Response to Certificate Inquiries, Validation of Recipient Address & Related Routing Services Referral Documents, Referral Follow- Up, Results Delivery Query against State Provider Directory as needed Routing and CA Direct Communications Point to Point Referral Results Delivery Services Provider Directory State Asset Payload-Driven Translational Interface Services Associated Specialist(s)/Referred to with Routing End Point or Local HISP Action Provider to Hospital Admission Provider to Provider via Regional HISP to State HISP Laboratory Results “Lab Format” Hospital to Provider on Event (e.g. Discharge) Geographic-Based Local Medical Service Area Exchanges: Healthcare Organizations, Clinics, Surgery Centers, Imaging Centers, etc. Laboratories

19. Conceptual Model Drconnection Over 900 data Elements Commercial HISP “Provider Directory” ??? Commercial and/or State HISP(s) “Provider Directory” Certificates, Keys? Separate Process from Data “Operational “ Provider Directory for HITECH (HIE, REC) Service Subset of Data for HITECH Services, Regular Extracts Structured for “Real Time Operations” and Reporting HIN Operational Services Reporting Services for HIE/HIN and REC

20. HIE Fields for Consideration • Email Address • General Clinic Phone • General Office Fax • Office Site NPI number • Hospitals to which this provider is affiliated • e-Prescribing • Electronic Medical Record • Specialty • State License From • License number • Type of license • NPI number • Medicare Provider Number • Medicaid number • Digital Certificate/Public Key • Direct Address Last Name First Name Middle Name or Initial Name suffix (Jr., III) Degree / Title (free form, 1 time, 20 char max) Date of Birth Gender Office / Practice Name Parent Organization/Group Street name Suite / building number Address Line 2 City County State Zip code + 4

21. Discussion Points • Certificate granting as process vs. enrolling at “regional” HISP • Synchronization/alignment of “regional”, “state” and “interstate” HISPs • “Local” and “Global” contact lists • Architecture, Interoperability “Standards” • Identify appropriate incentives to ensure sources of data maintain current and accurate entries

22. Discussion Points Cont. • Scalability to all “HIPAA Providers” • Associations Individuals to Entities, and Independence • Audit reporting requirements • Consistent Terminology and Semantics • Reuse of data, a critical element for HIE in general

23. Use Case 1: Physician Searching for a Lab Physician logs into the DIRECT messaging system Provider Directory Search: Laboratories Name: Lab Corp City: Milwaukee State: ZIP: Search Internet Address DIRECT Email 5015 S 110th Street, Milwaukee, WI, 53228. Ph: (414)529-5620 LabCorp1@direct.org 2457 N Mayfair Road, Milwaukee, WI, 53226. Ph: (414)475-6206 LabCorp2@direct.org Attachments: Tests prescribed.pdf Send Message Message delivered to the designated entity’s Inbox

24. Use Case 2: Lab Sending Out a Report to a Clinic Lab person logs into the DIRECT messaging system Provider Directory Search: Clinics Name: Marshfield City: State: Wisconsin ZIP: Search Internet Address DIRECT Email 945 South Dettloff Drive, Arcadia , WI, 54612-1895 Marshfield.Arcadia@direct.org 729 Pine Street P.O. Box 119, Athens ,  WI, 54411 Marshfield.Athens@direct.org 1711 York Street, Bloomer, WI, 54724 Marshfield.Bloomer@direct.org ……. ……. Attachments: Lab Report 1.pdf Lab Report 2.pdf Send Message Message delivered to the designated entity’s Inbox

25. MedAllies Presentation

26. MedAllies Provider Directory Approach • Provider Directory supplies lookup and routing capabilities, whether endpoint is SMTP or XD. • Phased approach to HISP requirement of maintaining provider directory • Phase 1: Static directory of providers that will be exchanging Direct project messages for closed loop referral & discharge summary notification • Phase 2: Dynamic/centrally hosted provider directory integration based on IHE • Phase 3: Conform to National Standards as they come on line.

27. Phase 1, Reference Implementation • Routing based on advanced knowledge of Direct Address (no central lookup) • Each pilot site or its EHR vendor responsible for supplying providers’ information in MS-Excel spreadsheet • MedAllies merge all provider lists obtained for each pilot site, and create/maintain the master provider directory • Master provider directory list distributed to all pilot sites, out-of-band • Pilot site’s EHR vendor integrate relevant providers’ list in their application from which users select ‘intended recipient’ for their clinical messages • Intended Recipient triggers HISP centralized routing

28. Phase 2, IHE Based Maintenance • Provider Directory information including endpoints and direct addresses maintained in relational databases • Master Data Management (MDM) Database allows for unique identification of providers and their practices, linked with their direct addresses • MDM Database fronted by Standard IHE PIX-PDQ HL7 V3 interface, already supported by many of our EHRs • Allows for ID correlation and demographic querying for direct address • Loosely coupled Admin Database allows for Provider Maintenance and Operational Workflow per HISP policy • Admin Database maintains endpoint routing based on direct address Fields in provider directory include: Org ID; User ID; First name; Last name; Middle initial; Credential; Street address 1; Street address 2; City; State; Country; Zip code; DoB; Effective date; End date; Practitioner/admin; Access to clinical information; Break-the-glass; NPI; Direct address; Endpoint and type

29. Direct Provider Maintenance Screen

30. Phase 3, National Provider Directory • Following developments in the HIT Policy Committee for national direction • Anticipate substituting national data structure and interface for current MDM / IHE implementation • Should be able to keep HISP admin and policy implementation with new national structure

31. Verizon Presentation

32. S/MIME, PKI Challenges • Generation, Distribution and Use of S/MIME can be difficult • Certification Authority (CA) issues • Issues two X.509 Certificates (Public/Private Keys) one for Digital Signing another for Encryption • CA Certificate Chain • Attests to users identity • Key Storage and Distribution • Sender must distribute Public Key to recipient prior to receiving an encrypted email • Public Keys are stored locally on the computer receiving the email • Private Key used to sign emails while encrypting the email required to Public Key of the recipient encryption certificate. • Distribution to more than one email recipient • Requires Public Key encryption to each recipient • Mailing List Agent’s public key enables single encryption by sender, but still requires encryption by agent to each recipient • Each specific user must unwind message

33. S/MIME, PKI Challenges, cont. • Key management • Proper management of Certificate Authorities is expensive • How to manage common use cases with differing email clients: • Configuration of email clients (MS Outlook, Web Based clients) • Validation of Certificates (Certificate Revocation Lists) • Accounts dedicated to provider • Lost Private Keys • Key revocation • Key recovery/redistribution • Managing Trust across multiple authorities “Trust Anchors”? • Use of too many trust anchors will cause interoperability issues • Certificate Policy development is extremely time consuming. • Standard enrollment and Issuance of certificates

34. Cloud Based Solutions Simplifies • Centralized Trusted Entity • Simplified end user registration process via a controlled process • Use centralized web portal • Leverage end user email accounts via MS Exchange interfaces • Improved user experience • Validation of end users prior to issuance of trusted credentials • Centralized identity proofing augmented by delegated identity proofing from HISP organizations • Cloud based Private and Public Keys reduce complexity for end users • Private keys kept secure • Reduces identity theft • Reduces administrative tasks

35. Cloud Based Solution Simplifies, cont. • Directory • LDAP, including IHE Healthcare Provider Directory attributes • S/MIME attributes values integrated with directory • Integration with EMR, HIE and other systems • Low latency lookup • Network Directory - Public (extranet) / Private access (intranet) • Public senders have Read only search access to the directory • Commercial Offering • High assurance of integrity, scalable and availability

36. Tradeoffs • Sole source deployment improves the chances of rapid adoption and integration • Distributed Multiparty or End User Self Service • Elongated adoption process • User experience varies • Private and Public Key control unknown • Distributed closed community directories • Centralized Trusted Entity • Enables rapid deployment • Improved user experience • Simplified Private and Public Key distribution and management • Centralized directory with 3rd party access capabilities

37. Provider Directory Resources • Direct wiki Certificate Pilots Recommendations page • http://wiki.directproject.org/Certificate+Pilot+Recommendations+Discussion • State HIE Provider Directory CoP HITRC site: • http://hitrc-collaborative.org/confluence/display/hiecopproviderdirectories/Provider+Directories+-+Home • Information Exchange Workgroup site: • http://healthit.hhs.gov/portal/server.pt?CommunityID=1474&spaceID=14&parentname=&control=SetCommunity&parentid=&in_hi_userid=11673&PageID=0&space=CommunityPage • S&I Framework Wiki (will be launching a Provider Directory initiative soon) • http://wiki.siframework.org

38. Q&A

39. Poll