Upload
maci-hemsworth
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
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)[email protected] 2457 N Mayfair Road, Milwaukee, WI, 53226. Ph: (414)[email protected]
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 [email protected] 729 Pine Street P.O. Box 119, Athens , WI, 54411 [email protected] 1711 York Street, Bloomer, WI, 54724 [email protected] ……. …….
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