Presentation is loading. Please wait.

Presentation is loading. Please wait.

Provider Directories and Direct Session 5 April 12, 2010.

Similar presentations

Presentation on theme: "Provider Directories and Direct Session 5 April 12, 2010."— Presentation transcript:

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 2

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 3

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 4

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 directories to facilitate manual lookup For 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 directories to facilitate automated direct 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 directories to support both push / 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. 5

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

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

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 8

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: serid=11673&cached=true serid=11673&cached=true UsersUses/FunctionsDirectory ContentOp. Reqs/Business Model Policy 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 9

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: entid=18&mode=2&in_hi_userid=11673&cached=true entid=18&mode=2&in_hi_userid=11673&cached=true UsersUses/FunctionsDirectory ContentOperating 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 10

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 on?pageId=4194700 11

12 Provider Directory Requirements for Direct Implementation For Direct implementations, there are some required directory functionalities and some functionalities that are useful for exchange RequiredUseful 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. 12

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 13

14 Wisconsin Presentation

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

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 17

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 Referral, Admission, Results Delivery Provider Directory State Asset Query against State Provider Directory 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 Referral Results Delivery Direct Communications Point to Point Referral Results 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 18

19 Conceptual Model Drconnection Over 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 19

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 20

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 21

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 22

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-5620 2457 N Mayfair Road, Milwaukee, WI, 53226. Ph: (414)475-6206 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 23

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 729 Pine Street P.O. Box 119, Athens, WI, 54411 1711 York Street, Bloomer, WI, 54724 ……. Name: Marshfield City: State: Wisconsin ZIP: Search Attachments: Search: Clinics Lab Report 1.pdf Lab Report 2.pdf Send Message Address DIRECT Email Provider Directory Message delivered to the designated entity’s Inbox Internet 24

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

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 27

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 28

29 Direct Provider Maintenance Screen 29

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 30

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 32

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 33

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 34

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 35

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

37 Provider Directory Resources Direct wiki Certificate Pilots Recommendations page – ion ion State HIE Provider Directory CoP HITRC site: –http://hitrc- Directories+-+Homehttp://hitrc- Directories+-+Home Information Exchange Workgroup site: – &parentname=&control=SetCommunity&parentid=&in_hi_userid=11673 &PageID=0&space=CommunityPage &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

38 Q&A

39 Poll 39

Download ppt "Provider Directories and Direct Session 5 April 12, 2010."

Similar presentations

Ads by Google