2. Discussion on the Western
States Consortium and
Inter-State Exchange
Robert Cothren, California Health eQuality
Institute for Population Health Improvement
5. Use Case
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
• Includes investigation of policies, procedures, and
technologies.
• “Using Direct” concentrates on a simple use case
being implemented today.
• “Across state lines” is a more complex version of
“with unaffiliated providers”.
• “Between providers” and “for treatment purposes”
places focus on interstate exchange rather than
patient privacy issues.
4
6. Use Case
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
Really about scalable trust.
Two important components…
1. Establishing a Trust Community.
2. Discovering how to communicate with others.
5
7. Use Case – the Future
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
Focus on this use case for now, but we want to
prepare for the future…
• Use cases beyond Direct.
• Use cases within state lines but between unaffiliated
organizations.
• Use cases beyond between providers.
• Use cases beyond treatment purposes.
6
8. Pilot Scenarios
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
Scenario 1 The sender knows the Direct address of
the recipient.
– Defines a Trust Community of HISPs that conform
to Eligibility Criteria. (governance task)
– Creates a Trust Bundle as the identities of
Qualified Entities. (technology task)
– Currently underway.
7
9. Creating a Trust Community
Moving from today’s … to tomorrow’s world of
world of point to point scalable trust.
trust agreements….
8
10. Creating a Trust Community
Add New Qualified Entity to Trust Community
• Policies for sharing of
Trust Bundle New Qualified Existing Qualified
Governance Body Party State
Coordinator Entity POC Entity POCs
From “Eval
information between
of Qualified
Entity”
Requests that
HISPs.
Qualified Entity be Requests Trust Returns Trust
added to Trust Anchor. Anchor (via email).
Community.
Inspects Trust
Anchor to verify it
• Eligibility criteria that
meets Eligibility
Criteria.
Issues? yes Corrects issues.
look a little like no
accreditation.
Places Trust Anchor
in test HISP.
Sends trust anchor
Places trust anchor
for test HISP (via
for test HISP in HISP.
• A process for managing
email).
Conducts test of Conducts test of
Trust Anchor Trust Anchor.
and distributing trust Issues? yes Corrects issues.
anchors. no
Adds Trust Anchor
to Trust Bundle.
Notes successful Sends notice of
addition to Trust addition to Trust
Community. Community.
Sends notice that
Trust Bundle has
been updated.
Retrieves Trust Retrieves Trust
Notes update to
Bundle (via FTP) and Bundle (via FTP) and
Trust Bundle.
places in HISP. places in HISP.
9
11. So on to the meat…
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
Scenario 1 The sender knows the Direct address of
the recipient.
Not today’s topic.
10
12. Question
We are looking for input, so will be asking questions
today. A little practice…
• What is your favorite color?
My favorite color is blue.
I don’t like blue all that much.
11
13. Context
• Many states are focused on implementing Direct.
• Direct doesn’t require provider directories, but
directories can facilitate use cases where the sender
doesn’t know in advance recipients’ addresses and
other desired information.
• Many solutions include address books or some other
level of provider directory to serve their participants
internally.
• However – the ability for participants to query
directories outside of their HISP/HIE will be needed
to continue to advance today’s exchange objectives
and facilitate tomorrow’s.
12
14. Pilot Scenarios
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
Scenario 1 The sender knows the Direct address of
the recipient.
Scenario 2a The sender does not know the Direct
address of the recipient.
13
15. The picture…
• What is Dr. Smith’s Direct address?
query
HISP HISP
(directory) (directory)
response
NCHIN, an HIO CareAccord,
operating a HISP operating the
with a directory in statewide HISP
California. with a directory
in Oregon.
14
16. The purpose…
• Test an emerging standard for Directory Services
query.
• Drive out additional requirements as a result of user
feedback.
• Address these issues without complications of
federation.
15
17. Who are we talking about?
• For the WSC, and for right now, there is a one-to-one
correspondence between HISPs and directories.
• This may not always be the case:
– A HISP may use a third party directory provider.
– A state may implement a statewide directory for
multiple HISPs.
– A HISP may have multiple directories to serve
multiple geographies.
16
18. Pilot Scenarios
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
Scenario 1 The sender knows the Direct address of
the recipient..
Scenario 2a The sender does not know the Direct
address of the recipient.
– Requires that a HISP use a searchable provider
directory containing provider demographics.
(operations task)
– Defines a standard for Directory Services to query
a provider directory for a Direct address.
(technology task)
– Currently underway.
17
19. Concept of Operations
Trivial Case – Message to a local recipient.
– For most HISPs, this is functionality that exists today.
– Requires that there be a provider directory populated with
appropriate demographic information to perform a search.
NCHIN Directory
Operated by NCHIN 1. Fills out query form.
HISP 5. Retrieves Direct address.
6. Ensures recipient address is appropriate.
Audit Log Directory 7. Sends message.
Authorized
User
2. Searches local directory.
3. Locates matching entry.
4. Presents match to user.
18
20. Concept of Operations
Scenario 2a – Query another HISP.
Oregon LDS LDS = local directory service,
Operated by e.g. operated by a HISP
CareAccord HISP
Audit Log Directory
4. Logs received query.
5. Searches local directory.
6. Locates matching entry.
7. Sends response to NCHIN; logs sent
response.
NCHIN LDS 1. Fills out query form.
Operated by NCHIN 10. Retrieves Direct address.
HISP 11. Ensures the recipient address is appropriate.
12. Sends message.
Audit Log Directory
Authorized
User
2. Recognizes recipient not in local directory.
3. Sends query to CareAccord LDS; logs sent query.
8. Logs received response.
9. Presents match to user. 19
21. The standards…
SOAP: Robust web services standard widely
accepted for health information exchange.
HPD: Emerging IHE (LDAP) standard for
Healthcare Provider Directory data model.
HPDPlus: Emerging EHR | HIE Interop Workgroup
recommendation that adds more robust
organizational elements to HPD.
DSML: OASIS standard for querying an LDAP
directory.
S&I: Guidance on query for individual.
20
22. The standards…
SOAP: Robust web services standard widely
accepted for health information exchange.
HPD: Investigating an update to incorporate
HPDPlus functionality.
HPDPlus: Commitment of many industry partners,
plans to adopt / align with IHE
adjustments to HPD.
DSML: OASIS standard for querying an LDAP
directory.
S&I: Looking for experience of states
implementing provider directories.
21
23. Question
There is a concern over protection of PII.
• Should directory query be authenticated?
Yes, I want to know who is asking the question.
No, we should keep this simple. It is public information.
22
24. Question
There is a concern over protection of PII.
• Should directory query be authenticated?
• This is a technology question implementing a policy
decision.
• Currently, WSC approach is to include authentication
between directory systems using TLS.
– Note that individuals are NOT authenticated.
– There is an assumption of system/organizational trust, part
of “scalable trust”.
23
25. Question
We have said that we will log a query.
• What information should be logged?
Nothing.
Date and time, querying org, the query.
Date and time, querying org, the query, the response.
24
26. Question
We have said that we will log a query.
• What information should be logged?
• While the technology may be “complicated”, this is
really a policy question.
• Currently, WSC response is to log all queries and
responses, but reconsidering responses since they
include PII.
• Question for thought: What would you do with log
information?
25
27. Pilot Scenarios
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
Scenario 1 The sender knows the Direct address of the
recipient.
Scenario 2a The sender does not know the Direct
address of the recipient.
Scenario 2b The sender does not know the Direct
address or the HISP of the recipient.
26
28. The picture…
• What is Dr. Smith’s Direct address?
CareAccord, query IPHI, acting on
acting on behalf State State behalf of
of Oregon. California.
response
response
query
NCHIN, an HIO
operating a HISP
with a directory in
HISP
California.
27
29. The need for Scenario 2a…
Oregon LDS
Operated by
CareAccord HISP
Scenario 2a…
Audit Log Directory
• Requires knowledge of each
HISP in Trust Community.
4. Logs received query.
5. Searches local directory.
6. Locates matching entry.
7. Sends response to NCHIN; logs sent
response.
NCHIN LDS
Operated by NCHIN
HISP
1. Fills out query form.
10. Retrieves Direct address.
• Requires knowledge about
Audit Log Directory
Authorized
User
geography or customers
11. Ensures the recipient address is appropriate.
12. Sends message.
2.
3.
8.
Recognizes recipient not in local directory.
Sends query to CareAccord LDS; logs sent query.
Logs received response.
served by each HISP.
9. Presents match to user.
Scenario 2a • Is not scalable; requires
leads back to…
coordinating updates to
every HISP every time…
… a new HISP is added, or
… a HISP changes the
customers it serves.
28
30. The big picture…
Where we are headed…
California Statewide Provider Directory Oregon
SDS = state directory SDS
service
California Nevada
Hides complexity of SDS SDS
federation.
NCHIN
LDS Alaska
SDS
Hawaii
SDS
SD Beacon
RWMN LDS
SCHIE
LDS LDS
IEHIN LDS = local directory
LDS service
29
31. The big picture…
Where we are headed… Western States
California Statewide Provider Directory Oregon
SDS = state directory SDS
service
California Nevada
Hides complexity of SDS SDS
federation.
NCHIN
LDS Alaska
SDS
Hawaii
SDS
SD Beacon
RWMN LDS
SCHIE
LDS LDS
IEHIN LDS = local directory
LDS service
30
32. The big picture…
Where we are headed… California
California Statewide Provider Directory Oregon
SDS = state directory SDS
service
California Nevada
Hides complexity of SDS SDS
federation.
NCHIN
LDS Alaska
SDS
Hawaii
SDS
SD Beacon
RWMN LDS
SCHIE
LDS LDS
IEHIN LDS = local directory
LDS service
31
33. The purpose…
• Continue to test an emerging standard for Directory
Services query.
• Drive out additional requirements as a result of user
feedback.
• Address federation!
32
34. Who are we talking about?
• For the WSC, and for right now, California is
implementing a federated directory service.
– There are almost 30 HIOs operating in California,
with 5 separate HISPs.
– This complexity should be hidden from the
provider.
– The California state node stores no data; all
directory information is managed by local
directories.
33
35. Pilot Scenarios
Using Direct to exchange clinical information between
providers across state lines for treatment purposes.
Scenario 1 The sender knows the Direct address of the
recipient.
Scenario 2a The sender does not know the Direct
address of the recipient.
Scenario 2b The sender does not know the Direct
address or the HISP of the recipient.
– Builds on Scenario 2a.
– Addresses scalability by adding state Directory
Service and federation.
34
36. Concept of Operations
Scenario 2b – Query a state’s Directory Service.
California SDS SDS = state directory Oregon SDS Acts as an SDS and
Operated by IPHI/CHeQ service Operated by hides federation.
CareAccord HISP
Audit Log
Audit Log Directory
4. Logs received query.
5. Recognizes recipient not in California. 7. Logs received query.
6. Sends query to Oregon; logs sent query. 8. Searches statewide directory.
11. Logs received response. 9. Locates matching entry.
12. Forwards response to NCHIN. 10. Sends response to California; logs
sent response.
NCHIN LDS
Operated by NCHIN 1. Fills out query form.
HISP 15. Retrieves Direct address.
16. Ensures recipient address is appropriate.
Audit Log Directory 17. Sends message.
Authorized
User
2. Recognizes recipient not in local directory.
3. Sends query to California SDS; logs sent query.
13. Logs received response.
14. Presents match to user. 35
37. Concept of Operations
Scenario 2b – Query a state’s Directory Service.
California SDS SDS = state directory Oregon LDS Acts as both an SDS
Operated by IPHI/CHeQ service Operated by and an LDS.
CareAccord HISP
Audit Log
Audit Log Directory
4. Logs received query.
5. Forwards query to LDS(es); logs sent 2. Recognizes recipient not in Oregon
queries. 3. Sends query to California; logs sent
10. Logs received response(s). query.
11. Aggregates response(s). 13. Logs received response.
12. Forwards response(s) to Oregon. 14. Presents matches to user.
NCHIN LDS
Operated by NCHIN 1. Fills out query form.
HISP 15. Retrieves Direct address.
16. Ensures recipient address is
Audit Log Directory appropriate.
Authorized 17. Sends message.
User
6. Logs received query.
7. Searches local directory.
8. Locates matching entry.
9. Sends response to California SDS; logs sent 36
response.
38. The standards…
SOAP: Robust web services standard widely
accepted for health information exchange.
HPD: Investigating an update to incorporate
HPDPlus functionality.
HPDPlus: Addresses the need for complex
organizational descriptions within the data
model; not yet accepted or implemented.
DSML: Not designed to address federation; one
query to one directory.
S&I: Looking for experience of states
implementing provider directories.
37
39. Question
Federation allows for centralized or distributed policy
decisions.
• Should the decision to respond be centralized or
local?
Leave the decision with those responsible for the data.
Users have an expectation, so policy should be uniform.
38
40. Question
Federation allows for centralized or distributed policy
decisions.
• Should the decision to respond be centralized or
local?
• For now, WSC is adopting an approach of local
autonomy. Each state and directory operator should
be empowered to decide on whether to respond to a
query.
39
41. Question
We said we should log information about the query.
DSML does not support federation.
• What do you need to know about “who”?
I need to know the name of the individual.
I need to know the name of the organization (i.e., the HISP).
I need to know the name of the state.
40
42. Question
We said we should log information about the query.
DSML does not support federation.
• What do you need to know about “who”?
• For now, WSC is passing only the identity of the last
organization in a query.
– Oregon knows the query came from California.
– California knows the query came from NCHIN.
– NCHIN knows the query came from Dr. Jones.
41
43. Question
DSML does not support federation. You can only have
one response to a query.
• What do you do if someone errors?
Pass on all the matches there were. Sometimes the Internet fails.
Pass on the matches, but report an error.
I don’t know.
42
44. Question
DSML does not support federation. You can only have
one response to a query.
• What do you do if someone errors?
• This is a technical issue with user experience
implications.
• WSC is trying to think of the user.
– What would the user do with the information?
– Should errors be only an administrator’s issue?
– If a user didn’t get the information they expected,
would they just ask again?
• DSML doesn’t support the answer we like.
43
45. Question
DSML and HPDPlus support querying for members of
an organization. Directory operators are concerned
about protecting directory information.
• Should directory queries allow browsing?
No, you need to know enough to get a single response.
Yes, users are expecting to be able to browse a directory.
44
46. Question
DSML and HPDPlus support querying for members of
an organization. Directory operators are concerned
about protecting directory information.
• Should directory queries allow browsing?
• Must be controlled by policy.
• WSC decided that browsing should not be allowed.
• The first time a query was placed, the user asked “but
why can’t I get a list of the members”?
– Our users have an expectation.
– If we meet that expectation, we open the door to fishing.
• This is what pilots are for! 45
47. Question
DSML allows for a rich set of query capabilities.
Directory operators are concerned about protecting
directory information.
• Is there a minimum standard for wildcards?
No, we decided that should be left to the directory operators.
Yes, so the users know what to expect.
46
48. Question
DSML allows for a rich set of query capabilities.
Directory operators are concerned about protecting
directory information.
• Is there a minimum standard for wildcards?
• This is really a policy decision.
• For now, WSC has not established any requirements
for minimum data in the query.
47
49. Question
HPD and HPDPlus are complex. They may not be
uniformly populated. End users need to be able to
decide whether they can use the address.
• Is there a minimum standard for data that must be
included in a response?
No, any information is useful and the user is smart enough.
Yes, directory operators to create good directories.
48
50. Question
HPD and HPDPlus are complex. They may not be
uniformly populated. End users need to be able to
decide whether they can use the address.
• Is there a minimum standard for data that must be
included in a response?
• This is really a policy decision.
• For now, WSC has not established any requirements
for minimum data in the response.
49
51. Challenges
1. Single vendor implementation.
– Few are implementing HPD, HPDPlus, and/or DSML.
– Exploring Directory Services testing with another vendor.
– Participating in national conversations to harmonize query
standards.
2. User experience design.
– Many things are possible…
3. Policy implications of technical design decisions.
– There is an (unfortunate) opportunity for technology to
drive policy.
This is hard!
50