Provider Directories and DirectSession 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

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 directoriesto facilitate manual lookupFor direct “push” exchange

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 directoriesto facilitate automateddirect lookup/ routing

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

Provider directoriesto support bothpush / pull exchange

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

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

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

ELPD ILPD

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

•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

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=trueUsers Uses/Functions Directory Content Op. Reqs/Business

ModelPolicy issues/Actions

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

•Support directed exchanges (send/receive as well as query/retrieve)

•Provide basic “discoverability” of entity, HIE capabilities, and security credentials

Entity ‘demographics’ and identification information:

•Name

•Address(es)

• Other familiar names

•Human point of contact

• Internet-like model – nationally coordinated, federated approach

• ELPDs maintained by certified registrars

• National guidelines are followed

•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

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

Users Uses/Functions Directory Content Operating Reqs/Business Model

Policy issues/Actions

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

•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

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

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

• 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

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

Required Useful for exchange

• 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

• Discovery• Messages the recipient is able to

consume• What mode of communication to use

•Look up address by name, specialty, place of practice, etc.

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

Wisconsin Presentation

15

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

PHI for Various Continuity of Care Services

Individual Health Organizations, Clinics,

Providers, Payers, Pharmacies, etc.

Physician Office(s), Clinic(s), including Independent and affiliated or owned

PHI For Referra

l, Admissi

on, Results Delivery

Provider Directory

State Asset

Query against State ProviderDirectory as needed

Provider to

Provider via

Regional HISP to

State HISP

Geographic-Based Local Medical Service Area Exchanges: Healthcare Organizations, Clinics, Surgery Centers, Imaging Centers, etc. Laboratories

Laboratory Results “Lab Format”

Direct Communications Point to Point

ReferralResults Delivery

Direct Communications Point to Point

ReferralResults Delivery

Health Information Service Provider

Services

Routing and CA

Services

Payload-Driven Translational

Interface Services Associated

with Routing End Point or

Local HISP Action

Response to Certificate Inquiries, Validation of Recipient Address & Related Routing Services

Hospital to Provider on Event (e.g. Discharge)

Provider to Hospital Admission

Referral Documents, Referral Follow- Up, Results Delivery

Specialist(s)/Referred to

19

Conceptual Model

DrconnectionOver 900 data

Elements

Commercial HISP

“Provider Directory”

Commercial and/or State

HISP(s)“Provider Directory”

“Operational “ Provider Directory

for HITECH (HIE, REC) Service

Reporting Services for

HIE/HIN and REC

Subset of Data for HITECH Services, Regular Extracts

HIN Operational Services

???

Certificates, Keys? Separate Process

from Data

Structured for “Real Time

Operations” and Reporting

20

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

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

5015 S 110th Street, Milwaukee, WI, 53228. Ph: (414)529-5620LabCorp1@direct.org 2457 N Mayfair Road, Milwaukee, WI, 53226. Ph: (414)475-6206LabCorp2@direct.org

Name: Lab Corp City: Milwaukee State: ZIP:

Search

Attachments:

Search: Laboratories

Tests prescribed.pdf

Send Message

Address DIRECT Email

Provider Directory

Internet

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

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

Name: Marshfield City: State: Wisconsin ZIP:

Search

Attachments:

Search: Clinics

Lab Report 1.pdfLab Report 2.pdf

Send Message

Address DIRECT Email

Provider Directory

Message delivered to the designated

entity’s Inbox

Internet

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

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

Q&A

39

Poll