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
Provider directories
to support both
push / pull exchange
A machine readable
directory to support direct
& networked
point-to-point exchange
of health information.
Machine and human
readable directories to
support the future state
vision of networked
exchange.
A HISP-based directory
of providers who wish to
send & receive clinical
messages utilizing the
Direct Project and other
HISP supported
protocols.
Includes both Entity
Level Provider Directory
(ELPD) and Individual
Level Provider Directory
(ILPD) capabilities
Utilized in operational
HIEs
New requirements added to trust framework over time: one-to-one 
Supports both push and
pull use case scenarios
across multiple HIE/HIO
networks enabling
NwHIN
one-to-many 
5
many-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
7
identified location
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
Uses/Functions
Directory Content
•Individual providers and NOT
entities: clinicians,
administrators, support staff)
•Support directed
exchanges functions
(send/receive as well as
query/retrieve)
• Demographics: Name,
provider type, specialty,
name/address of
practice locations,
practice phone, e-mail
and hospital affiliation
• Enrollment and
verification process
•Potentially sensitive
identifiers: NPI, DEA,
State License #, etc.
• Considerations of
uses outside support of
MU (credentialing,
research, etc.)
•Provide basic
“discoverability” of
individual
provider/practice
location(s); tight linkage
to provider’s ELPD
listing
Operating
Reqs/Business Model
•Role and rules-based
access requirements
•Information updating
requirements (at least
three times per year)
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 directory
functionalities and some functionalities that are useful 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
Direct
Communications
Point to Point
Referral
Results Delivery
Individual Health
Organizations, Clinics,
Providers, Payers,
Pharmacies, etc.
Physician Office(s), Clinic(s),
including Independent and
affiliated or owned
Response to Certificate
Inquiries, Validation of
Recipient Address & Related
Routing Services
Referral Documents, Referral FollowUp, 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
Specialist(s)/Referred to
Hospital to Provider on
Event (e.g. Discharge)
Direct
Communications
Point to Point
Referral
Results Delivery
Provider
to
Provider
via
Regional
HISP to
State HISP
Geographic-Based Local
Medical Service Area
Exchanges: Healthcare
Organizations, Clinics,
Surgery Centers, Imaging
Centers, etc.
Laboratories18
Conceptual Model
???
Drconnection
Over 900 data
Elements
Certificates, Keys?
Separate Process
from Data
Subset of Data for
HITECH Services,
Regular Extracts
HIN Operational
Services
“Operational “
Provider Directory
for HITECH (HIE,
REC) Service
Commercial
HISP
Commercial
“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
Provider
Directory
Search: Laboratories
Name: Lab Corp
City: Milwaukee
State:
ZIP:
Search
Address
Internet
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
23
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
Address
Internet
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
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
34
– Reduces administrative tasks
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 3rd 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://hitrccollaborative.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