Provider Directories and Direct

Session 5 April 12, 2010

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 2

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 3

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 4

Provider Directory Continuum

Provider directories can evolve as grantees develop more complex data exchange capabilities .

Provider directories to facilitate manual lookup For direct “push” exchange

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

Provider directories to facilitate automated direct lookup/ routing

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

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

New requirements added to trust framework over time: one-to-one



one-to-many



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.

6

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

ELPD

• Used to find routing information at the entity level. Entity would be responsible for routing to the correct individual provider within their organization

ILPD

•Submitter needs to send a message to an individual provider •Submitter has some information on individual but does not have information about the individual’s location •ILPD is used to identify all possible locations •With additional information, submitter identifies and selects appropriate location •ILPD links to ELPD to obtain security credentials, digital certificates, location of submitter and receiver entities •Submitter sends data to individual provider at the identified location 7

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 8

• • •

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_u serid=11673&cached=true

Users

•Health care provider orgs. (i.e., hospitals, clinics, etc) •Other health care orgs. (i.e., health plans, public health) •HIOs (i.e., regional HIE operators) •Other organizations involved in HIE (BAs, clearinghouses)

Uses/Functions

•Support directed exchanges (send/receive as well as query/retrieve) •Provide basic “discoverability” of entity, HIE capabilities, and security credentials

Directory Content

Entity ‘demographics’ and identification information: •Name •Address(es) • Other familiar names •Human point of contact

Op. Reqs/Business Model

• Internet-like model – nationally coordinated, federated approach • ELPDs maintained by certified registrars • National guidelines are followed

Policy issues/Actions

•Multiple ELPDs will exists but will feed into a national directory that will support identification of entities across ELPDs (like DNS) through an EHR •Acquisition of a security credential (certificate) and discoverability of this credential using the ELPD must be included in the technical approach 9

• • • • • •

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&par entid=18&mode=2&in_hi_userid=11673&cached=true

Users

•Individual providers and NOT entities: clinicians, administrators, support staff)

Uses/Functions

•Support directed exchanges functions (send/receive as well as query/retrieve) •Provide basic “discoverability” of individual provider/practice location(s); tight linkage to provider’s ELPD listing

Directory Content

•

Demographics

: Name, provider type, specialty, name/address of practice locations, practice phone, e-mail and hospital affiliation •

Potentially sensitive identifiers:

NPI, DEA, State License #, etc.

Operating Reqs/Business Model

• Enrollment and verification process •Role and rules-based access requirements •Information updating requirements (at least three times per year) • Considerations of uses outside support of MU (credentialing, research, etc.)

Policy issues/Actions

• HITSC identification and recommendation of ILPD interoperable standards (in line with HITPC recs and S&I framework) • ILPDs build from State HIE COP funds should be made available to public and private sponsored networks 10

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

on?pageId=4194700

11

Provider Directory Requirements for Direct Implementation

• For Direct implementations, there are some

required

functionalities and some functionalities that are

useful

directory for exchange

Required

• • Direct address issued by HISP • To include DNS-mapping of address to HISP (behind scenes) Certificate discovery • Use DNS or alternate methods in the • short-term Move to state/ national-based directories that include certificate discovery in the future

Useful for exchange

• Discovery • Messages the recipient is able to consume • What mode of communication to use • Look up address by name, specialty, place of practice, etc.

12

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 13

Wisconsin Presentation

15

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 16

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 17

Individual Health Organizations, Clinics, Providers, Payers, Pharmacies, etc.

Response to Certificate Inquiries, Validation of Recipient Address & Related Routing Services Referral Documents, Referral Follow Up, Results Delivery Specialist(s)/Referred to Hospital to Provider on Event (e.g. Discharge) Direct Communications Point to Point Referral Results Delivery Health Information Service Provider Services Routing and CA Services Query against State Provider Directory as needed Provider Directory State Asset Payload-Driven Translational Interface Services Associated with Routing End Point or Local HISP Action Provider to Provider via Regional HISP to State HISP Geographic-Based Local Medical Service Area Exchanges: Healthcare Organizations, Clinics, Surgery Centers, Imaging Centers, etc.

Physician Office(s), Clinic(s), including Independent and affiliated or owned Communications Point to Point Results Delivery Laboratories Direct Referral

18

Conceptual Model

Drconnection Over 900 data Elements Subset of Data for HITECH Services, Regular Extracts HIN Operational Services ???

Certificates, Keys? Separate Process from Data “Operational “ Provider Directory for HITECH (HIE, REC) Service

Commercial HISP “Provider

and/or State

Directory”

HISP(s) “Provider Directory” Structured for “Real Time Operations” and Reporting Reporting Services for HIE/HIN and REC

19

HIE Fields for Consideration

• • • • • • • • • • • • • • • • 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 • • • • • • • • • • • • • • • • 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 20

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 21

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 22

Use Case 1: Physician Searching for a Lab

Physician logs into the DIRECT messaging system Search: Laboratories Provider Directory Name: Lab Corp City: Milwaukee State: ZIP: Search Address DIRECT Email 5015 S 110th Street, Milwaukee,

WI

, 53228. Ph: (414)529-5620 [email protected]

2457 N Mayfair Road, Milwaukee,

WI

, 53226. Ph: (414)475-6206 [email protected]

Internet Attachments: Tests prescribed.pdf

Send Message Message delivered to the designated entity’s Inbox 23

Use Case 2: Lab Sending Out a Report to a Clinic

Lab person logs into the DIRECT messaging system Search: Clinics Name: Marshfield City: State: Wisconsin Search Address DIRECT Email 945 South Dettloff Drive, Arcadia , WI, 54612-1895 [email protected]

729 Pine Street P.O. Box 119, Athens , WI, 54411 [email protected]

1711 York Street, Bloomer, WI, 54724 …….

…….

Lab Report 1.pdf

Lab Report 2.pdf

[email protected]

ZIP: Send Message Provider Directory Internet Message delivered to the designated entity’s Inbox 24

MedAllies Presentation

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

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 27

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

28

Direct Provider Maintenance Screen

29

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

30

Verizon Presentation

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 32

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 33

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 34

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 35

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 3 rd party access capabilities 36

Provider Directory Resources

• • • • Direct wiki Certificate Pilots Recommendations page – http://wiki.directproject.org/Certificate+Pilot+Recommendations+Discuss ion 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

37

Q&A

Poll

39