RESTful Health Exchange (RHEx) WebEx Discussion Log

taupesalmonInternet and Web Development

Oct 21, 2013 (3 years and 7 months ago)

114 views

RESTful Health Exchange (RHEx)

WebEx Discussion Log


WebEx Discussion Log

Introduction



Anne Kling
(presenter)

has been working on the data architecture behind RHEx



RHEx Orientation

o

RHEx is an open source, exploratory project to apply proven Web technologies to
demonstrate a simple,
secure, and standards
-
based health information exchange

o

Sponsored by FHA for FY12 to inform a path forward for a RESTful health data exchange

o

Phase 1 has concluded and now we’re starting to get into the Content approach for
Phase 2



Phase 1 dealt with the s
ecurity and transport of health information


now we’re going to go
over ‘what’ we’re securing and transporting



Within the architecture stack


content organization vs. content payload

o

Content organization is how the content is managed


rules and standar
ds

o

Content payload


what data will be exposed


semantics

Content O
rganization



Establish traversable hierarchical organization of data

o

Have links to discover what data is available to use, then utilize RESTful links



Provide common structures of interact
ion to apply RESTful principles



Options

o

Atom publishing protocol (AtomPub)


original Web 2.0 for publications and posting on
Web resources

o

Open Data Protocol (
oData
)



Extends AtomPub



Data represented by Entity Data Model

Meeting Name:

RESTful Health Exchange
Content Approach WebEx

Date:

August 23
,

2012

Time:

11:00 am EDT

Facilitator:

Anne Kling

Purpose:

Review RHEx’s content approach to exchanging health information

Key Takeaways

from Discussion

1

RHEx’s content organization based around common structures to apply RESTful principles;
AtomPub, oData, hData

2

RHEx content payload leverages existing standards; HL7 (CDA, V2.x, 2.6 REF_I12, V3),
CCDA,
greenCDA,
DICOM



Provides specificity at the field
and data type levels



Not healthcare specific

o

hData



Similar to AtomPub, but more
constrained



Data can be represented using multiple standards



Provides specificity at the granular document levels



Developed with healthcare domain in mind



Hierarchical structur
e supporting linked documents



Provides a means for discoverability

of changed content



Can interoperate with other protocols



OData can be integrated in hData hierarchy

Content Payload



What data do we want to expose?



Establish common data model for exchange


provide semantic and
syntactic

interoperability



Want to leverage existing standards



Provide extensible solution to manage multiple data standards



Align content with use case


TATRC Pilot Use Case



Healthcare Standards

o

HL7 CDA



HITSP C83/80/154/32



GreenCDA

for C32

o

HL7 2.6 REF_I12

o

HL7 V3



REPC_MT210001UV

o

Consolidated

Clinical Document Architecture (CCDA)

o

DICOM

RHE Content Approach in TATRC Pilot



TATRC Pilot Motivation

o

Pilot is designed to develop proof of concept for a World Wide
W
eb model for health
data
exchange



Test application of REST to health data
exchange



Help address NwHIN Power Team recommendation

o

Worked with selected
federal

partners to identify critical capability gap and select a
prototype use case



Consult results are not consistently sent to PC
P today, impacting healthcare for
Veterans and Service Members

o

Phase 1 talked about the security approach to RESTful information, Phase 2 designed to
evaluation Content Organization and Payload Concepts



There are additional steps in the industry


simplifi
ed for the pilot



PCP generating and extending the direct message with a link to the
Consulting Provider (
CP
)

for
the consult request

o

Phase 1 demonstrated as a single link to a pdf consult request

o

In Phase 2 talking more granularly



A
dditional links to clin
ical information to support consult request



5 domains being captured in the clinical consult

o

CP can view and interact with information


if they have a system to do this, they can
copy the link

o

CP has acknowledged and performed the requests and can send i
t back to the
Patient
Consulting Provider (
PCP
)

via URL with appropriate clinical information

o

Gain secured access to necessary information that occurred with consult



Context

for the Pilot

o

Designed to summarize a patient’s electronic health record for the p
urpose of clinical
consultation

o

Components

were modeled to support pilot use case:
specialist

consultation



Content Organization choice

o

Hybrid approach



Patient data is organized into an hData Record on the CP’s HER



Each section has zero or more entries



URI
links are used for authorized patient record data access



Patient is exposed as links to greenC32 representations on PCP HER

o

Content

Payload



greenC32 schemas used as content payload



hData Abstract Content Model

o

Expose data at root xml level

o

In the possibili
ties you could mix coarse documents like pdf or .com images


would be
stored in document feed

o

Where we’re focusing is the granular parent feed and granular section feed

o

Patient would have pr
ocedures, results, and medications


off that would be individua
l
entries

o

OData could be implemented as a Section Feed

o

URIs can point to DICOM images or granular patient data, such as
allergy

or
medication

o

Each document and feed will have its own URI



Coarse Grained Link

o

Specific patient record


coarse document feed


section document

o

If EHR wants to expose C32 as a complete document then it would use coarse grained

o

Each C32 would be its own resource underneath the feed



Granular Content Link


what’s being used in the TATRC pilot

o

Patient record


parent feed


granular

section feed


section document



How did we come up with the schemas
?

o

Different than schemas currently being used

elsewhere

o

Looked at use case and reviewed existing data standards

o

Looking towards data already available

o

Identified the section that would
b
e
necessary for us

o

Applied greenCD
A

process and methodology to produce hData extensions

o

Each procedure has its own extension that relates to schema

o

Main difference between these
extensions

and schemas being used on TATRC side is
the
granularity

o

Data
being
exposed on the granular entry level

o

Created
RDDL

document which speaks to the semantics and description of the
data

o

Within our implementation for hData server we can expose and serialize these schemas
for JSON
,

XML or
hData



Summary

o

RHEx Content Layer inclu
des Content
Organization

and Content Payload

o

Concepts for Content Organization and Payload are being evaluated in the TATRC Pilot



Hybrid approach to Content Organization



hData is used as the Content
Organization

for RHEx at CP

o

Support multiple data standar
ds

o

Developed

with healthcare domain in mind



GreenC32 used for Content Payload

o

Builds on existing standards

Questions from the Audience



Would it be possible to assemble a list of top 5 links, white papers or documents that were most
helpful then post them o
n the Wiki

o

We can look into doing something like that

o

We’ll be posting the Content Profile soon


if there’s anything missing we’ll come back
to this



What happens after link is clicked?

o

D
epends

on how app wants to handle it

o

On hData side
we

leverage the fu
ll use of http as sub header

o

T
he goal would be if a user in the browser clicks on the link
,

they would be able to see
an html view

o

I
f they look at a patient record they

take
link fro
m
the
direct message and put it into
critical
software
, then they could use different
JSON or Atom

feed representations

o

In the future, there could be in
box processing happening on the direct message so the
client can pick
the
link out of
the
direct message and request i
nformation straight from
there



A

number of standards
may have been missed
targeting access to health data

o

Some standards are being missed
, not THE approach but it Phase I work would be
applicable to these standards as they gain traction

o

For example, Fire. RHEx was a little ways down the

road when it came out, but we’re
keeping our eye on it.



RHEx’s approach to the

security layer is
great because it is harmonious with the transport layer,
and many of these standards are not mature enough
to profile with
these standards.
Up until
this poi
nt, very happy
with
the way things were coming together because the transport
specifications are being coordinated through the security layer
.
Coming out with hData and
ignores other work is disheartening

o

On the MITRE side the goal was to implement hData a
nd remain as true to that spec as
possible

o

On TATRC the goal was to start with an hData approach, but with the scope of the
project the goal was to get something working in a RESTful manner

o

The way we’ve been thinking about it is to explore the spectrum

o

If

we have machine understandable structure and loose standards


trying to explore
the space and see what makes sense

o

Two separate workflows, with TATRC we’re using the 3 legged workflow where the user
is in the loop



Two pieces of software preconfigured tog
ether then it would be two legged

o

The user is the resource owner



When they follow the link, the resource owner would see that
you’re

logged in,
then select IdP the resource t
rusts, then log in via Open ID



O
nce logged in by resource host, then the client ge
ts an OAuth2 token



Even if you’re not a resource owner, you have access

o

In this example the trust being developed
is
between EHR system an
d

the

particular
user


how does the system know what EHR to link to


is it any user has access to any
data


or is t
here a way to say that ‘Bob Smith’ has access



Trust relationship is between
IdP

and resource host


set up ahead of time


a
resource host can decide what
IdP

to trust


left up to an organizational basis


very similar to Direct (
IdPs

similar to HISTs)



Ba
sed on whatever rules you want to have in place



Up to resource host how restrictive they want to be



What OpenID Connect delivers is the information needed to make an
access control decision



As a resource host you can say that person x has logged into certa
in
host they trust



The
IdP

can ask for additional information


then write whatever access
control rules you want

o

In practical terms


would it be workable for implied consent



It will most likely be individuals and roles at individual facilities



It might
be a sub
-
department within



These are policy issues, and we’re focused on the technical side



Direct trust relationships are nicely distributed


the standard use case is bilateral trust


could
RHEx get this kind of trust network


o

In OpenID Connect there is

a notion of bilateral trust

o

Justin Richer could talk about trust networks you can set up with OpenID Connect


if
you post this on the Google Groups you will get a more in depth response



If you are assuming that the
IdP

is a HIST, would it be simpler in a

restricted sense to have the
HIST sign the link when they present it to the resource provider. As long as the resource host
gets a link signed by the destination of the Direct message


they would consider that to be
sufficient, is that plausible

o

Would ha
v
e

to think about that


signing a link on the return would be difficult

o

One downside would be that it would make a user in a browser use case more difficult

o

The Direct message goes to a HIST, the user signs into the HIST but the HIST itself has
access to
the private key


don’t understand the browser point



The user would be logged into the HIST then at that point the HIST could format
the URL to have different information in it



A lot of HISTS


the one in
Massachusetts



are providing a mail interface for
their user



Good suggestion


don’t have it worked out off the top of the head


can you
fast track someone’s access if you already know they’re logged in


can you pre
-
log them into another site



If you’re assuming the message goes out from Direct to a HIST

---

the duck test
would say that you have all the pieces in place, then why don’t you need
OpenID Connect



Dangerous since the source is presuming the RESTful service sent through an
email would never go anywhere else. Dangerous decision to make for a serv
ice
provider. The user does not need to be
bothered

by the challenge for
authentication since they are
already logged in to the HIST



Don’t try to expose the expectation on simplified web interactions



From the user it may be seamless


the resource host tha
t has to
interpret the attributes of the log in user and make those decisions


you’ve created something that’s flexible


can’t avoid the feature of
forwarding messages


not saying it’s a substitute but eliminating the
wait of the decision process on the

resource host would simplify the
implementation in certain cases



The simplification would present the vulnerability

o

The link could end up somewhere else


the service host is not
in control of that link once it has gone out

o

Only the HIST can sign the link

o

The signed link doesn’t buy you anything


if OpenID Connect is
your identity provider, what will happen is that it’s messy on the
network but it will redirect you to your
IdP

and it will say that
you’re already logged in


then it will forward along your

identity information


a lot of back and forth but at the end of
the day you would just show up at the site

o

In a RESTful model where that link might take you to a
document that has other links


would it be overkill if you use
links for that remote relyin
g party application

o

That raises an interesting content question because of the
mapping of c32 into segmentation strategies


understand that
once you know whose logged in, then you can ignore the
consent issues



Anticipates some of the work we’ll see for
segmentation for privacy
initiative