Provider Directories and Direct

bijoufriesΤεχνίτη Νοημοσύνη και Ρομποτική

19 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

127 εμφανίσεις

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

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

d
irect lookup/
r
outing

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
e
xchange

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








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

ILPD



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



卵扭楴t敲e湥敤猠t漠s敮搠愠m敳s慧a t漠慮a楮摩i楤畡氠
灲潶楤敲


卵扭楴t敲e桡h s潭攠楮i潲o慴楯渠潮o楮摩i楤畡氠扵b
does not have information about the individual’s
汯l慴楯i


f䱐i 楳 畳敤et漠楤敮瑩fy 慬氠灯ps楢汥i汯l慴楯湳


t楴栠慤摩瑩潮o氠楮i潲o慴楯測 s畢u楴t敲e楤敮瑩f楥i 慮搠
selects appropriate location


ILPD links to ELPD to obtain security credentials,
digital certificates, location of submitter and receiver
entities


卵扭楴t敲es敮摳e摡d愠t漠楮摩i楤畡氠灲潶楤敲i慴 t桥h
楤敮瑩f楥搠汯l慴楯i

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

Uses/Functions

Directory Content

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








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

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


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

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




䑩獣ov敲e



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.

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

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

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)

Referral Documents, Referral Follow
-

Up, Results Delivery

Specialist(s)/Referred to

18








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








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


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





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








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

Lab Report 2.pdf

Send Message

Address




DIRECT Email

Provider
Directory

Message delivered
to the designated
entity’s Inbox

Internet






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