American Health Information Community

Consumer Empowerment Workgroup Meeting #16

Wednesday, May 2, 2007

**Disclaimer**

*The views expressed in written conference materials or publications and
by speakers and moderators at HHS-sponsored conferences do not
necessarily reflect the official policies of HHS; nor does mention of
trade names, commercial practices, or organizations imply endorsement by
the U.S. Government.*

**[\>\> Matt McCoy:]{.underline}**

Okay, Judy, you can go ahead.

**[\>\> Judy Sparrow:]{.underline}**

Great. Thank you, Matt, and welcome, everybody, to the sixteenth meeting
of the Consumer Empowerment Workgroup. A reminder that we operate under
the auspices of the Federal Advisory Committee Act, the Workgroup
proceedings are being conducted in public, the public will have an
opportunity at the end of the meeting to make comment. For those of you
Workgroup members on the telephone, remember to speak clearly and
distinctly and identify yourself. And also, put your phone on mute when
you are not speaking. We have a jam-packed agenda today, so I think
without much further ado we'll head into it. Rose Marie Robertson, one
of our co-chairs, is on the line, and Nancy Davenport-Ennis will be
joining us shortly. So Rose Marie, would you like to begin?

**[\>\> Rose Marie Robertson]{.underline}**\
Judy, thanks very much, and welcome everyone. As members of the
Workgroup recognize, in the period since our last set of deliberations
we've been thinking about the process that we should follow in terms of
interacting in some of our activities with the, with some of the other
Workgroups, particularly the CPS, Confidentiality, Privacy, and Security
Workgroup, in moving forward the areas for recommendations that we
brought forward. We also will be having a change in our support staff,
and we'll be talking about that some as well. And we have put together
for today a series of presentations of where a number of these tasks are
at present so that the group can begin to work on the process that we
will take moving forward in forming our next recommendations and in
being certain that we manage to accomplish in the next period of time
the charge that\'s been given to us for, before the AHIC migrates to
what will perhaps be a different format moving forward at the end of its
current existence. So we have a number of presentations planned for
today, and Judy, I don\'t know how many of the presenters are there
in‑person and how, and if ‑‑ Kelly was leading this off. And is she, is
she with us currently?

**[\>\> Kelly Cronin:]{.underline}**\
Yes, I am.

**[\>\> Judy Sparrow:]{.underline}**

And actually I neglected one thing. We should probably introduce the
members, not only here at the table at ONC but also those on the ‑‑

**[\>\> Rose Marie Robertson:]{.underline}**\
Absolutely. Let\'s do a roll call, if we can.

**[\>\> Judy Sparrow:]{.underline}**\
We will begin here. We have \--

**\
[\>\> Kelly Cronin]{.underline}**[:]{.underline}

Kelly Cronin, ONC.

**[\>\> David Lansky:]{.underline}**\
David Lansky from Markle.

**[\>\> Justine Handelman:]{.underline}**\
Justine Handelman, Blue Cross Blue Shield.

**[\>\>]{.underline}**\
\[Inaudible\], Surescripts.

**[\>\>]{.underline}**\
\[Inaudible\].

**[\>\> Christina Collins:]{.underline}**\
Christina Collins, AMA.

**[\>\> John Casillas:]{.underline}**\
John Casillas, Medical Banking Project.

**[\>\> Judy Sparrow:]{.underline}**\
Okay, and those on the phone, please.

**[\>\> Matt McCoy:]{.underline}**\
Sure, Judy. On the phone today we have Jayne Orthwein from NIST.
Lorraine Doo from CMS. Jason Bonander from CDC. Robert Tennant from
MGMA. Our co‑chair, Rose Marie Robertson, from the American Heart
Association. Davette Murray from DOD. Mike Kaszynski from OPM. Paul Tang
from the Palo Alto Medical Foundation. Mark Boutin from the National
Health Council. Kim Nazi from the VA. JP Little from RxHub. And Charles
Safran from Harvard Medical School. And Kat Mahan from Surescripts. Is
there anybody who I did not mention?

**[\>\> Steve Parente:]{.underline}**\
Steve Parente, University of Minnesota.

**[\>\> Steve Downs:]{.underline}**\
Steve Downs, Robert Wood Johnson Foundation.

**[\>\> Matt McCoy:]{.underline}**\
Okay. Sorry about that. Judy, I think we are ready to go.

**[\>\> Judy Sparow:]{.underline}**\
Kelly.

**[\>\> Kelly Cronin:]{.underline}**\
Yes, I think ‑‑ Rose Marie mentioned that we have some change in to how
we are supporting this Workgroup. So perhaps I will just give a brief
update on that before we jump into the content of the day. I think as
you all know, when we first established the working groups under AHIC,
we had, we realized it was going to be a lot of work across a lot of
public meetings, and that we were going to have pull from resources
across ONC and also with some of the federal agencies to really
adequately give you the support you need to do work and develop
recommendations. And when we first got going, Karen Bell and I short of
shared the responsibilities across Workgroups to try to make sure we
work closely with co‑chairs in developing agendas, and coordinate with
everything else that is going on and also really try to provide the
staff support needed.

And Karen Bell, as you know, is the physician that heads up the
Office of Health IT Adoption here, who really is going to be very much
engaged in pilot projects around personal health records and doing a lot
of activities related to personal health records in general. And you've
probably also heard that we are now in the early planning stages of what
the governance entity might look like if it were operating in the
private sector. So sort of the next phase of AHIC‑like activities that
would not be considered advisory committee per se but really would be
more of a formal governance entity. And because we are really now going
to be asked to sort of take that on in addition to our other
responsibilities, it looks like Karen Bell will be playing the role I've
played with this Workgroup over the last year and a half, and we'll also
be getting additional support staff in to really kind of help you all
get to the next phase of your work. So she\'s not able to be with us
today since she just started a vacation, but she will be here the next
meeting. And we will give you a more definitive update then in terms of
her involvement and also the other staff that will be involved as well.
Are there any questions about that? Okay, great.

**[\>\> Rose Marie Robertson:]{.underline}**\
Sorry, I just would want to say that, you know, your support for this
Workgroup, although I\'m a newer, newer member to it, has really been
spectacular. And I think the, both the time and the expertise that Kelly
has brought to this, is really extraordinary. So I just want to, want to
voice that specifically. And we know that Karen will take good care of
us. But we are very, very appreciative of the time and effort Kelly has
put into this.

**[\>\> Kelly Cronin:]{.underline}**

Thanks so much, Rose Marie. It is really been great to work with you and
Nancy. And I think you will in good hands, no matter what happens here.
But we will definitely have a good team behind you.

So in starting off our discussion today, I thought, in trying to plan
the agenda, Nancy and Rose Marie both thought it would be helpful to
have some context, maybe have an overview of what we know is going on
now across the country in terms of Health Information Exchange. And also
touch a little bit on our plan for the NHIN as it relates to consumers
in particular since much of what we want to cover today is sort of, you
know, what is, what else is going on in the landscape. We did a nice
environmental scan and had the benefits of learning from that over the
last six months, but it didn\'t really get into some of the issues
around RHIOs, health information exchanges, the future of the NHIN, what
the role of data intermediaries might be moving forward, what medical
banking is and how might that influence the development of the market,
and what are sort of the scope of all the evolving technologies and how
might that really be impacted in a positive way, and what are the risks
that we should be aware of moving forward.

So as opposed to being sort of vendor-oriented, as we had been in our
last environmental scan, looking at a variety of applications that are
already on the market, I think this will, today will really provide us
with a good opportunity to think more about the future directions and
what health information exchange, either at a regional or perhaps even
at a national level, might mean for consumers and getting access to
their information.

So with that in mind I thought it would be helpful just to start off
with some definitions. Because as I think as everybody knows, we have
not only been acronym challenged in recent years, we tend to use names
so interchangeably that it confuses everyone. While I think the
term Regional Health Information Organization was used very broadly in
the \[inaudible\] framework back in July 2004, and still really is
probably the name that most people use, it is also very commonly
referred to, increasingly referred to, I think probably because the NHIN
is now getting more traction, as Health Information Exchanges. You can
use that as a noun or a verb. The noun is the entity overseeing these
activities, and the action of health information exchange is sort of the
actual flow of data. But for the purposes of our, at least this initial
discussion we really wanted to try to set the context for what we mean
as an organizational or entity level. In the NHIN trial implementation
this year, we will be referring to HIEs as multi‑stakeholder entities
that enable the movement of health‑related data within a state,
regional, or non‑jurisdictional participant groups. So there is a lot of
other definitions that have been proposed over the years. I think Kim
had a pretty robust group together that was trying to agree on a
definition last year. I am sure that we will get to one that everyone
can feel comfortable with over time, but in terms of a working
definition for our discussion, we can sort of look to this. And then a
newer definition we are also trying to use again more or less for
practical purposes because we are going to be funding trial
implementations is associated with the Nationwide Health Information
Network and health information exchange in that context, which would be
an HIE that implements the NHIN architecture which includes services,
standards, and requirements, processes, procedures and also one that
participates in the NHIN cooperative. So a group of these organizations
that will be all convening and meeting together and sharing their
learnings, how to be building this network of networks.

So we often use this concept of network of networks because so much of
what\'s happening across the country are regional or now increasingly
state-level efforts that are, I think, aware of the fact that they are
going to have to be connected and obviously be building an interoperable
platform. But right now, there is, there has not been a lot of
demonstration of that interoperability across regions and states. So
what we want to see over time and try to really demonstrate this year is
the ability for these different regional networks or regional entities
to be sharing data with each other, and focusing on the interfaces that
are needed and the data sharing arrangements that are needed to enable
that. So we are not just connecting providers across settings of care
within a given region, but you would also be connecting providers across
states as needed. You can also be collecting that data through record
locator services or other technologies and housing that for consumers.
So in essence this becomes connectivity for consumers, too, or one point
of access for them.\
\
So I think we\'re really hopeful that in this next year, as we start to
get a little more experience with this, and there is also going to be
some competition for funding, that a market will start to develop for
these kinds of services. You know, small vendors, system integrators,
you know, we would hope that it is going to attract a real variety of
people that might offer these services, either in suite or individually
marketed, but that it will become a more robust market over time as the
demand is understood. And we really want to try to secure a foundation
for growth innovation over the next couple of years.

So what is the status currently across the country? I think a lot of
people have heard about the hype around RHIOs and HIEs. And certainly we
know roughly 140 of them that exist now. eHI has been doing a survey for
the last couple of years. And even though it is self‑reported data, it
does indicate there is a lot going on across the country. But a lot of
it still could be considered in the planning phases. They are not really
operational in sharing data. There are, there is a subset that is
sharing data at this point and they have worked out the hard staff,
which is really building the trust and relationships that are needed so
that hospitals feel comfortable sharing data, providers, other providers
in the region or in the catchment area are comfortable with the whole
arrangement, and they can know that the data will be held responsibly.
So they are getting to the point where there are increasing numbers that
are getting to an operational state. Many of them are offering results
delivery or clinical messaging, so lab results or radiology or
medication history is also becoming increasingly a starting point.

And there are only, what we know of now, there is only a handful, less
than 10 that are truly making enough money to be considered sort of on a
path to sustainability. So one of the big obstacles that we have
recognized over the last few years is really what is that revenue
stream, where does it come from, what are the initial value-added
services that are easy enough to do out of the box, that are not too
technically demanding as you are just getting started, but that people
are willing to actually write a check for. So we are really starting to
get a better handle on that, even though there is really not that much
experience to draw from at this stage. And then we also recognize the
importance of really trying to, out of all these activities that are
going on, understand what\'s working, what\'s not working, what are some
emerging best practices as there is more experience. We have been
funding an effort to do this at a state level. So figuring out, out of
the state public/private partnerships that are forming, some of them are
taking on statewide projects like a master patient index. Others are
really acting in a more coordination or oversight way. But what are the
best models for governance, for financing, and for data sharing
policies? How do they make that work, and what will likely work across
regions and states over time to build this network of networks?

So more recently, in getting ready for this next round of procurement
with the NHIN, we have been really thinking a lot about consumer
capabilities and really specifying what\'s really important to enable
consumer control and to be able to demonstrate, get some real empirical
evidence in this next one or two years on how we can ensure that there
is an appropriate role for consumers and that protections are
incorporated. So we have been focusing on some key consumer services,
including identifying a personal record home for consumers. Allowing
them to search other places where their data exists. So, say, they
receive care across four different hospitals and five different
physician offices over a 15 year period, and it\'s relevant to their
chronic condition, they should be able to query and obtain that. They
also should able to control who can access their records, their personal
health information, view who has actually accessed their PHR, or have
made lookups, or noticed how, or can view how their data had been
disclosed. They also should be able to request changes that need to be
made when they notice an error or something that requires some kind of
modification. And then also just as important, they should able to
choose not to participate. If they are entirely uncomfortable with their
data being shared across the network, then they should be able to simply
say, I don\'t ‑‑ and be informed about what the real risks and benefits
are, but really be able to, as a lot of people refer to it, opt out.

So in the trial implementations this year we hope to have at least two,
maybe more, sites where the consumer empowerment use case will be a real
focal point. And I think it will provide us with some really good
experience to learn from and hope to get those awarded over the summer
so that not only this Workgroup, but really the larger community can
really start to figure out what might work and not work. So we will be
getting our request for contracts out in the next, I imagine, days, if
not weeks.

So that\'s sort of some general background information. And I think the
more interesting discussion and presentations will follow. So, Rose
Marie, do you want to open up for discussions or do you want to go right
on to Steve Parente?

**[\>\> Rose Marie Robertson:]{.underline}**

Kelly, let me just check one thing. Is everyone who wants to be in by
Webcast able to get in? I know some of you are there in‑person. I\'m not
sure if ‑‑

**[\>\> Charles Safran:]{.underline}**

This is Charlie Safran. Can I ask Kelly a question about the ten sites
that are up, that have business models running?

**[\>\> Rose Marie Robertson:]{.underline}**

Let me just make sure this technical thing is addressed. So any
difficulty in getting into the Website? I ask because I\'m having
difficulty getting in.

**[\>\>]{.underline}**\
We\'re not having any difficulty on our side.

**[\>\> Rose Marie Robertson:]{.underline}**

If it is only me, I will make do with the PowerPoints I have in my
e‑mail. So, sure, let's go ahead with, let\'s go ahead with that
question.

**[\>\> Charles Safran:]{.underline}**

This is Charlie Safran at Harvard. Kelly, of the sites that are up that
have, you say a revenue stream. I\'m just wondering if you could break
that down and specifically, have any of them tried to make money by
reselling their data to pharmaceutical companies or others? Do any of
them have advertising models so, you know, sort of the re‑use of data?
How are they making their money, I guess, is the question. And I think
that\'s probably relevant from the point of view of this committee.

**[\>\> Kelly Cronin:]{.underline}**

Yes, that\'s a good question, Charlie. None of them are making money
from secondary uses of data. And I think that we all recognize the need
to get more clarification around the necessary policies to protect
consumers\' interests regarding that. Clearly the NHIN cost and revenue
models that represented across the four consortia back at the beginning
of the year, they did rely heavily over time on revenue from secondary
uses, so either from research, it could be getting access to data for
pharmaceutical-sponsored research or post‑marketing surveillance, it
could be data being shared with other organizations that want to
aggregate and analyze data for quality measurement and public reporting.
There is a whole host of secondary uses that could be I think down the
road revenue sources. What we evaluated through some work that some
folks in Regenstrief and AHIMA looked at last year were sort of fixed
operational RHIOs. And they sort of did case studies of them, trying to
figure out what are the services they are offering, how are they making
money, is it sort of pay for transaction, is it a membership based fee?
And the results we have on our Website, which we could get into in a lot
more detail. But essentially the majority of them were starting off
with, or making money from clinical messaging or results reporting. I
think it\'s been noted in general that hospitals tend to be engaging and
finding value in receiving those kinds of information, and they are
willing to pay for it. I think that medication history was also
recommended as sort of a good initial starting point, that there is a,
some inherent value and people are willing to pay for that. And then
they also looked at sort of the value of having a complete patient
record available to clinicians over time, and quality measurement, as
well as some other more complicated or more complex services.

And essentially what they found after looking across six of them, and
again it is not a huge amount of experience, but they recommended that,
starting off, it makes sense to try to, both from a technical
perspective and from where the market is, what the market might demand,
to start with clinical messaging or results reporting. And then
potentially also medication history, and then build from that to go to
the services that require more complete data sets, that are of high
enough quality, that have enough standardized data that you could do,
you could contemplate using it for either quality measurement or having
a complete patient record or potentially using it for different kinds of
research, as appropriate.

So I think the details are probably, you know, in the report. But we
know that there is really not a huge amount of examples to follow. I
think clearly Indiana, and Indiana Health Information Exchange has had
the most experience. To date they have, I think over 50 employees now.
And they are in the black, making money, delivering valuable services.
But that may not be, you know, the model to follow for the rest of the
country for many different reasons.

**[\>\> Rose Marie Robertson:]{.underline}**

Other questions for Kelly?

**[\>\>]{.underline}**\
I have one here. I just was wondering about the request for contracts
and the trial implementation? In \'06 when the NHIN architecture were
being built, the contracts were mostly technology vendors that brought
in stakeholders. This is a little bit different in terms of trying to
really test, and it\'s going to require true collaboration among many
stakeholders. Is the view again, or is it wide open, that it would be
technology vendors that bring together organizations, as was the case in
the previous contracts and building upon those efforts, or is it wide
open as to anyone who can come to the table that ‑‑

**[\>\> Kelly Cronin:]{.underline}**\
Yes. We will be targeting, we're intending to actually contract with
regional and state level organizations that will be more, really
overseeing the efforts and likely then contract with however many
vendors they feel they need to. The focus much more is at the entity
organizational level this time. And then really the concept of the
network of networks will be really starting at that point. So it is not
technology-, vendor-, or firm-oriented. It is really going to be up to
the organizations to then contract for those services so that they can
really decide what would be, either building off of their already
existing, what their market share already is, or deciding to do
something different, depending on what the needs would be to connect
across the region.

**[\>\> David Lansky:]{.underline}**\
Kelly, can I ask a question on the slide on consumer services within the
NHIN?

**[\>\> Kelly Cronin:]{.underline}**\
Yes.

**[\>\> David Lansky:]{.underline}**\
Can you explain what the first one means? A personal health record home,
is the idea of a service. And also just the entire group, how are you
thinking about these? Would these for example be turned into rules or
requirements for the NHIN trial content or are they just your sense of
what\'s happening in the marketplace?

**[\>\> Kelly Cronin:]{.underline}**\
No, I think it is really, it is built into what we expect to see
happening in the next one to two years through the funding, through the
trial implementation. So both through guidance and the use case, and in
how data sharing arrangements are drafted, we hope to try to enable a
lot of these concepts so that a consumer can have the ability to, for
the record locator service, for example, to security and other kinds of
providers (inaudible) to be able to get access to all their history.
They should know whether personal health record can be accessed so is it
on a Website, or is there a definitive place for them to go to, to be
able to access that. This is one point of access. They should clearly
have decision‑making ability to not participate. And again, there needs
to be a lot more exploration, explicit policy in that area. We are not
trying to turn policies at this point in time that would be, you know,
sort of lasting policy for the long‑term. I think we are looking at
trying to incorporate what are hopefully really requirements or key
functionalities that will empower the consumer, and then we can evaluate
that experience as we go along.

**[\>\> David Lansky:]{.underline}**\
So that first one, personal health record home, is that what you meant
by having a definitive ‑‑

**[\>\>]{.underline}**\
Yes. And I think it is also ‑‑ I\'m not the best person to
\[inaudible\] ‑‑ because I\'m not overseeing this work right now. But in
terms of a conceptual level, we want consumers to feel like they have a
home or a place for their personal health record and they understand
what ‑‑ and I think the details will be worked out as we \[inaudible\]
the RFD now and start \[inaudible\].

**[\>\> Rose Marie Robertson:]{.underline}**

And actually, I suspect that some of the same issues, you know, it might
be timely to move on to the next two testimonies because I think some of
the same issues about control of data and where data sits are relevant
to electronic medical banking. We thought this would, that this could
help us understand how things have worked in another related area. And
obviously medical, there is medical banking. There is, there are issues
in terms of how other parts of industry have dealt with some of this.
And we have asked Steve Parente from the University of Minnesota to be
our next testifier. So, Steve, should be we turn to you?

**[\>\> Steve Parente:]{.underline}**

That would be great. I\'m a little new to advancement so do I give you
guys a cue to advance the slides? Is that how we do this?

**[\>\> Rose Marie Robertson:]{.underline}**

Just say next slide when you are ready.

**[\>\> Steve Parente:]{.underline}**

Well, thanks very much for this opportunity. Some of you may know I\'ve
been doing a lot of research for the last five years on
consumer directed health plans, and one of the things that\'s become a
variant to that is focusing on medical banking and the overlap with
personal health records. And just from the outset, this is certainly an
external, I guess, reviewer to this. It seems to be one of the more
interesting things that\'s coming down the pike with health IT and it
may be too good to be true, but it seems to have a lot of promise. Most
of my research has been funded by the Robert Wood Johnson Foundation
since 2002. Want to give due note to the Health Care Financing
Organization initiative as well as support from DHHS as well as Pfizer.
If we can go to the next slide.

So what I would like to do is give a sense, from my outsider\'s view, of
what a medical banking PHR could do, this is going to come in part,
looking at this as a health economist, also looking at it from someone
who is a consumer and actually use some of the consumer-driven products
as a consumer. I want to give you a sense of what, whether this could
really be a viable platform and what do I mean by being a platform.
There is a pretty dense scenario I\'m going to walk you through as
quickly as I can. These slides will be posted up, I know here, but also
on my own Website, ehealthplan.org, if you want to go into more detail.
I just want to walk through one patient's example of how this could be
used in different ways. And then sort of make a bit of a case for, this
is a little more normative than I like to be, of why this really might
work. Maybe as a plan B, but there is just a lot of traction points to
it that make it kind of an interesting thing to, at the very least, keep
an active eye on. Next slide.

So what\'s the vision for these? The idea behind personal health records
in general, as most folks know on the call, is that these are a personal
and portable resource for patients and their families to use in the
long‑term. They can be as simple as scanned images that are available
for folks online in case of emergency, with some personal information
down, maybe a do not resuscitate order and other components like that.
The idea is this will be a critical resource for folks to improve their
health and aid them in long‑term care issues. The issue about long‑term
medical care affordability is something I will come back to in a second,
but it could be used for that as well. One of the most cogent examples,
people like these PHRs is that it essentially will give emergency access
for critical information. If someone comes unconscious to an ER, the
hope is that there would be some way to identify that person, get that
information back out to see what\'s going on. And, or in other
situations, if there is issues about strong preferences, those can at
least be noted someplace. And it really allows, unlike, say, a standard
electronic medical record, a chance for the consumer to personalize
their preferences. Next slide.

This is actually a graph, and, David, you are on this call I take it?
David Lansky? I will just assume he has the mute button on.

**[\>\> David Lansky:]{.underline}**\
I\'m here, Steve.

**[\>\> Steve Parente:]{.underline}**\
Yes. This is, I don\'t know if David remembers. This is actually from
the eHealth, actually SimHealth software from 2002, 2003. And, David, I
would like to formally put in a request to buy the copyright for this
picture, because I use it far too often, and you guys should deserve
some money. I\'m semi-serious because I just cannot get my graphic
designers to ever replicate this, even though it is from basically Maxis
Corporation. In any case this is actually, some of you remember way
back, health reform back then, this is actually from a policy simulation
game. What I loved about this was it pointed to all the different actors
or agents that are involved in the healthcare economy. It is just a huge
group of folks. And this is a very simplistic view of this. But when we
think what\'s actually built electronically in terms of data transfer,
the places that are the cleanest are between the insurers and the
physicians, and the insurers and the hospitals because of, essentially,
electronic billing. By insurers there, I\'m thinking mostly of Medicare
but a lot of the commercial insurers have tremendous amounts of stuff
that is running electronically. There is a dotted yellow line that runs
between the physician and the hospitals, which really gets tp integrated
delivery systems when it\'s all one roof like Kaiser, or when it is a
little more disaggregated as well. Everything in red is essentially
what\'s to build. What\'s fascinating about this notion of the PHR
through medical banking is that at least as we are touching the
consumers, and as you can see we touch a lot of the consumer, or at
least the small business, market here, this does give you a portal to
operate all this, as well as another portal into the insurers and the
providers for billing purposes. And in a sense it touches more lines
without directly trying to make it as an agenda than many, many of the
things that are on the market today. Next slide.

Okay. So I actually like this idea enough to ‑‑

**[\>\> Rose Marie Robertson:]{.underline}**\
Steve, one question on that last slide.

**[\>\> Steve Parente:]{.underline}**\
Sure.

**[\>\> Rose Marie Robertson:]{.underline}**\
The income, the income designations.

**[\>\> Steve Parente:]{.underline}**\
Yes.

**[\>\> Rose Marie Robertson:]{.underline}**

Could you just explain what those are?

**[\>\> Steve Parente:]{.underline}**\
Actually, I\'m not sure I know what you mean.

**[\>\> Rose Marie Robertson:]{.underline}**\
On the bottom ‑‑

**[\>\> Steve Parente:]{.underline}**\
Oh, that\'s just ‑‑

**[\>\>]{.underline}**\
Ninety-one to ninety-nine percent income.

**[\>\> Steve Parente:]{.underline}**\
This is regarding the U.S. population. So it's the population that's
sort of off in the hinterlands there. You can actually think of DC sort
of distributed this way. Those under 90 percentile of income, those with
91 to 99 percent that have a pool but not that great a roof, and those
with 99 percent that have solid rock materials across all their homes.

**[\>\> Rose Marie Robertson:]{.underline}**\
Okay.

**[\>\> Steve Parente:]{.underline}**\
So \-- okay. Next slide. So we have actually taken a pretty strong
interest in doing this for research. This is actually a project that we
sent initially to RWJ, but it moved on to actually getting potentially
some support from the State of Minnesota to look at this as a demo with
market research, with Exante Bank, which is one of the medical banking
firms sponsored by United Healthcare. In essence what they are using is
the healthcare card to function as a Visa, MasterCard transaction
platform that could carry claims data along the wire with it and
potentially have the opportunity, using a USB swipe technology, to
actually carry more than the claims data. What\'s intriguing about this
is that United has actually tried in some demonstration purposes to
incent the providers to actually use the cards and get immediate payment
back, or at least within a few minutes back as opposed to the normal
waiting 30 to 40 days to get the payments back. And in certain instances
when the, if say it is a high deductible health plan, the Visa part
could be accessed to essentially cover the cost. What United has done as
a demonstration is, actually, they are covering the cost and then going
back to the consumer to settle. But one thing that they're doing that is
kind of interesting is they are basically paying 85 percent, 85 cents on
the dollar for expenditures for the allowed charge. And the sense is
there is a 15 percent fee, which might seem a bit high, but then again
the recovery rate for stuff that is direct billed to the patient is more
like 35 percent. So it is actually potentially a better deal for the
physicians and they get paid immediately. What\'s intriguing about this
is that it is a real nice financial economic incentive for physicians
and providers to participate because they are going to get the dollars
faster, essentially insurers may be willing to let go a little bit of
the float here to try to get better data. And because the USB technology
opens up a Web platform, you might be able to put additional clinical
information in, very simple stuff, such as blood pressure and weight and
other components. And then for diagnostic testing, you might be able to
go even further to actually attach the results as well and have that fly
on the claim stream, as well as the Visa transaction back. So what we
are looking at is a study to see whether or not consumers and providers
will buy into this. It is multi‑disciplinary with a marketing group, as
well as the business school and the medical school, to see if this will
play. We should know something by next year although we are very early
on. Next slide.

So this is just a piece of what we are talking about before. What this
is referred to is the integrated health card. It combines
medical banking with electronic health records or really personal health
records data. As I mentioned, the bottom bullet, we are going to see how
this prototype will work and then try the prototype out on a focus group
to sort of get back sort of how much the consumers will value, almost to
the point of saying, how much would they price this service for. And
then the same thing for provider adoption, whether or not there is
sufficient buy in particularly with different economic incentives that
were mentioned before that actually have this work. Next slide.

So what I find is particularly innovative about this is that you are
sort of taking two or three existing technologies, that have been around
for a long time and putting on top of them a personal health component
that I think has been missing. I\'ve worked with a few of the personal
health record companies. What always struck me was that they, very few
of them actually used the backbone systems of the insurance world to
actually operate. This uses that world, as well as incorporates in the
banking or Visa rails (ph) technology, which is not perfect, but it is
an interesting, novel approach.

And what I define innovation as is this creativity across a set of
different ideas and interrelationships. This definitely does it because
what it essentially does, is it has that healthcare card, which all of
us have anyway, provide a mechanism to essentially get to a Web‑based
ASP platform to have health data that\'s there, that\'s secure, the same
way that we use that information for online banking and other things
that the consumers at least would recognize as familiar and not
completely new. Granted, it is health information, people are very
sensitive about it. But if there were extra consumer benefits that could
go along with this, plus if the data sticks with you for a while, and it
let\'s you shop smarter for your healthcare, it may get over the hump of
people getting concerned about the privacy issue, in the same way that
online banking and online retail eventually got over the privacy issue,
because of the convenience argument. Next slide.

So all of you probably have, think about this in the different ways. I
use this in class all the time, of talking about a Medicare enrollee
saying that it is wonderful that all these health systems or hospitals
are buying electronic health records and they talk about being
interoperable-ready, sort of strikes me as this HD-ready stuff. But, and
this is even, not quite so prepared. So this is an example of a Medicare
snowbird that lives in Minnesota. She gets about 40 percent of her care
from an integrated delivery system that\'s here, from two different
clinics. Their records are linked so that\'s great. But the other 60
percent of her care is outside, in Florida. Some of it might never be
linked at all. Say the 10 percent that\'s a mental health provider
that\'s in Florida that doesn\'t want to link whatsoever. But basically
the majority of her care is unlinkable. The only person that actually
sees this care though, it's kind of poor, is the actual insurance folks
say at Medicare. It would be nice if you could try to have different
clinical information ride that wire, though it has its problems. The one
thing about it is at least right now that data does flow as opposed to
what we are trying to build with interoperability. Next slide.

So what can happen, as I mentioned before, is that the information can
be accessed or used at the point of care. The idea is the swipe of the
card can give access to physicians to personal health records that the
consumer can put in, plus the claims data for that person's back
history. Now, I\'m not sure how many folks have actually used these
sorts of things. It is really just, you are having your explanation of
benefit forms online to you. But it is pretty robust actually, or can be
very robust. If you have, essentially going back a year or two or three
in medication history, and you see the actual scripts and what\'s
prescribed, that tells a lot of information to a physician and it\'s
just based on claims. When I actually show examples of this to students
and actually faculty and physicians in my class, a lot of people say,
well, this is a medical record. And I\'m like, no, this is actually
claims. And they're just shocked, because it\'s coming from all
different sources, and normally they don\'t necessarily get to see that
as well, unless they are coming from an integrated delivery system.
What\'s nice, even better, is that the records can be augmented with
information from that person, as well as some other information on, that
could be history and physical information that could be added in on
those swipes, depending upon what rule engine you put into and
collection premises. It is really a question of how aggressive does the
insurer or the banking agency want to be to collect that additional
information? Next slide.

So how might this work? What I have here is the case of Anna, who is a
consumer. And I\'m Italian so I\'m speaking my grandfather\'s native
dialects here. You know, with a diabetes. Sorry about that. With
diabetes. She\'s just moved to a new city. January 1, 2008, she begins
her new coverage. She has this iPHR technology basically coming to her
by getting a health card with a swipe technology component. Prior to the
start date she receives health benefit information that\'s with a mag
stripe from her employer. That\'s basically the card. She then can go to
the Website that\'s noted inside of that packet to see what\'s going on.
She can look and see what endocrinologist she wants to see. She\'s been
used to seeing a set of them. That\'s helpful. And she can also find
that those endocrinologists are actually linked and available to be
scheduling appointments. There is a lot of assumptions that are being
made in that issue. That\'s not necessarily medical banking. That is
more assumptions of the health plans that have that level of
coordination with their provider panels. Next slide.

So prior to the visit basically Anna will log on to the Website. She
verifies what her eligibility is. She adds a little bit of information
in, such as emergency contacts and a do not resuscitate order, personal
preference information there. She also requests that her previous
pharmacy history from a different health plan be added to the iPHR. This
is an interesting idea because we don\'t really talk about this very
much. We talk about the issue of you owning your medical records. We
think it is your medical records, but why not claims? And that claims
data is essentially, from the pharmacy side, just as relevant as what
the retail orders were before. And under this scenario, essentially,
that data gets loaded in and actually back fills quite a bit. And if she
goes from health plan to health plan over a period of years she might
have several years of accumulated pharmacy information available with
dates of service, where she got the services, anything else that would
essentially be fields that are on a RxHub-type of platform.\
\
When she visits the endocrinologist, the physician assistant swipes the
card using the USB swipe machine that can actually \-- Internet, those
little swipe things are about 50 dollars. If you just plug into any
workstation, and it kind of auto loads that into a Website that sort of
pulls up her iPHR information. There is a request for authentication
with her password. This is probably the bulkiest part of this that needs
some work. I will leave that to the medical banking people to figure
this out, whether or not it\'s a password, whether it\'s a thumbprint or
something else, there has to be some authentication that goes on. I
think this would be the case for anybody, not just whether this is a PHR
or medical banking technology.

The physician then sees this information, or has access to all her past
history. It's up to the doctor to see how much they want to see before
they see her. He conducts an initial evaluation, and actually has some
information on, prior information on dosing. Next slide.

During the visit, standard stuff gets ordered. HbA1c. Blood sugar.
Creatinine. Also height, weight, blood information is entered on paper
records. The physician assistant then bills for all this stuff on the
iPHR Website. This links to a transaction that basically asks for
additional information besides just the CPT4 code for being billed for
that height, weight, and blood pressure information. This once again is
a question of how aggressive does the health plan or component want to
be. The idea is that that information is being taken when it is part of
a standard evaluation. Why not collect it there? Since it is
time-stamped with claims data, it can provide a very robust history over
a long period of time. Then the, with the information already known in
terms of eligibility, basically once that information is entered and
everything checks out, it would be, get transferred back to that
provider\'s account or however they want that information secured,
really at the point of care. The thought is, I think in talking to a few
health plans that are thinking this way, that about 95 percent of
transactions can move within about two minutes of essentially that click
as opposed to the days that they go on right now.

A day later the patient receives e‑mail that the lab work\'s been done.
They go to iPHR to basically click on the Website information. Having
been at Definity for several years, I mean, the tantalizing thing always
was, when you see that lab work was done, you sort of just want to click
at this magical icon that\'s never there that says, okay, what the heck
was that result. This would sort of give you that result and link it
back to that claim. Next slide.

Patient sees the endocrinologist four more times. Keeps showing stable,
improving lab values. At the end of the year the health plan invites the
person to comment. She comments upon this information and actually
allows her to get additional health savings and credits into her
reimbursement account. This is actually happening already with a lot of
the consumer-driven health plans. Wells Fargo, I know for example, is
doing something similar to this using health risk assessment forms.\
\
The issue is that is has to become more robust in terms of getting
better information to really see whether or not you are targeting the
right types of behavior. What\'s really intriguing is number 16 though
because you have this back store of information. And you, think of it
this way, for those of you who sort of investigated health insurance,
and you go to eHealthInsurance.com to shop for a premium. The idea is
that you could take this information, bundle it as a packet, and submit
it to eHealthInsurance.com to get a new locked-in premium. Not just a
hypothetical that requires a paramedic to come to your house. A real
one, that actually has a discount that\'s associated with it. It is not
just, in this case now, it is no longer just about getting electronic
health records and having them available in an emergency. This is
honestly letting you shop for lower premiums. And what would happen is,
if this works right, is that she would essentially pick another
insurance design, and all this information flows. She owns it. This
basically creates the utility model for the medical banking thing and
ties in well to how we think about banking in general, and off we go.
Next slide.

So the big question, I\'m sure everyone asks is claims data the right
architecture. Particularly if you are more clinically-minded. It\'s like
claims data just pays bills. Get off. This stuff is dumb. The thing that
claims data has that\'s unique is that it has a date and time stamp that
is very important to look at things chronologically, what's generally
going on is you are missing a tremendous amount of clinical detail. When
people look at what they like about clinical information systems, they
are after all transaction systems, largely. When you look at CPOE
systems, whether they be diagnostic, radiology, or pharmacy, that\'s
what they are. It is just they are different variables and clinical
components that are following along. This would allow some of that
information to go along for the ride on, with the claims, and it can
reach into any platform, regardless of provider preference.

My biggest concern ‑‑ little soapboxing here ‑‑ with interoperability is
that ‑‑ and I see this even in friendly Minnesota \-- there is a lot of
providers that just don\'t want to let the data out for fear it is going
to recriminate them. But the data does go out with claims. And the
thought is, well, as long as stuff is going along, let this be the
Schindler\'s list. I know I\'m going to regret this comment, but take
that information out, so that at least it doesn\'t get held hostage by
servers forever. Next slide.

Why this might really work? As I said before, the biggest weakness of
health data from insurance transaction data, is it's just billing
information. You can add additional clinical information and have it
ride the wire. And as I said, basically in the IOM report and other
things that come after this, we have all been sort of advocating these
types of information systems. Just this takes what\'s already built from
them and extracts key information. It is going to take a while to
evolve, to figure out what key information you need to make it useful
for other indications, but at least as a start to have the information
to flow to let that science begin. You know, it took about six or seven
years for people to figure out what to do with diagnosis codes once they
came in for DRGs. But once they did, it was a whole different world.
Without that flow we are going to be stymied to come up with better
transparency and quality metrics. Next slide.

So in summary, not to be a pessimist about this, it is my own opinion,
nobody else\'s. But my question generally is, is what if
interoperability is too hard to get the compliance from the providers to
make this thing work. This provides a very real plan B. Could be faster
and cheaper to collect because many of the existing components are
there. Really it is a question to be, you know, trade term, courage on
the part of the payers and other folks to kind of let this thing flow.

The significance of this new technology is that it is really based on
old and can be very innovative in its application. And it does provide
one thing that\'s been missing, which is a platform that links across
all different sites of care to get clinical information out, regardless
of whether it is integrated or not, and have it basically tie back with
the patient as the unit of analysis. Right now only claims do that. This
lets that clinical information ride that wire, and give the consumer
something tractable to do, such as shop and get some real value back
potentially to make that convenience/privacy trade‑off in the long run.

And with that, I welcome, next slide, any additional questions. Most of
this, like I said, I will post this on our consumer-driven health site,
ehealthplan.org. You can find me there if you need any other additional
information. Thank you.

**[\>\> Rose Marie Robertson:]{.underline}**\
Steve, thanks very much. What we might do, we have it on the agenda this
way, is to hear John Casillas and then invite discussion from the group
about both topics. So John, if you are ready. John is, joins us from the
Medical Banking Project, in Franklin, Tennessee, right down the road
from my house.

**[\>\> John Casillas:]{.underline}**\
Right down from your house. I didn\'t even know that. Here I am up here.

\[laughter\]

Can everybody hear me okay?

**[\>\> Rose Marie Robertson:]{.underline}**\
I\'m not at my house either, so it doesn\'t matter.

**[\>\> John Casillas:]{.underline}**\
Okay. First of all I want to thank the committee for inviting the
Medical Banking Project to speak about this movement, now global in
scope. Also want to publicly thank the members of the Medical Banking
Project. And I actually prepared comments, and I hope that\'s okay. I
certainly get involved in ad hoc conversation, but I thought I would try
to, you know, medical banking is a broad topic. Trying to get it all
into 15 minutes is challenging.

Our members represent a diverse constituency of banks and financial
service groups, healthcare providers and plans, IT and consulting firms,
automotive, entertainment and pharmaceutical firms, government agencies,
associations, academic health centers, and non‑profits.

And they have dedicated about 200 C-level executives to our work. So I
just, I want to invite you on a journey, a digital pathway to better
health. You know, one of my favorite movies growing up was the Wizard of
Oz. I loved the journey following the yellow brick road, into the land
of imagination and fascination. Sometimes it helps for us to just step
back a little bit and imagine once in a while. We watch the tin man who
needed a heart, the lion who wanted courage, and the scarecrow who
wanted a brain. If ever there was a need for these three things, a
heart, courage, and a brain full of wisdom, now is the time, as we face
a broad and deepening healthcare crisis in America.

Now, I'm no wizard, but I\'ve been on the journey for the past decade
that I believe, in fact I\'m positive, will help us solve one of the
most vexing problems our country has ever faced: universal access to
quality healthcare at a reasonable cost. Starting this journey in
earnest in 1996, I coined the term \"medical banking\" that is now in
general industry use. That was nine years before we announced our
membership program, which was nine years of pushing the ball up hill
financially, intellectually, and emotionally. I must admit, there were
naysayers at almost every corner, and the journey was very lonely, but
not anymore. We have seen testimony already today, there is many more.
When a major publication like *HealthLeaders* heralds, the banks are
coming, you know you\'re making great progress. So I know a lot of
people are asking today, why banks? And in the short 15 minutes here, I
hope to answer that for you. Next slide please.

Our new journey comes packed with new terms like medical banking which,
simply stated, means using banking systems to improve healthcare. Have
you ever noticed that sometimes when we try to solve a complex problem,
the answer is right under our nose? I believe medical banking is much
like that. Other industries have learned how to link EDI to streamline
end‑to‑end programs. The bank, central to the healthcare value chain,
can help us to do just that. New inter‑organizational systems have
dramatically changed how we find and purchase airline tickets, for
example. Today we go online, and our options are numerous and
increasing. As the academic researchers have critically shown, what made
this convenience possible is the integration of banking and ticketing
systems, and this is a key point. There is nothing more important to a
sale than knowing for sure that you have been paid. It is foundational
for providing an ever increasing array of consumer options. Next slide.

Likewise, we believe what will empower medical consumers is the
integration of their pocket books with healthcare choices, through their
bank accounts. We call it the health-wealth equation. Using
sophisticated tools, implemented and secure, consumer authenticated and
authorized online banking systems, where 55 million Americans pay their
bills every day, you and I will be able to see, with the aid of our
family doctors, how our health conditions will affect us over time and
how much they will cost. These modeling programs will empower us to
strike a balance between how much we will likely pay for our healthcare
and how much we want to keep for retirement. And we will even be able to
measure those costs along the way. Equipped with sophisticated identity
proofing, the online banking platform can house our medical and
financial tool kits, talking about a medical PHR home. Think of it as
single sign‑on for the consumer. Today banks own secure systems that
link all the healthcare actors, including consumers.

In 2001 we jump‑started the medical banking industry by showing banks
how to use this linkage to reduce transaction processing costs in
healthcare by 35 billion dollars annually. A recent survey commissioned
by PNC Bank showed that most hospitals would use these savings,
estimated at up to 10 million dollars per year, per facility, to provide
charity or indigent care. This is consistent with our guiding mission to
convert digital savings into charitable resources. Yet this is just the
first leg of the medical banking build‑out as we move forward to develop
a secure, self‑sustaining system for on‑demand personal healthcare
records. We view this effort as highly synergistic with RHIOs or HIEs
and the new health record banks. Next slide.

Now, sometimes we place the cart before the horse. In our race to
improve healthcare, we think it is important to keep at least two things
crystal clear. First, is public trust. The true bellwether of our drive
to empower consumers must reside with public trust. The second is
meeting the challenge of the underserved, and in medical banking this
includes the unbanked. Medical banking programs address this critical
area and also meets the needs of consumers to access money and
healthcare records during times of man‑made or natural disaster, through
the medical banking system. Clearly a consumer empowerment issue.

Now back to that cart analogy. The cart in our case is HIPAA. And I\'m
reading a little bit about it in these notes. As you can see with our
HIPAA wizard, we dressed him up a bit to debut Phase I of our industry
build‑out, because most industries have a very hard time embracing this
guy. Clearly banks must embrace HIPAA before paving new eHealth
highways. That means that banks must comply with the highest medical
privacy rules in the land. And through our extensive outreach programs,
with CMS, the Office of Civil Rights, privacy groups, and others, we
helped to pave this cornerstone area in medical banking policy.

Public trust represents what we must have to do anything else in this
new space. Banks have it, and without it, they simply fail. We should
realize that just under our nose is a banking system that routinely
spends billions of dollars in an identity theft arms race that keeps the
bad guys away from your money, day in and day out. It can keep the bad
guys away from your health data, too. Banks operationalize privacy and
security in a comprehensive and global way every day of the week. When
you consider healthcare is just getting started, we think not using
banking systems could squander an historic opportunity in America. The
sheer cost alone is reason enough to look at what\'s lying right beneath
our nose using banks, not to mention the necessary operating experience
because this really is not just a technology issue.

So how will medical banking build a better mouse trap? Turning towards
Phase II of our movement, we needed to move the bylaw from HIPAA
compliance to interoperability so we created the Great American
Interoperability Tour. This 14‑month lecture series picked up by NBC
provided sneak previews to 10 stakeholders of what banks can do. It
ended at our 2003 institute, where three of the largest banks in America
publicly embraced HIPAA and announced they were moving ahead to provide
better tools for care providers, health plans and consumers. At that
moment, a new race was on. Today banks, in order to compete in medical
banking, have invested already hundreds of millions of dollars into
healthcare IT. A new non‑traditional buyer is in town, banks, and they
are providing funds that can ramp providers on to a digital ecosystem in
healthcare. Next slide.\
\
We next announced our COMBAT initiative at the Vanderbilt Center
for Better Health to steer this new momentum. The acronym stands for
Cooperative, Open-source Medical Banking Architecture and Technology.
And the mission is to combat the rising cost of healthcare using medical
banking.

We are engaging or managing two pilots under this initiative. One helps
the doctor to know how much to bill an out‑of‑network patient at point
of service who presents with a high deductible health plan.

This card can be teamed up with the PHR that the gentleman from
Minnesota was talking about. In fact, the use case is being funded
Exante and managed pro-bono by Foresight, PricewaterhouseCoopers, Sun,
and ACS. This is an industrywide critical path issue in consumer-driven
healthcare because it allows care providers to calculate what the
consumer owes at point of service and bill it accordingly, as opposed to
shouldering this increasing risk.

A second pilot program links the consumer to his or her healthcare
records through a HIPAA-compliant online banking system. Only bank
members of MB project who have been thoroughly indoctrinated with HIPAA
are working on this. We agree passionately with the privacy groups that
a Chinese firewall between the bank and your health data is a
pivotal element in building public trust.\
\
Sometimes it is important to move quickly. That\'s why we announced
Phase IV of our build‑out, a common medical banking platform called
BoardTrust. BoardTrust will literally hand‑hold the banks into this
fascinating new world we call medical banking by ramping them on to
standards, processes, and operating agreements quickly and easily. It
will be directed by a board of governors, as we take our lead from the
Federal Reserve System. This body will be supported by at least two
advisory boards, a public trust advisory board and a technical advisory
board. These groups will keep our work focused on what\'s happening on
the ground in terms of privacy, security, and consumer protection. Under
the leadership of our diverse membership, our venue will help to ensure
that the information families use to make decisions will improve
healthcare, which is a key area of concern by employers and is based on
evidence‑based medicine, especially as more of that information is
distributed through the online banking platform, which is happening
today. Next slide.

Many have joined our cause, including a new joint task group for value
in health that we formed with the 1,600 employers strong Automotive
Industry Action Group. Together we are introducing value‑driven
healthcare strategies into the medical banking model. For instance,
designing employer programs that can motivate employees financially to
live long and healthy lives, managed by the local bank. Disney has been
a constant supporter of our work, and has promoted MB Project to the top
100 corporations in America. We also have a world‑class advisory board
that keeps us well informed. Next slide.

Our journey is just beginning and requires constant focus on
environmental factors. As you can see from this graph, community
integration of systems that were previously behind corporate walls
demands tight multi‑domain integration. All of these systems are
accountable to the golden standard of public trust. Next slide.

To summarize, the medical banking journey has led us to a new vision for
healthcare using a bank infomediary. This intermediate market structure
is well positioned, extremely well financed, and willing to make large
investments to improve healthcare. It's areas of focus include improving
administrative efficiency; creating a highly secure, patient‑authorized
health data network; delivering healthcare tools to bank account holders
to manage their health-wealth equation; and, last, but not least,
driving better coordination of community health care through a program
we call Charitable communities Network. Next slide.

To assist the medical banking journey, I thought while I was up here we
would ask AHIC to consider three things as recommendations. First we
invite you to engage a cross‑industry dialog to ferret out policy
issues. And I see you\'re already embarking upon that. We often find
ourselves on the defensive as we try to coordinate policy in between
banking and healthcare. It's like a mouse dancing in between elephants.
In order for medical banking to flourish as an industry strategy that
empowers consumers, we need to focus on these policies that affect both
banking and healthcare.

Second, consider appointing a liaison for electronic and personal
healthcare records program. I am sure you get thousands of requests like
this, but wishful thinking is permitted in the Land of Oz. Actually,
your involvement would help us refine our model.

And finally, participate in our annual institutes for ONC, the National
Governors Association, Centers for Disease Control, and many others
participated who believe that our program can empower medical consumers
in the emerging digital world. Next slide.

I hope this helps to understand our work to support universal access to
quality healthcare at a reasonable cost using medical banking. Thank
you.

**[\>\> Rose Marie Robertson:]{.underline}**\
John, thanks very much. That\'s great. Let\'s take a few ‑‑ we\'re just
a few minutes behind schedule here, but let\'s take a few minutes to
allow questions and to discuss these last two sets of comments.

**[\>\> Kelly Cronin:]{.underline}**\
I\'m just wondering what regulatory framework you are working under. And
in particular, the board that you talked about, are you picking up sort
of a quasi‑regulatory responsibility or how are you relating to existing
regulations?

**[\>\> John Casillas:]{.underline}**\
I think there\'s two questions there, if I heard it right. The first
question is what regulatory frameworks we are working on, and those are
the regulations already in place. HIPPA, Title V of Gramm-Leach-Bliley,
FACTA, FFIEC guidance, and other rules.

And again, you know, no one wants to see banks using personal health
records to make credit determinations, and that was clearly specified in
the FACTA rules. However, if the bank can utilize that de‑identified
information to extend more credit to healthcare consumers, then that is
probably a positive thing because hospitals need that. So there is a
need to make sure the policies that are being applied are, make sense on
both sides of the spectrum. And I think that\'s a policy gap or an area
of regulatory gap that we have.

The other question about the public trust advisory board and the board
of governors is strictly a private effort. We are talking to Federal
Reserve, but there is no quasi‑governmental influence in that at all
that I know of.

**[\>\> Kelly Cronin:]{.underline}**\
And the Federal Reserve is acting in an ex officio capacity or ‑‑

**[\>\> John Casillas:]{.underline}**\
No.

**[\>\> Kelly Cronin:]{.underline}**\
‑‑ you are just seeking ‑‑

**[\>\> John Casillas:]{.underline}**\
Just seeking their guidance right now.

**[\>\> Kelly Cronin:]{.underline}**\
Okay.

**[\>\> John Casillas:]{.underline}**\
If you look at the Independent Health Record Bank Act the Federal
Reserve Board was actually listed as the governance study for rolling
out the health record banking model in the House version of the bill
sponsored by Senator Brownback. We inquired, because that was news to
us, we inquired from the Federal Reserve if they had ever talked about
that, and we found out that the answer was that they had not ‑‑ and that
started the dialog. We think the Federal Reserve Board model, great
model for understanding what\'s going on on the ground with respect
to consumers and privacy.

**[\>\> Justine Handelman:]{.underline}**\
I was just more so going to make a comment, going back to what Steve
said about claims data, obviously some value there as the first step. We
know it is not the best data out there, but at least now where we are in
the system. But I also just felt the need, having heard what John said,
that at least in Blue Cross/Blue Shield, we have actually established ‑‑
I\'m not sure if you are familiar with Blue Bank, because we saw the
value of making it easier for consumers to integrate financial and
health information. And actually the host of that and wrapped around it
is not only we have an agreement with Visa so we can do many of the
things with providers in terms of providing payment up front, real‑time
claims adjudication is what we are working to. In some areas we are
there. And attaching all the health information tools using the data we
have around that. I\'m happy to share more information of what\'s
happening in the health plan world. We think it is pretty exciting. The
bank was just launched in March. But given the information that we have
in our relation with our providers and consumers, how we make everything
more user‑friendly for all the users and create efficiencies in the
system. This is something that clearly wanted to have a role in the
space and see a role to integrate. And what\'s interesting about our
model, too, is even if the consumer leaves Blue Cross/Blue Shield, they
can still keep their Blue Bank if they have HRAs or HSAs or any of the
other acronyms out there. So I\'m happy to provide more information ‑‑
\[inaudible\] regulatory ‑‑ \[inaudible\].

**[\>\> Rose Marie Robertson:]{.underline}**\
Terrific. That would be great.

**[\>\> Kelly Cronin:]{.underline}**\
I just had a quick follow‑up question for Steve Parente. We've talked
about this issue in the past. I think it is somewhat related to what
Justine was saying. As an economist, Steve, could you comment about the
role of payers and banks and their market \-- how they could influence
the market given their capital and given their strategic interest in
this area? Also comment on the risks involved with that.

**[\>\> Steve Parente:]{.underline}**\
Yes. I mean, that\'s a great question. I mean, in terms of their role,
it could be really the, they could be really the total tipping point. It
really depends how far the insurers will cooperate. Because I think what
needs to happen to make this really viable is for there to be ground
rules set up between the, both the banks and the insurers participating
in this to have the handoff of records that, from one consumer to the
next. You really need to, you would almost want to have a set of firms
that really come up as the consumers' advocate, which really could be
the banks or a subset of the banks to support that function. And the
insurers must be willing to let the data go. If they don\'t, then we
have a problem. But I think if that were to occur, it really could, the
tipping part is getting the data out of the providers, to more or less
say to the provider community, you\'re not going to get paid unless you
attach the stuff, and the advantage of it is, you are going to get paid
a lot faster. I think that\'s a viable thing to say.

What\'s the risk? Well, I mean, in terms of the ‑‑ I really appreciate
David's comments, because the issue is that there is this question of
the trust factor here. And focusing on trust is going to be a big issue
here. Insurers don\'t necessarily go up high on the trust score. Banks
are not that much above them. And so to make this thing work well, it is
going to need some really solid sales, really almost public marketing to
make sure that people see the long‑term advantage of getting this thing
done.

And there needs to be some consumer protections that are built in, that
are as transparent as, say, in the credit card industry to say, look it,
if something goes wrong there is a very clear course of corrective
action. You know, that\'s usually the case for fraud in credit. I mean,
there is more stuff coming up for privacy. That still might not do the
deal, but that\'s probably the biggest risk. And outside of, the other
risks besides that, I\'m not quite sure what they are. I mean, I think
this really can be a very potent area for change.

**[\>\> Rose Marie Robertson:]{.underline}**\
Steve, to what extent ‑‑ you talked about the insurance company perhaps
being willing to give up some of the float, you know, to make this
happen because they would, there would be some advantage to them. Do you
have a sense of the quantity, the quantitative base of that, and what
aspects they would be looking at for benefits?

**[\>\> Steve Parente:]{.underline}**\
Well, that\'s a great question, and I don\'t have a very, I don\'t have
a clear number on it. I think, as I\'ve been kind of digging at that
question, because that honestly is one that\'s been sort of noodling
around in my mind. I hear different responses from the insurers, about
do they care about the float now or not. The sense is, if anyone is
making really any money on the float per se anymore there are other
vehicles to, that could enable better vehicles for doing that. It
doesn\'t necessarily require, in the sense they are willing to give that
up if they know there are other longer term advantages they could gain.
The thing that always was very clear about it Exante that was kind of
clever was that they knew they were going to get this fee back for
essentially holding the money. Now, whether that\'s the right fee for
holding the money is a different question. But they at least put
together, in my view, a stability piece of this to sort of cover the
cost of the float loss.

The other aspect of it, too, is that, you know, a lot of these insurers
are operating on, as for self-insured designs. And that\'s really the
majority of insurance cap these days. These under 65, if you are not a
public insurance plan. Say about 55 percent of folks are there. In those
instances a lot of the money is coming directly from the employers
anyway, so there is not that much float to hold on to to begin with.

Over a period of time the float has been diminishing. Insurers have been
adjusting. They might see opportunities for other revenue to cover it,
or they just, they honestly just are looking for better information
exchanges. The other thing to consider, and I said this before to Kelly
and many others, is that depending on the health plan you are talking
about, whether it be United or I know the Blues are thinking about this,
they too want to resell this data. And in the case of United, they do,
to the tune of a lot of money. So if you actually happen to accentuate
it with more information and it\'s de‑identified, which is the condition
for the resale or repackaging of it, it is pretty viable.

**[\>\> John Casillas:]{.underline}**\
Can I add just a couple of things? Unisys did a report, a global survey
\--

**[\>\> Rose Marie Robertson:]{.underline}**\
Who is this?

**[\>\> John Casillas:]{.underline}**\
This is John Casillas with Medical Bank. Sorry \-- Where they ask
consumers who they trusted the most for their digital authentication
credentials. Okay? Who would they trust to manage their digital ID,
essentially. And in the survey, which I\'m sure I can get for this
group, the banks placed number one and the government actually placed
number two. And private groups placed at, like, 36 percent, 46 percent
So there is hope there.

The other issue is, how do banks and health plans cooperate, which is a
big issue because it seems like, you know, banks like to have health
plans as their clients. And in the new consumer driven healthcare world,
there seems to be another dichotomy that\'s starting to arise here,
where they are competing, and that\'s not very good. But the exception
to the study, and they said that ‑‑ and I\'m sure you are familiar with
it ‑‑ that consumers would pay 5 dollars or more per month for access to
their healthcare records. Okay? And if that\'s true and there\'s over
100 million accounts today, that\'s a 6 billion dollar market.

**[\>\>]{.underline}**\
Right.

**[\>\> John Casillas:]{.underline}**\
So ‑‑ and we are, the banks are not going to get this information. They
are going to try to get it from RHIOs. If they offer it on their online
banking platform, and they actually ‑‑ I think that\'s one way that you
can speed adoption of this ‑‑ they are going to be searching for it from
their relationships with providers, with RHIOs, with health plans. So
there is a way for them to partner there.

**[\>\> Rose Marie Robertson:]{.underline}**\
Any other questions? We should probably move on to ‑‑ and testifiers,
again, are welcome to stay and listen.

I forgot one item in our previous, as we began, and that was just to
have approval of the prior meeting summary. And could I have a motion
for that approval?

**[\>\> Lorraine Doo:]{.underline}**\
This is Lorraine. I\'ll move.

**[\>\> Rose Marie Robertson:]{.underline}**\
Okay. Second?

**[\>\>]{.underline}**\
\[Inaudible\].

**[\>\>]{.underline}**\
Do we need a third? A third? I\'ll do a third.

**[\>\> Rose Marie Robertson:]{.underline}**\
Okay. All in favor?

**[\>\>]{.underline}**\
Aye.

**[\>\>]{.underline}**\
Aye.

**[\>\>]{.underline}**\
Aye.

**[\>\> Rose Marie Robertson:]{.underline}**\
Opposed?

**[\>\>]{.underline}**\
None.

**[\>\> Rose Marie Robertson:]{.underline}**\
Okay. Very good.

Now, we ‑‑ as part of this discussion about where information can be
held and how it can be exchanged, we have, as you are all well familiar
with, Stanley Chin, who provided us a bit of very important information
previously. We had asked Stanley to come back and talk to us about an
environmental scan on interoperability. And so let\'s turn over to
Stanley now.

**[\>\>]{.underline}**\
\[Inaudible\].

**[\>\> Michelle Murray:]{.underline}**\
Rose Marie, we\'re switching the order a little bit, because Ken Mandl
has to go teach a class at 2:40.

**[\>\> Rose Marie Robertson:]{.underline}**\
Okay, sure. Very good.

**[\>\> Michelle Murray:]{.underline}**\
So we'll let them go forward first and then Stanley.

**[\>\> Rose Marie Robertson:]{.underline}**\
So we are going to our next section on the testimony on the role of
Health Information Exchanges, to Will Crawford and Ken Mandl.

**[\>\> Will Crawford:]{.underline}**\
Thank you very much. Ken, are you actually still ‑‑ I think we have some
other telephony issues so I think he was trying to dial back in. I\'m
going to try to get started so we can stay on track and then he\'ll go
in when he gets reconnected and should be here for the Q&A piece.

What we were asked to do is to come and talk a little bit about some of
the specific examples of health information exchange connectivity with
personal health records, that we have been working at Harvard Medical
School and Children\'s Hospital in Boston for the last several years, as
well as to talk a little bit about some of the thinking we have been
doing over the last year or so on different models for the PHR\'s role
in a networked health information exchange environment. So what I\'m
going to try to do today is actually go very low level. I\'m not going
to talk about the need for broad governance activities, but try to
really get down to brass tacks with some of the specific things that we
have been doing and that we\'re hoping to learn from and that will
hopefully inform some of the future discussions about HIE and personal
health records. So hopefully this will actually help drive the
discussion on how to implement some of the NHIN consumer-focused
requirements that Kelly was talking about a bit earlier. The next slide,
please.

So just to define terms very quickly, what we are talking about, when we
at Children\'s talk about this stuff, is the personally controlled
health record, which is just like a regular personal health record
except it has another letter in the acronym. Because we think that the
control aspect for PHRs is very important, and it\'s worth reminding
people of over and over again.\
\
It\'s important to remember that control is not just about access to a
record. It is about having the flexibility to make some decisions about
how that record is dealt with in terms of who the information is
disclosed to, what kind of non‑clinical care uses it\'s put to. The
whole principle that we found that all of the work that\'s happened at
Children\'s on, is that a really solid concept of patient control is
critical to driving adoption of any of these systems, and certainly
anything that has something as scary as a network attached to it.

Just definitionally, it\'s an irrevocable copy of all healthcare data,
subsequent releases under patient control. And then the technology is
what really enables the rules of engagement. I think I\'ve actually
shown this slide to CE before. So next slide.

Quick background here is we're with the Children\'s Hospital Informatics
Program, at Children\'s hospital in Boston. This is a laboratory
affiliate of Harvard Medical School. Right now it is about 20 faculty
members, an additional 20 staff, focused combination of clinicians,
computer scientists, software engineers, social science researchers, who
handle some of the evaluation components for the different projects that
we have been doing. Established in 1994, working on issues around PHRs
since 1995.

The primary mechanism that we have been using is something called
IndivoHealth, which was formerly the PING project, which began in about
1997. It\'s been funded by a variety of sources including the Centers
for Disease Control and The Robert Wood Johnson Foundation, as well as
by Children\'s Hospital. It is an open source project. It is being
deployed at Children\'s to provide PHR services in some of the clinic
environments right now. We\'ve also deployed it with the student,
faculty, and staff population at MIT, which has just \[inaudible\], and
looking at a number of other long‑term research deployments of this
particular platform. So talk about a little bit more.

Most importantly for this discussion, though, this is the framework that
we have been using about PHR-enabled health information exchange and how
what we have been doing would fit into the broader setting of RHIOs,
NHIN, HIE. Technically we have already actually done that in that we
were involved in the CSC Markle Foundation NHIN demonstration project,
one of the four big \[inaudible\] pieces. And Indivo was the personal
health record component that demonstrated the consumer empowerment use
case in that \[inaudible\] piece. So next slide.

I just wanted to show the entire thing in one picture. And the picture
that I chose was the one page within the application that shows a
particular user, in this case it is Dan Nigrin, who is our CIO at
Children\'s, setting up his subscriptions. The Indivo personal health
record is built around the principle that you have a personal health
record and that personal health record subscribes to data from other
sources. So in this case Dan is getting information from Children\'s
Hospital and he\'s getting information from the MA-SHARE RHIO. He has
some other options that he could subscribe to, but he does not have data
in those places.

This is sort of the unique feature that allows us to look at HIE models
and the way that users interact with interoperability because the
software itself provides them with a platform to aggregate information.
What this also does is it allows the individual participants, in this
case Children\'s Hospital, the MA-SHARE RHIO, MIT Medical Center, to
make its own decisions about how they are going to release data to the
personal health record. Each of these institutions has an identity
proofing process that\'s already in place and that is more or less
adequate for their needs.

The PHR application, as opposed to the broader NHIN application, which
is a harder problem to solve, we allow those organizations to make their
decisions about what process the user needs to go through to have their
information activated so that they can then subscribe to it within the
personal health record. So it is not just a matter of logging into
Indivo and saying, I\'m a patient of Children\'s Hospital, here are my
demographics. You log into Indivo and say, I\'m a patient of Children\'s
Hospital, here is the PIN code that Children\'s Hospital gave me to set
up a relationship. That might be in‑person. It might be through the
Children\'s Hospital portal. It might be via some other avenue or it
might be through some shared authentication mechanism that\'s part of
the NHIN, part of the medical banking initiative, or even via an
insurance company or some other identity provider. Next slide, please.\
\
We sort of have two key insights that have come out of thinking about
deployment that we've done. The first is that, as I mentioned before,
it\'s important to confront privacy head on. I really emphasize the
individuals\' rights. That means that nothing that happens in this PHR
environment happens without the involvement and consent of the user.
That includes secondary use of data, it includes third party research,
it includes clinical care in the emergency room.\
\
I wrote another really insightful note here, but I handwriting is so bad
that I don\'t know what I actually wanted to say. So I\'ll just skip on
to insight number two which was that the patient is ‑‑ and this is
something that\'s been repeated in a number of other points of research
on this ‑‑ the patient is, in many cases, the ultimate aggregator of
where their health information exists. The health plan is actually
another useful aggregator because, by accepting claims, you have a
reasonable expectation of where information actually resides. But
particularly for the patients that we are targeting, who are generally
somewhat technology savvy or somewhat healthcare savvy, they can provide
the pointers to where their core healthcare information exists. And if
those providers are willing to share, then they can tie information
together. At the very extreme, you actually end up with something that
looks very much like an actual health information network, or at least
a more conventional health information exchange because you have
different providers feeding information to a single user\'s personal
health record. And I will get back to that in a minute.

I just want to emphasize again that a third key point here is that
involving the patient really does simplify some of the privacy concerns
around HIE because you can avoid having to make some of the assumptions
that you would otherwise have to make. If you have identity proofing
taking place at the site of care for instance, you don\'t need to engage
in nearly as much matching as you might otherwise have to. This
potentially makes it a lot easier for the healthcare delivery
organizations to release information to the PHR because, again, they
have some assurance that they are releasing it to the person they expect
that they are releasing it to rather than to another intermediate agent,
another intermediate organization which will have to make some kind of
judgment call about whether the PHR data should flow in a particular
direction. So the next slide, please.

And most of the rest of the presentation is pictures. This first one is
sort of our canonical picture of what the CSC Markle demonstration
project looked like. And you get the little picture of Dan Nigrin in the
corner there. This is what we actually built for the demo, which is an
Indivo server, fed by Children\'s Hospital, which is our PHR. That also
was fed by the MA-SHARE RHIO, which is the Massachusetts health care
organization, which then connected via an inter‑SNO bridge, according to
the Markle common framework with Regenstrief and Indiana.

The PHR here has the potential to do two things. It can retrieve
information that\'s provided by Indiana through the inter‑SNO bridge to
incorporate that information in the PHR, so it can subscribe to the
health information exchange. And it can also present information to the
health information exchange. And in this case the privacy protections
and the decisions that the user makes about how they want their personal
health record to be controlled, or that apply more or less transparently
back to the inter‑SNO bridge and back to the rest of the network of
networks. The information simply is not let out unless the user within
the PHR has decided they want that data to be let out. Next slide. And
actually we can skip even past this next slide as well.

We sort of have four methods that we have talked about. The tethered PHR
I\'m not really going to go into focus on because what\'s more
interesting is what the tethered PHR might evolve into. And this is one
model of what that might evolve into. The personal National Health
Information Network gateway provided via a particular hospital or
particular care delivery organization. In this case we have a hospital
connecting to the PHR server, which then participates just like any
other top level organization in the NHIN. So in this case we have it
connecting to a record locator service in a particular SNO, like the
original one that connects via the inter‑SNO bridge to other SNOs.
Pharmacies, pharmacy networks might be connected to the local network,
might be connected directly to the PHR and be connected via the NHIN.

The next evolution of that from, just on the next slide, is the idea
that the personally controlled health record service provider, whether
it is Indivo or something else, acts somewhat separately. Next slide.
It\'s animated. But the next slide ‑‑ there we are.

Personal NHIN gateway via PCHR service. In this case we have a separate,
independent healthcare service provider, to use the new NHIN
nomenclature. We\'re buzzword compliant.

\[laughter\]

It could also be called a consumer access service if you want to use the
Markle common framework buzzwords. But we have a separate organization
that does two things here. It connects to the health information
exchange and provides the individual patient the gateway into all of the
data that is available within the NHIN and within the individual
hospitals that might have direct connections, to provide richer data. It
also provides the patient the ability to opt in to certain kinds of
research or other activities, and that\'s represented here by the
connection with public health agencies directly via the personally
controlled health record environment, which allows you to do things that
you could not really do via just existing public health authority. There
are certain things you can look at as a public health agency, and there
are certain things you cannot look at, but that you still might want to
study with patient consent. So this provides a model that allows you to
tie in sort of those additional research agendas. But it doesn't have to
be just public health. That could be a pharmaceutical company.

Again, the secondary use issues do become a lot simpler if the patient
is put in the driver\'s seat and can make a decision about whether they
participate or not. The scope of those efforts might be a little bit
smaller but on the other hand, if you get the right kind of consent, you
might be able to learn a lot more about the patient.

The other interesting nuance of this is, in the simplest form, the
personal health record server just subscribes to all this health
information exchange data and it allows the consumer to make good use of
it. The more interesting aspect is the personal health record could also
provide the interface that allows the consumer to define to the health
information exchange, or to the NHIN, what controls they would like to
have placed on that data. So, and this is a major development effort and
a major standards effort, but there is a very real possibility of using
the concept of a PHR, whether it\'s is a consumer access service or
structured in some other way, to increase consumer confidence in the
NHIN, because it provides a concrete, centralized way for the patient to
indicate what their requirements, what their requirements actually are.
And I\'m almost done. There is one more slide.

I think it\'s going to ‑‑ so our final model, which we should put up
here for comparison, and this is actually more or less the model that we
are building in Boston and would like to expand out to connect to
further HIE as it evolves, is what we call the Aristotelian model, which
is where everything revolves around the PHR. And again, the difference
here from some of the standard PHR models is, rather than being provided
by the primary data source, or provided by a complete third party that
expects the individual to enter their own information, the PHR provider
creates the relationships with hospitals, pharmacies, subnetwork
organizations, and then that effectively acts as the health information
exchange. In order to make this work you need to have a wider range of
interfaces than you might need if you could tie into a more full,
national, consensus-driven HIE process. But there is still the ability
to plug in emergency room views, other kinds of research applications.
Specific \-- we've actually pulled out our user, or architecture a
little more on this slide. So we have the server that\'s responsible for
making all the tough decisions about how to apply patient privacy rules,
and then user interfaces that connect to that server can vary depending
on the needs of the population. So if you have a particular community of
interest around a particular disease, they might have very different
needs in a personal health record. We think of that as really an
application innovation issue rather than a PHR fundamentals issue.

And actually with that, I\'m not going to go to my last slide. I\'m
going to wrap up. And we sort of see three core issues around personal
health record health information exchange connectivity. The first is
that the data, including the connections to the care delivery
organizations that provide it and the ability for the patient to control
how they want it to be used, really need to become part of the plumbing.
That\'s what\'s going to drive personal health record innovation. Not
single, monolithic systems that run all the way through. If the data
becomes part of the plumbing, then PHR innovation can really focus on
applications that add value to particular communities. We believe that
the PHR example \[inaudible\] currently in the process of rolling out at
MIT with the entire student faculty, staff population at MIT. So we will
be learning a lot more how people react to this kind of a system.

It is a huge challenge. But making the data providers comfortable with
the process and releasing information, which already has been mentioned
and I\'m sure will be mentioned again, is a huge challenge. You know, we
think that the PHR could provide an opportunity for much greater, or can
drive adoption of broader, more clinical data‑focused activities. And
actually it's probably worth saying that one of the ways that we have
looked at doing this at Children\'s Hospital, to deal with the provider
concern about releasing some of the more detailed information \-- and we
have everything in that, we have got clinical notes, we\'ve got the
whole nine yards ‑‑ is set a cut‑off date. So information that is overly
historic is, this patient is not going to be provided when we roll out
for the whole hospital. But the physicians have gotten the date after
which their clinical notes are fair game for patient consumption. And
that\'s how things are going forward. So obviously that wouldn\'t have
been possible without very strong support from the Children\'s Hospital
administration and the partners there. What we hope to do is learn
something from that experience and then make that a model that\'s
available. I think I've run over my time, but thanks everyone. Ken, did
you ever make it on? Okay. So I do apologize to Stanley.

**[\>\> Rose Marie Robertson:]{.underline}**\
Terrific. Thanks very much. And what we might do is we will hear from
David Lansky and then have the discussion about this area. David. We
will turn to you.

**[\>\> David Lansky:]{.underline}**\
Thanks Rose Marie. I think I\'m going to potentially extend the comments
Will just made and frame them just one level higher of generality
probably. So what we ‑‑ the problem we\'ve been trying to tackle the
last year or so has been, less what is any specific implementation of
PHR data acquiring and sharing look like than what are the common rules
that all of those implementations probably need to subscribe to, to
create trust and interoperability among them. So even the three or four
models we\'ve talked about this afternoon, how do they talk to each
other and what would be the rules which will enable there to be trust
and efficient exchange of information among them, and with, as Wil just
said, those who currently hold personal data and on the other hand those
who are users and ultimately owners of that data.

So we have been developing the concept of the consumer access service.
So the first, we can skip through the first two or three slides. And
many of you have seen the Markle Connecting for Health work will
recognize this, essentially it says policy and technology have to go
hand in hand. You\'ve got to think about the architecture that\'s going
to be tying these networks of networks together as policy constructs.
They will in fact shape how much privacy people have and how much
control they have. So these couple of slides say that. We can skip ahead
to the first diagrammatic one. Probably the next slide. Yes, thanks.

So this is our picture of a network of networks. As Will suggested, in
our jargon we have a subnetwork organization which is like a RHIO,
whether it is geographic or not, and it has two pieces of
infrastructure: an index, which we call a record locator service, and a
bridge to the other networks, which we call an inter‑SNO bridge.\
\
And the next slide just asks the question, if we have a network of
networks, where does the consumer attach to this environment? As Will
suggested, one could do it through an existing provider relationship or
plan relationship or banking relationship but do you have to be mediated
by an existing, essentially in effect a RHIO member, to get at the
networks. So we have been trying to think in terms of that. And
essentially what we proposed is we have a common framework for consumer
access that anybody who is willing to subscribe to that framework can
play in this party, in this club. You can skip the next two slides. Let
me go to the one, that, after it says, \"Are we headed for integration
or just more silos?\"

The concern we had in looking at this work was that the PHR industry, as
we have seen it develop the last couple of years, seems to be a
replication of the healthcare fragmentation that we are all concerned
about, as each sector, whether it is the health plan or provider or
hospital, is developing its own way of serving its current population,
its members, its constituents, but not particularly developing a
cross-sector set of interfaces. So the patient typically has to have a
separate electronic relationship with CMS, with their PBM, with their
hospital, with their medical provider, with their pharmacy, because
those things don\'t cross-integrate with each other.

This picture I included here of this web service called FlightStats.
It\'s a nice example of cutting across a wide variety of data sources in
order to serve a consumer through one platform in a transparent way. And
this is flightstats.com, I think. And it\'s just a good little
illustration because you see even on this one page a variety of data
streams arrayed together to help a person answer a problem, which is
what\'s happening with the flight I\'m either waiting for or taking. It
includes weather data, tarmac data, where the plane is on the runway,
other ancillary streams.

And the next slide shows a little blow‑up of the architecture, which is
germane to our discussion, the upper right side of this. And if you look
at this, you can see it on your copy of these slides, at the bottom in
blue are data source, which you can think of as hospitals, pharmacies,
PBMs, whatever. In the middle they have an architecture, an enterprise
infrastructure, which essentially does the mapping and integration of
data across these different systems. And then at the top is a set of
analytics and outputs, to a variety of outputs, which could be e‑mail,
PDAs, third party aggregators, or whatever. The question of interest to
us is, what\'s the middle section look like? We are not going to try to
change the underlying diversity of American healthcare. Data is
basically going to stay where it is, in a widely distributed and
centralized federated environment. And we are going to generate a
variety of standardized outputs at the top of this picture and have a
pluralistic marketplace, as Will said, of innovative PHRs. Picture the
top gray levels as PHR vendors and applications. And they could be
enormously diverse, specialized by age group, health condition,
insurance class, or whatever. And there are going to be a variety of
those blue boxes at the bottom of data sources. Is there a need for a
mediating set of activities in the middle which connect them to each
other? In other words, we are not talking about PHR applications in our
work. We basically don\'t care about PHR applications. We are only
talking about the connection between the data sources and the outputs.
So the next slide says, we need to build this environment in a way that
all these elements are trustworthy.

So the next slide lists some of the things that we think these mediating
players need to do, this mediating function needs to do. We call it, as
Will said, a consumer access service. And all we mean by that is there
is a service with a small S. It\'s not a company. It\'s not an industry.
It is a set of functions which do these things. They distribute data and
services to populations of people. They manage the authentication issue,
which several people have talked about today as a sensitive one. And in
effect they vouch between the parties on a network, saying this is
really David Lansky, you can securely and properly transfer data to that
user, I\'m going to vouch that you have got the right person at the
other end of the wire. Presumably these services would help people
access and aggregate their data. And then, very importantly to us, they
would assure that networkwide policies are followed. Their in effect the
enforcement mechanism across the network to create the trustworthy
environment that we talked about.

So the next slide just goes back to our previous picture and shows that
with this now, instead of having three networks on this page, we have
two networks and a consumer access service playing the role \-- in fact,
at one point we called these consumer SNOs. They were essentially a
network of users, of consumers, who are now legitimately attached to the
larger network of networks. So they can now, through their consumer
access service, talk to the VA, RxHub, SureScripts, Sloan Kettering, or
whoever they want to talk to. This does not mean they have one PHR
product. That consumer access service could offer them 10 PHR products
for a variety of needs people may choose to have. It also doesn\'t mean
it\'s a new thing.

The consumer access service, as the next slide suggests, we have a lot
of them already in business or aspiring to be in this business. Many of
them are at this table and this call. So anybody who wants to play by
the rules of our proposed consumer access service can be a legitimate,
trustworthy representative of consumers on a network. The question is
what are the rules and technology requirements that anybody playing this
role would need to follow. So the next slide.

I think I said this previously. The consumer access has to be trusted by
its users. Naturally it has to be trusted by the other people on the
network who hold data. And we have to figure out what are the necessary
policies that you choose to subscribe to.\
\
If you jump to the next slide, this little picture is meant to \-- we've
talked at various times about a framework, privacy and security. On the
right‑hand side of the slide, in a box, are nine, pretty widely
accepted fair information practices. And versions of these are used in
Canada, Europe, and here, and so on. This picture just takes the list
of, whatever it is, 10 or 12 policy areas we have all in this committee
and elsewhere talked about. Disclosure, access to information, some of
the things that were on Kelly\'s list of services earlier, auditing,
data security, notification of breach. These, I think in Stanley\'s
previous presentation to us, this same list was pretty much appearing on
those other analyses that you have got on the Website. So assuming these
are the kinds of issues we are all aware of, this is a simple attempt to
map them back to a framework. If you flip it and say, what issues in
that framework are we not adequately tackling? So it becomes a kind of
litmus test or checklist to evaluate whether we are properly assessing
the integrity of the network from a privacy and security point of view.\
\
So the next slide applies this more practically to this idea of a
consumer access service. I\'m sorry about the amateur graphics. But you
have got Waldo over there on the right, who is an end‑user application.
Waldo there is sitting in his living room looking at a personal health
record on his computer. Through a chain of data hand‑offs and
relationships, over to the far left of the picture, Waldo is accessing
and integrating data from a wide variety of data sources, could be
hospitals, doctors, Medicare, pharmacies, PBMs, et cetera.\
\
What we are just sketching simplistically here is the recognition we all
have, there are a lot of players in this. It is not as simple as saying
the consumer is going to sit at home and electronically, with an
octopus, go out and grab all their data, populate a PC application, and
go on their merry way. In fact there are aggregators, some of whom are
on our committee, who already have relationships with data sources,
acquire data, aggregate it, massage it, add value to it in some way. We
already have, at that third node, the data store hosting service. We
have portals and others who are now aggregating data from aggregators
and putting it together in a way which makes it accessible to a
consumer. They may or may not also offer a personal health record
product. We also have in the middle space next to Waldo the PHR sponsor,
which could be, for example, an employer, who is not directly offering
any of these services but is in fact setting policies regarding the use
of the data.

The next slide asks the question, where does the policy go? Environment.
It is real world environment, where there are many links in the chain.
For example, the question of secondary use policies that Kelly and
others have highlighted, you can imagine that different nodes in this
data sharing network, which ultimately delivers data to me and you as
consumers, have different answers to the question of how will I use your
data. Some of these entities are under the catchment or cloud of HIPAA.
Some of these entities may not be. Some of these may say, as my silly
example on the far left here, we never share any of your data with
anybody except public health and subpoenas. We are playing by the
narrowest interpretation of our responsibility to protect your data. The
next step over, the aggregator one could say, if we ever sell your data,
it will be anonymized and we will ask for your permission. Third bubble
on here may say, look, we\'re selling your data. That\'s how we justify
giving you free use of services. Over at the far right, PHR application
has to, in our meetings here, somehow communicate the complexity of
these policy relationships to the end user. The question is, how does
Waldo know what is happening to his data across a series? And one person
said to me, there are actually about 14 of these handoffs in a typical
PHR application. So let\'s imagine there are 14 or 3, or whatever number
of intermediate data handlers, some which will be HIPAA regulated, and
some won\'t be. I think the question for us to ask ourselves is where
does policy overlay the real technology architecture that\'s out there,
and what are the instrumentalities of enforcing that set of policies,
especially as they go outside of current statute?

So the last slide, I think, asks some of those questions. What are the
policies that will be employed by each entity in this chain of
relationships? How will they be, once we define them, once we know what
those policies are, how will they be implemented and who will enforce
them? My view is that all the models we hear about here are worthy of a
try. And we should be encouraging all these models to go forth and
prosper and innovate and learn what\'s going to be valuable to the
public. But the real challenge, I think, at an advisory committee level,
is in these three steps. What are the policies that will apply to them?
How will they be implemented? And how will they be enforced?

**[\>\> Michelle Murray:]{.underline}**\
Rose Marie, do we want to have Stanley present? Do we want to have
Altarum present next?

All right. Stanley, why don\'t you go ahead?

**[\>\> Stanley Chin::]{.underline}**\
Yeah, I\'ll go ahead. And if I get ‑‑ I\'ll just launch into this.
First, thanks. This in some ways wraps up the analytical end of the work
that Altarum's done for the Consumer Empowerment Workgroup. First,
thanks for allowing me to present \[inaudible\].

This is specifically interoperability and data mobility. And in some
ways summarizes a lot of the work, a lot of the presentations we've
heard already today. I will talk you through our findings and our
approach. And it again, as I said, I think it reinforces many of
the points.\
\
On the first slide, just a point that we were asked to examine the
current status of PHR interoperability. We took a case study. We dove
into eight organizations and carried out these interviews in the
December, January time frame among COTS vendors, academic medical
centers, and others, including commercial data providers. So, look,
specifically it\'s the problems that they understand, overcome, the
mechanisms they use, architecture, whether it was in authentication and
identification or in this, focusing primarily on interoperability of
data. We anonymized these to the best extent we could, one we note is a
large government organization, several are academic medical centers.
Well, anyway, they\'re all in the United States.

Two dimensions of PHR interoperability, just to note, that we were asked
to look at was the PHR's ability to import and export data to and from
source systems, which turns out to be one of the interesting questions
there. And then the extent to which PHRs might be able to import or
export among each other for the purposes, for example, if a PHR vendor
goes out of business or a consumer wishes to shift PHR vendors. And we
talked about key barriers and ‑‑ next slide.

Now, I don\'t think any of the enablers will come as a surprise, but I
do want to reinforce the point that, when we found success, we found it
because there were underlying business models that were already
supporting standardized data, whether it was claims data, whether it was
pharmacy data. And a lot of this has to do with peculiarities of the
individual marketplace. So for example, pharmacy data, laboratory data,
readily available, transportable, and standardized. Imaging data is not
so. And I want to point out that if you look with the light of good, you
do run a risk of looking where current market peculiarities have caused
data to exist. So that\'s just an interesting \-- but the point is that,
where data are rapidly already flowing, already flowing now, PHR
certainly, PHRs we observed certainly were able to adjust to the rapid
prepopulation of claims data, laboratory data, some of which we observed
\[inaudible\] and others we have heard today.

Second point was, just in particular about the PHRs that we looked at
were the ones that were most successful in being able to move data in
and out and move data among each other using service-oriented
architecture, providing rich metadata to enable the PHR itself to know
what it had written before, as well as to share data \[inaudible\]. The
third point was that in a couple of instances we see the use of existing
document formats, whether it is CDA, Clinical Document Architecture, or
CCR, Continuity of Care Record or emerging hybrid Continuity of Care
Document. So we see these in use in several applications and locations.
And as a consequence, it\'s just an irony that it may be easier to move
data from one PHR to another, than to move data in and or out of a PHR
from a source clinical system. And that\'s simply going to be a fact as
long as they are using standardized document architectures so ‑‑\
\
As for key issues and challenges. Again, I don\'t think these are going
to come as a big surprise. I think there are some issues, some
interesting things that we uncovered that we had not expected to. The
first is just the issue of incentives. PHRs, as they stand, lack
sufficient market pull to induce sources to become more interoperable,
so where are the win‑wins, so that financial or other incentives that
may flow from the ability to share data can apply not only to the system
that creates interoperability but the others in the organization. And we
also note, and we\'ll note this a couple of times, what about data
originating from outside formal care settings? I\'ll come back to that.

The second point was actually raised by David Lansky just a moment ago
about business rules. How are business rules attached or made portable
to the data as it flows. It\'s an important issue that we note is not
solved in any of the current applications.

Third point, and this has to do with how data flows ‑‑ the third and
fourth points both have to do with how data flows, who controls the data
and to what end. We noted, for example, laboratory values, and a couple
of applications were held for a week or two weeks before they were
released to the patient. And the purpose of that was to allow the
provider who had ordered the lab to have a chance to interpret it and
write the interpretations and signings prior to this being released
directly to the patient. That\'s a model. That is a business rule that
is certainly not standardized but it does exist. This begins to run into
a problem if you have, for example, consumer initiated direct access to
testing and consumers are locked into a test facility and has ordered,
essentially asked for a test done directly.

So to the extent that you have data, clinical data flowing outside of a
clinical setting to an individual, there are issues of interpretation
and business rules associated with that that are going to be need to
be thought through. Conversely, when you have data merging from outside
the clinical the setting, whether it is individually entered or whether
it's through over‑the‑counter medications or whether it\'s through
(inaudible) medicine, those information flowing into a clinical setting
you have the reverse. Trust of those data by the physician. Those are
business rules and work flow issues that are actually quite, that we're
only beginning to touch on. The point of that was to say that technical
interoperability of data is the least of your worries at that point. The
fact that the data are there and this physician won't use it means that,
you know, you don\'t have interoperability at a functioning level. And
conversely, if the data are available but the consumer cannot interpret
it in any way, or there are some fears about how the consumer may
interpret those data, again, there is a challenge on the meaning of the
interoperability in that case.

The next slide is just a pretty picture that actually is similar to
other pictures, just to serve as an architecture saying you can flow
data, intermediate it in some way, and produce an interoperable
document. We have seen those.

Slide 6 is one of our more typical presentation slides, that is an
information dense slide. In this case I\'m not going to run through all
of the elements at the same rapid tempo, but simply say that they\'re
here, and we summarize the statements that we made earlier today about
how claims data, highly interoperable, highly available, and they have
all the issues that we know associated with claims data, prescription
data, again, noting the problem with laboratory data in some on the
results end, as opposed to on the order end. Radiology reports, issues
of clinical notes. Again, a point that was raised about chronic
\[inaudible\], although it is not ‑‑ sorry. About the ability for
patients, for example, to see notes, patient notes, and for example,
well, that may be for, intended originally for the physician\'s own use.
And then sources of data from outside the clinical setting, including
history, physical, and home health monitoring devices we noted that
although in a couple of places where home health devices are hooked up
using highly individualized interfaces, that that\'s a one off and it\'s
easy to break that interface the way things currently stand.

So again, thanks. And that is a very quick wrap up of, dive into a small
handful of case studies. Again, they are not, it\'s not a broad survey.
It is not intended to be representative. But there were specific
examples of successful systems and approaches that they had taken to
overcome particular issues in interoperability. So ‑‑

**[\>\> Rose Marie Robertson:]{.underline}**\
Stanley, thanks very much. As usual, that\'s very helpful. You know, the
concept that we, some of the functionalities and the items, you know,
people tend to put in the ones, it's a little like looking into the ‑‑
it is like looking into the lamp post for the thing you've lost. The
thing that\'s there shows up and gets used. It might or might not be the
most useful piece of information but it's handy to put in.

Questions for either, either for William or David, or for Stanley?

**[\>\> Christina Collins:]{.underline}**\
This is Christina Collins. I will jump in from the AMA if I could. I\'m
really intrigued by one of the key challenges that were identified here.
It's kind of interesting to me \[inaudible\] also be made portable or
otherwise attached to the data. And I guess something that sort of
created a lot of, I don\'t know, maybe internal turmoil for lack of a
better term, sort of looked at these issues from the physician
perspective. When we look at everybody who touches healthcare data, we
see a number of proprietary interests or business interests who have a
great deal of interest in the information that emanates or flows from
the physician\'s medical records. But what we also find is that
physicians are the only ones who really have the immutable principles
under the Hippocratic Oath that they are legally and ethically obligated
to uphold.\
\
So I guess I\'ve been sort of perplexed or troubled or confused or
generally stymied by the notion of what do we do with these differing
relationships? Because truly, that confidential information flows
between a patient and a physician under the expectation by the patient
that that information is being given within a confidential relationships
and it will be afforded the greatest degree of privacy possible. So once
you sort of get the information out of that lock box, sort of into the
arena of the public, and we don\'t really know how it is going to be
used or who is going to use it or who is going to touch it. So I\'m
really intrigued by the notion ‑‑ if you could sort of frame this issue
for me in a way that sort of made a lot of sense, and that is, it isn\'t
necessarily the holder of the data that maybe holds the individual
responsibility for how it is used or treated. And if you treat all data
just as data and, accordingly, give it a high level of confidentiality,
perhaps that ends a lot of the difficulties with provider information
flows we are seeing or even institutional flows internally. So thank you
for putting that bullet in, if for nothing else, for my personal
edification, I thank you. But I do think that might be a useful
construct for going forward to kind of understand where the pockets of
data are and why they stay there, and that there are indeed legitimate
legal reasons and ethical reasons for them to be there. But maybe work
from that framework as we are going forward in creating policies about
health IT in its entirety.

**[\>\> John Casillas:]{.underline}**\
If I could tag along with that, too. This is John Casillas, Medical
Banking Project. You said you were using XML in the diagram for your
documents.

**[\>\>]{.underline}**\
Yes.

**[\>\> John Casillas:]{.underline}**\
There is a field of XML called the EbXML. And in that field business
rules are actually imbedded in the document. So the rules are applied by
\[inaudible\], specifically by that entity looking at that document. And
there have been some pilot programs in the PHR arena, I think it is up
in the Netherlands, using that specific docs if you will.

**[\>\> Will Crawford:]{.underline}**\
And there have been a number of other, sort of similar proposals, like
the IHE, Integrating the Healthcare Enterprise standards also use a
similar approach of linking rules for data usage to the document
themselves, document itself. The way that we have approached it on
the Indivo project side is sort of two‑fold. The first is that we look
at this stuff from the perspective of the patient. So once the
information has gotten to the patient, then to a certain extent we
consider most of the other activities that some of the other actors
would have taken place, would have done with that data on its way to the
patient to be issues that sort of need to be dealt with separately. And,
if so, the data once it sits within the PHR is under the patient\'s
control. But then, you know, looking at the personal health record as
the NHIN gateway model, you start getting back to how do you ‑‑ you have
one set of constraints on that data that come from the original data
providers, you have potentially an additional set of constraints on the
data which you want to allow the end user to be able to impose as a
condition of their participation in the NHIN project. So from a
technology and standards perspective, whether it\'s via EbXML or some
other mechanism, how do you bring those two pieces together? Now, I
think that would be one thing that, assuming it can be wrapped in an
appropriate use case, would be an excellent HITSP project.

**[\>\> John Casillas:]{.underline}**\
It might already be, as I was saying, in the Netherlands I think they
have actually tested that.

**[\>\> Will Crawford:]{.underline}**\
There have been several. We have actually looked at it. We have worked
with, a group in Norway, actually, that\'s also been through another
variation on that. And then through IHE there have been the
connect‑athons. So it is available and it\'s certainly being explored,
and ‑‑

**[\>\> John Casillas:]{.underline}**\
And it\'s something, I mean, with the AMA and your concerns, there is
actually a technological capability that addresses that concern.

**[\>\> Will Crawford:]{.underline}**\
But there is still ‑‑ and I will just add, there is still a policy layer
that has to go on top.

**[\>\> John Casillas:]{.underline}**\
That\'s right.

**[\>\> Will Crawford:]{.underline}**\
Because you can represent, and, but then people still need to abide by
those business relationships. And creating that degree of assurance is
personally where I think a lot of the ongoing challenge is going to be.
And, you know, why the, you know, some of the work actually that
Connecting for Health is doing around establishing a common framework
for creating those agreements so that those technological instructions
can be followed up or used is almost the really key work.

**[\>\> Rose Marie Robertston:]{.underline}**\
Other thoughts or questions in this area?

**[\>\> Kelly Cronin:]{.underline}**\
I just ‑‑ this is Kelly. I have a question about concept of the
interoperability data sharing agreement I, think is one that a lot of us
think is really critical and want to support. And I\'m wondering to what
extent, with the chain that David showed, and the fact that there are
probably a lot of different ‑‑ well, actually this is jumping ahead.
Maybe I should wait until we hear from Steve. But, say, there is going
to be a lot of different ways that the data is used by different kinds
of applications or different ways to access. How do we know that the
people who offer, or the firms that offer those end applications that a
consumer will have, and those will be their tools that they use, that
they also are responsible actors in the system? So how do those
interoperability data sharing arrangements actually reach the firms that
offer the end application?

**[\>\> David Lansky:]{.underline}**\
This is David. We\'ve talked a lot about that issue, and \[inaudible\]
the Hotmail example, which is sort of our worst case, which is a person
gets all their personal health data and then sticks it in an open e‑mail
account. The answer is we cannot keep people from doing something stupid
with their own information when they have it. So then the question is,
what is the next layer up which is to the responsible vendors?

**[\>\>]{.underline}**\
Right.

**[\>\> David Lansky:]{.underline}**\
What is the mode, assuming people acquire, through a HIPAA-type of
request, direct access and control over their health information,
outside the protection of HIPAA directly, they are now free to do
something stupid with it. So on the range of enforcement, going back to
the policy problems that we have talked about, if we had a clear
framework for all the privacy issues we were concerned about or policy
issues we're concerned about, some of those might lend themselves to
contractual enforcement among parties. Some of them might require
statutory enforcement because it is public protection that cannot be
enforced, people will do something stupid unless we have a law
preventing them, discrimination or uses of data prior to \[inaudible\]
so I think having a complete framework kind of gets on that slide and
critically asking questions, not only that answers, but what are the
enforcement tools appropriate to each class of policy, would be an
important thing to do.

**[\>\> Rose Marie Robertson:]{.underline}**\
It\'s interesting that, you know, clearly people have always been able
to talk about or not talk about their personal health information
insofar as they, you know, ask a friend about a diagnosis or get advice
from someone or just, you know, share in ways that sometimes they wish
they hadn\'t. I guess the one difference is that the detail of what they
are sharing and the ability to share it faster with more people, you
know, either by accident or because they don\'t recognize the
implications, suddenly that can have an impact that they would have been
protected from before, to some extent, by, you know, by how the data was
handled. And that does, as you say, you can\'t keep people from doing
something with it that\'s they will wish they had not done. But it is a
new era of those kinds of mistakes.

**[\>\> Kelly Cronin:]{.underline}**\
Yes. The only thing I would add to it is that presumably, whether it is
a phone company or a bank or one of the PHR vendors that we have already
looked into, and again we have at least a preliminary understanding of
some of their privacy policies, those privacy policies, over time,
should be, should function with these emerging interoperable data
sharing arrangements for the intermediary, so that there is some
consistency there. There is an agreement on how they are going to deal
with the data and how they are going to protect the data. So while, you
know, we have, you know, everyone at the table here supporting the
concept of voluntary certification, which is one of many tools to try to
get the end applications to be responsible around privacy policies, I
think that ‑‑ I guess we just need ‑‑ as our thinking evolves in this
complicated evolving landscape, I think we need to be mindful of the
fact these end applications are, ideally the firms who offer them, are
going to have to have privacy policies that are also going to work with
these intermediaries or the people who are going to be handling the
data, and will need to be mindful of sort of who are these emerging
actors in both categories and how do we make sure that this suite of
legal mechanisms, whether it is contracts, certification, enforcement,
legal data sharing arrangements, that all of them take care of both
sides of the equation.

**[\>\> Rose Marie Robertson:]{.underline}**\
Right. Okay. If we don\'t ‑‑

**[\>\> David Lansky:]{.underline}**

One last comment. And Steve will amplify on this. One of the things that
really occurred to us, all of our discussion here is interesting; but
getting the information released from the current data holder is the
biggest barrier. And I think more time we have to think some more about
that would be valuable.

**[\>\> Kelly Cronin:]{.underline}**\
In terms of, how could we require timeliness in access, in electronic
access?

**[\>\> David Lansky:]{.underline}**\
We had a meeting with several very large delivery systems that had
millions of medical records and we asked them those questions. I think
the sense we had was there is no business reason they are going to make
it easy to release that data in an interoperable, compatible format of
any standard.

**[\>\> Steve Downs:]{.underline}**\
David, this is Steven. I think I was sort of, the way I structured
my presentation was kind of to end on that question. And hopefully tee
up a discussion among us.

**[\>\> Rose Marie Robertson:]{.underline}**\
Then this is perfect timing. Should we turn to Steve?

**[\>\> Steve Downs:]{.underline}**\
Thanks Rose Marie, and thank you very much for inviting me to present.

Just a really quick intro on The Robert Wood Johnson Foundation\'s
interest and also to set the context for this presentation. As a
foundation, we are not really interested in health IT per se but in
doing what we can to help people live healthier lives. And it is our
assessment, as it is the assessment of many people, that people are
going to have to be much more engaged in their own health and are going
to need the tools to do so, and hence our interest in health IT in
general and, then particularly, in the PHR area.

To that end we have a program that we are supporting called Project
Health Design. It is led by Patty Brennan at the University of
Wisconsin. It is really an effort aimed at rethinking what PHRs could
be, pushing out a couple of years into the future and where could we go
and how could PHRs evolve to become tools that people could really use
to manage their health. I want to acknowledge both David Lansky on the
call who is a member of our national advisory committee, and also Paul
Tang who is the chair of our committee. Now, could we go to the next
slide?

So for this presentation, I want to ask you all to think of personal
health records as an input to consumer products and services and not as
a product in itself. And what I mean by that is sort of the idea that
the data contained in your medical record can be of some utility if you
look at them, but potentially much more valuable if you use them to feed
applications that help you gain insights into your health or take
actions to maintain your health. Now, the top line in this slide shows,
I guess what I would call a traditional view, which is start with a set
of data, you know, your medical record, figure out how to provide some
kind of view onto it, and then really, usually typically a view of some
of it, and then offer that to the consumer and kind of make that
experience of sort of viewing your record as useful and valuable as
possible.

We\'re trying to approach this from a different direction which is to
start with consumer health needs, figure out what applications can help
them manage their health, and then figure out how data in medical
records can help. And it\'s sort of, if you go back to David\'s diagram
on ‑‑ we are starting at the other end of the chain basically, is how we
are conceiving this. So I guess for this talk I want to define PHRs as
the data maintained by the healthcare industry, and sort of in the sense
of, this will go down on your permanent record. So really, the data
themselves, not so much the wrap‑around features and functions. And I
will get to that in a while. If you go to the next slide.

We are seeing, I think what I would again call the traditional PHR, and
as, you know, populated by data from encounters with healthcare
providers, as one input into a broader set of information about
people\'s health. So just sort of to walk through this, you know, sort
of what other information might be relevant to your health? Just kind of
maybe going counter‑clockwise from the top left there. Again, data from
a healthcare provider or, more broadly, let\'s say, many of the
providers and other actors within the healthcare industry. You have got
sort of the Bluetooth-enabled pedometer which measures some of your
activity. You have got a cell phone camera taking pictures of your food
to track diet. You have got a USB stick coming off your treadmill. And I
guess if I were to update this slide, I would show the Apple Nike iPod
arrangement where the Nike shoes talk to your iPod and tell you how far
you have run and how many calories you have burned. There is a
Wi‑Fi-enabled bathroom scale, everybody\'s worse nightmare, and then a
continuous glucose monitor as well. And then the fairly distressed
looking gentleman is actually a representative of a headache diary, sort
of noting down whenever your migraine seems to be starting up. And I
think what then gets interesting is you use these data to generate
things like alerts. So if a trend is bad or a value out of range,
reminders, let\'s say, to take your meds or request a refill of
medication. And then I think also correlations, intelligence that says,
geez, you have really been gaining weight since you started taking this
medication, and you may want to talk to your doctor about that.

And I think the important point is that everyone would use a different
set of applications. These are just sort of a silly collection of
possible ideas. But we are a diverse country. Everyone\'s health
profile, their habits, lifestyles, their communication styles, their
information processing styles. They are all different, you know. We are
each unique. And meeting those diverse needs is, I think, really best
achieved when you have a marketplace of developers and entrepreneurs
constantly innovating. I\'m one of those folks that grew up in the era
of four TV networks, with a very limited menu. And this is much more of
a YouTube model. There\'s a lot out there, there's a lot for everybody,
and you can find exactly what you want.

So, you know, the vision is sort of, rather than subscribing to a kind
of what I call a vertical PHR service, one that bundles both your data
and the features and functions, rather than that kind of service that,
let\'s say, over time is adding features and modules, you know, and say,
we have just added an asthma module or just upgraded our ability to
chart trends in your data. It is really much more of an envisioning a
limitless array of tools that can build on a basic PHR. And some
analogies to throw at you. You know, in the early days, actually really
kind of before the Internet took off as kind of a mainstream operation,
the telephone companies were very focused on sort of their version of
the Internet which was, you know, Verizon before they were Verizon was
planning, well, we will provide health information service so people can
learn about health. And we will provide home banking and we'll make a
partnership with two major banks or one major bank, and everyone can do
their online banking with that bank. Obviously a very different vision
than what happened with the Internet and the Web, which is much more of
a platform where lots of innovation could happen. Another example would
be, if you think about a Windows operating system or MacOS. You know,
Apple and Microsoft both write applications that run on their operating
systems. But more importantly, they have APIs that give developers
instructions on how they can write applications that run on their
operating systems. A third example might be Google Maps, where there are
lots and lots of interesting innovations going on with the Google Map
technology to do things like, I think some of the sites I\'ve seen,
calculating New York City cab fares and you can clock your jogging,
figure out how far you are running, stuff like that.

So this ‑‑ that\'s the broad vision. But then working with our Project
Health Design grantees we are starting to get the sense the data
contained in official medical records are really potentially just the
tip of the iceberg. And then the next slide shows a listing of some of
the data that can be recorded in the home, so if you can go to that.

This is just partial lists. But what we are really seeing is that new
technologies are creating options for recording a lot of this passively
and non‑intrusively. To be realistic, everybody has a different
tolerance for how much time and effort they want to spend recording
information about their behavior and how they\'re feeling. But you know,
and most people\'s tolerance is fairly low. But there is a lot going on
with sensors, for example, that can be used to track sleep or to track
your gait as you walk across the floor or whether you have opened the
pill dispenser in your medicine cabinet. There are pedometers and
accelerometers that can start to capture physical activity. I think even
just the basic task of recording personal observations is getting easier
as well. So rather than saying I have to go to my bedroom and sit down
in front of the computer and type something in, for example, we are
working with a grantee who is looking at chronic pain and saying, you
know, you carry around a cell phone and if you start to experience a
back spasm, say, you just tap a few keys on the cell phone and it\'s
recorded. So I think that\'s getting a lot easier. I think again, if you
play this out over 5 to 10 years, I think the ratio of how much
information you can capture versus how much effort it takes and how
intrusive it is to capture data is going to get higher and higher and
higher so we will have a lot of this available. So if you can go to the
next slide.

The vision that\'s coming out of this program really implies kind a
many-to-many architecture. Just to walk through that diagram. The user
on the left has multiple information or communication devices. I\'ve
shown three here: the laptop, the cell phone, the pedometer. But I left
out the TV, the game console, the iPod, the smart wristwatch, and who
knows how many other technologies that will be down the line. You know,
as in some of the other slides we have seen today, multiple data
sources, a lot of the traditional medical record data sources, but also
some of the ones that I pointed out in the earlier slides of the
home-generated data. So, you know, the things you might tap into your
PDA or sort of the passive monitors around the house. And I think also,
you know, these data sources, it's probably a misnomer because I also
think in here you want to possibly have things like information
resources. So let\'s say a nutrition diary. So if you are entering
information about the food you are taking, you can actually then take
that information and essentially look up comparable, or look up
information about nutrition content and be able to do some analysis on
that. Or it maybe medication instruction sheets. You know, a database
like that would be useful as well, or databases on drug/drug
interactions.\
\
And then in sort of the kind of the brown oval there, this is really the
software tools, the applications that analyze these data, make sense of
them and communicate with the user. So to walk you through kind of a use
case: think about a medication reminder system that runs off of, or
notifies you on a cell phone. So you get a prompt on your cell phone
that says, hey, it is time to take such and such a pill. But it also may
be, have the intelligence to check on the instructions for that. So it
may say, however, before you take it, are you planning to eat in the
next half hour? If not, it is not a good time or, if you are, it is not
a good time to take it. You may also then have a prompt, as your
medication starts to run down, a prompt, you may get an e‑mail message
that says time to refill. And then the other thing may be, you know, an
application that then starts to correlate the fact you have started
taking this medication in the last month to say, geez, your sleep has
been much more fitful over the last four weeks that you started taking
the medication. That may be an issue, or you may want to do something
about that. As you can see, it really integrates a lot of, whether it's
different devices, different data sources, and then, you know, a series
of different software tools.

If you go to the next slide, you know, what I\'ve done is sort of thrown
in a layer of, for lack of a better term, just calling it middleware.
This is a bunch of stuff that needs to sit between the data and the
applications. And actually if you turn this diagram on its head, sort of
rotate it clockwise, it doesn\'t look all that different from the
diagram that David showed about the flightstats.com architecture.
Anyway, in that middleware it is going to deal with things like finding
the data, authenticating the users, resolving vocabulary issues across
different sources, managing calendars. I think there is probably a real
need for consistent calendaring approaches in all of this, and other
services.

So to sort of get to this vision, I think we need to separate the
applications from the data. And I really like the way Will put it, sort
of make the data part of the plumbing. I think that\'s an excellent way
of framing that. And then I think the second thing is developing
standard API, application programming interfaces. If you think back to
the sort of brown ovals, this is really where the innovation happens.
That\'s where the developers and the entrepreneurs are saying, I want to
create a widget that helps somebody do this task or this series of tasks
and I need to grab certain data from different sources. And you
certainly don\'t want to have to make that task hard for the developers
if you want innovation in that area. So the degree to which, you know,
they can, through some sort of Web service request, say, you know, pull
current medication list from out there in the cloud of data providers,
you want that to be as simple as possible. And I think kind of standard
or common APIs is certainly a way of doing that.

So now I want to shift gears a bit and talk about then the data that you
do find in the medical records. And as it turns out, this does sort
of ‑‑ if you could go to the next slide ‑‑ rehash some of the earlier
stuff. But it is, sort of where are these data coming from. There are
the primary sources, I guess, I would call them that we are all familiar
with, the physician office and hospital, labs, et cetera. The
aggregators and integrators. This is really a fairly similar list, maybe
more compressed than what David offered. And certainly there are lots of
others in there. Obviously the SureScripts, RxHub, I think the
Aristotelian Indivo, probably fits in the aggregators, integrators as
well. I also think the primary source organizations can certainly play
that role as aggregators and indicators, integrators.

You know, I like to look to the sort of financial industry as an
analogue to this. And I think about mutual fund companies like Vanguard
and Fidelity that, not only do they, in their portals, their sort of
personal financial record product, not only do they show you the
accounts that they maintain on your behalf but they, if you give them
PIN numbers, you know, or user names and passwords for other companies
where you have funds, they will put it all together in one view for you.
And I think that\'s something that you think about. No reason, no
technical reason, one would think, in the long run that, let\'s say, up
in Boston, Partners and CareGroup couldn\'t pull from each other\'s
sites and each offer you a complete view of your records across both
systems.

So if we could then go to the next slide, and this is kind of what David
was alluding to just before I started talking, which was the key
assumption in all of this. And that key assumption is that you can
authorize an agent to retrieve information about you on your behalf and
that this request will be honored. And I think Stanley talked about this
as well, the incentives and policies, you know, are they really there?
You know, getting back to the Partners and CareGroup example, I mean, I
think ideally you want those to compete, at least on the information
side, on how well they present a portal to you, or how well they present
your information to you in a portal, how sort of service-rich is their
offering. Not, you know, which of them has more data about you. That
doesn\'t seem like the best basis on which to compete.

So, you know, the central question that I was really hoping that we can
talk about is sort of how do we get there. How do we get to the point
where, if you authorize a Yahoo or an Indivo or one to pull down your
data on your behalf and manage it for you, how does your ‑‑ what compels
or impels your provider to release that data in a usable way that makes
all of this possible? That\'s a key question. But there is also a
secondary question that may also be worth discussion, and I think in the
long run is quite interesting, is what do we all do with this patient
source data? I think a lot of the discussions really think the patient
source data as sort of annotating a record or adding a couple of bits to
a record. What if we are looking at the bottom of the iceberg with the
patient source data? Sort of some ‑‑ and some of the questions are
who\'s running all the analytics? How are you taking, let\'s say,
frequent measurements per day about certain clinical values and running
some analysis on them so that a clinician doesn\'t have to see every
data point but instead is able to the separate the clinical signals from
the noise? I think there are questions about then, how does it get
shared with healthcare providers, and sort of what happens after it is?
What control do you give up once you have taken a bunch of measurements
at home and then imported or exported them into your provider\'s EHR?
You know, what liability comes up? If you are providing a whole lot of
data about your day‑to‑day health to your provider, what does that
require of them to look at it and to make judgments based on it? So
those are some issues. I also think, kind of just to close, that the
opportunity is really striking, I think, with all of this.

Justin Starren had a great quote about diabetes management today. And he
said, he said it is akin to driving around in a car in a city with all
the windows blacked out, and then every 10 minutes or so rolling the
windows down, looking where you are and adjusting course. Presumably he
meant that you are driving around a city where there are no other cars
driving, because that would be really dangerous. But I think the idea
is, the analogy is really powerful. We are always taking snapshots and
then adjusting based on those snapshots. I think to get a complete
picture of one\'s health is quite exciting.\
\
Jay Sanders had another point. He said, if you think about how you get
your blood pressure taken. You know, sort of going into, you know, a lab
or a physician\'s office to do it, sort of outside of the flow of your
daily life, in a sort of potentially unfamiliar environment is not going
to give you an accurate reading of your blood pressure. It\'s not your
blood pressure as you live your life. And that if you were able to do it
on a much more regular basis doing things that you normally do, we would
have a very different picture of what blood pressure is right for you
and what your, how your blood pressure relates to your health.

So again, I think some really interesting opportunities with this. And I
look forward to the discussion.

**[\>\> Rose Marie Robertson:]{.underline}**\
Good. Terrific. Thanks so much. Those are important points on the
potential for this to really improve things and to give us a better view
of health and to provide people tools that they need is, I think,
tremendous. That\'s, I think, why we are excited about it.

I don\'t want to shortchange hearing from Ross and Deven about the joint
subgroup from Consumer Empowerment and CPS on the privacy policy
components. So I might, since we are at 3:40, maybe let me turn to ‑‑
actually, I don\'t know. Is it Ross or Deven or both of you who are
there to give us an update?

**[\>\> Michelle Murray:]{.underline}**\
Rose Marie, I believe Deven is on the phone.

**[\>\> Deven McGraw:]{.underline}**\
Yes. I am.

**[\>\> Michelle Murray:]{.underline}**\
Deven, do you want to give us a quick update?

**[\>\> Deven McGraw:]{.underline}**\
Sure. We have, I think, gotten off to a real good start. What we are
doing right now is really sort of compiling a lot of information about
sort of what is out there in terms of PHRs and different policy, privacy
policies, what those components are, what they cover, what they don\'t
cover, and then adding sort of a rating, of the sort of risk that\'s
involved if something is absent or, absent in sort of a less than
complete way for each of those components. And then, you know, sort of
being able to make some sort of assessment going forward once we\'ve
sort of gone through that exercise, which I think we are fairly close to
completing with the great, the terrific help that we have had from the
staff. Michelle, I don\'t know if you are there, if you have anything
you want to add to that piece.

**[\>\> Judy Sparrow:]{.underline}**\
She\'s stepped out, Deven.

**[\>\> Deven McGraw:]{.underline}**\
Oh. All right. Well, that\'s fine. I know you guys are on a tight
timeframe. The other thing that I was asked to report on is that the
Confidentiality, Privacy, and Security Workgroup did hear some testimony
in its last meeting from some PHR vendors, which was very interesting,
and I will just sort of hit the high points. I\'m sure that testimony
is, if it\'s not posted on the Web already, it can be, and of course
made available to you by the ONC staff.

In particular we heard from a company called LAXOR and then WebMD who
are both, they both have PHR products on the market out there. The LAXOR
testimony really is much more detailed with respect to the actual
product. The WebMD testimony is sort of more along the lines of, you
know, what their recommendations would be with respect to setting
privacy standards moving forward. Both really acknowledged that they
know they are not covered entities under HIPAA, and both ‑‑ LAXOR, in
particular, actually went through the HIPAA regulations and looked at
what requirements would apply to their particular business and are
voluntarily complying with them and making it known to their customers
that they are doing so. WebMD made it clear that they thought their
privacy policies, which are posted on the Web, are meeting or exceeding
industry standards.

One other kind of major point that was really made by both of them was,
that they thought it would be valuable and helpful to sort of set a
minimum set of standards that PHR vendors would have to abide by if, for
no other reason, than their recognition that even one bad privacy breach
by one vendor, even if it is not them, would essentially tank their
entire industry. People would lose all trust in the product in general.

So both products appear to be heavily patient-controlled. I just came on
to the tail end of the presentation that you just had. One of the things
that was also interesting about LAXOR is that they have administrators
that help populate the records. So when the patient gives consent to
share information, give consent to have their providers populate the
record and then also those LAXOR administrators to go and get that
information for them which, you know, didn\'t appear to be the case with
WebMD. It wasn\'t 100 percent clear how that record got populated, but
it looked almost as though the consumer was responsible for grabbing
that data and making sure that it was in the record.

So I don\'t ‑‑ again, because I know you guys have very little time,
I\'m not sure what other information will be helpful for you to know.
Again, the testimony, we do have. We also, during our meeting, heard
about two pharmacy information exchanges, SureScripts and RxHub. And
then also we heard about the health information exchanges being
established in Massachusetts, Rhode Island, and Delaware. So there is
testimony available from all of those as well, with similar detail.

**[\>\> Rose Marie Robertson:]{.underline}**\
Deven, one question I would raise for the joint group is that the, you
know, in the testimony today there have been some very, I think,
important and interesting questions and issues raised. I particularly
liked David Lansky\'s graphic about, you know, the issues such as how
do, you know, how are privacy statements tied to data as data flows. Are
they or, you know, do ‑‑ in that, very nicely demonstrates that you can
have the same data being, with different privacy regulations or policies
applied to it at different points in the chain. And so thinking about,
this was one reason we wanted to think about the health information
exchange world to some extent, because that obviously is important to
this and as the level of complexity beyond the individual personal
health record, or EHR itself. So I guess I would just encourage the
subgroup to look at the slides from today as you bring your information
together to see if that modifies your thinking.

**[\>\> Deven McGraw:]{.underline}**\
I appreciate that suggestion very much. We will definitely do that.

**[\>\> Rose Marie Robertson:]{.underline}**\
All right. And we will hear back from that subgroup. Remind me when you
will be reporting back to us.

**[\>\> Deven McGraw:]{.underline}**\
Oh, that\'s a good question.

**[\>\> Rose Marie Robertson:]{.underline}**\
Michelle, does ‑‑ Michelle or Kelly, do you have ‑‑

**[\>\> Michelle Murray:]{.underline}**\
Yes.

**[\>\> Rose Marie Robertson:]{.underline}**\
‑‑ a timeline.

**[\>\> Michelle Murray:]{.underline}**\
We have a couple of meetings more planned with the subgroup, and hoping
to get our component rankings back in June and hopefully in time for the
next June meeting for CE or soon after. But we will aim for that June
13th meeting.

**[\>\> Deven McGraw:]{.underline}**\
Yes, it\'s tight.

**[\>\> Michelle Murray"]{.underline}**\
Yes. It is a tight time frame. It kind of depends what comes up in our
sub group. We already slowed down a little bit to rework some of the
components before we ranked them. Kind of depends how the ranking goes,
but that is our goal.

**[\>\> Rose Marie Robertson:]{.underline}**\
Okay. And so we have cut back a little bit on the discussion we had
about the last set of topics, but I actually wanted to use some of these
next few minutes to hear from the Workgroup. Rather than
recapping action items, I would like to see if there is, if there are
informational items that the group would like to hear at the next
meeting in terms of some of the things we have talked about today. Do we
think we have sufficient information about health information exchanges
as they now exist, or really more than exist, are being developed. Do
we, are there, is there additional testimony we would like to hear? So
just from the group about information that might be helpful to us in
this particular area.

**[\>\> Lorraine Doo:]{.underline}**\
Rose Marie.

**[\>\> Rose Marie Robertson:]{.underline}**\
Uh-huh?

**[\>\> Lorraine Doo:]{.underline}**\
Good afternoon. It\'s Lorraine.

**[\>\> Rose Marie Robertson:]{.underline}**\
Hi.

**[\>\> Lorraine Doo:]{.underline}**\
Hello. And in order to answer your question, for what purpose? Are we
gathering, you know, for example our presentations today, which were
excellent, are we trying to make additional recommendations to AHIC
based on the information?

**[\>\> Rose Marie Robertson:]{.underline}**\
I think we do want to be certain that as we think about recommendations
we may make to AHIC, that we see if there are further recommendations
that we would make, that we understand this arena clearly, and
particularly as we receive back the information from our subgroup from
the, our joint subgroup, this seemed to be an important piece of
information, so ‑‑ an area of information. So we will be looking at the
subgroup\'s recommendations back to us. But I think we want it in the
context not ‑‑ so we develop a very full context, I think, for
developing personal health records. I think this Workgroup, you know,
knows more about the personal health record scene in the United States
than any other group of human beings probably, having, you know, seen so
many of them, having heard testimony from others. So I think we are very
knowledgeable about that. But we may not, I was not certain we were
quite so knowledgeable about health information exchanges and how they
were developing. So I just wanted to be sure whether, see if today\'s
presentations seem sufficient or whether we need more information there,
or more discussion.

**[\>\> Lorraine Doo:]{.underline}**\
Well, again, this is Lorraine. I can tell you from our perspective, from
a Medicare perspective, a couple of things. One, actually everyone would
like to have Medicare data, for example, for these Health Information
Exchanges and the RHIOs and the other networks. And the big issue goes
back to what many of the presenters talked about, which is the policy
related to the release of the data. So, you know, the push me or pull
you. Do I push a button and say, you know, yes, you can populate this
PHR, or do I get something and send it in? So that whole concept of
consent and authorization, you know, how that\'s obtained, where it is
logged, what happens when the person dies or discontinues. It\'s
extensive, as any of the presenters know. And we are wrestling with that
because we are going through a business process model so ‑‑ and that may
be what we get to in the next wave of our CPS combined group between
Consumer Empowerment and CPS.

**[\>\> Rose Marie Robertson:]{.underline}**\
Would it ‑‑

**[\>\> Lorraine Doo:]{.underline}**\
But that\'s one of the biggest stumbling blocks.

**[\>\> Rose Marie Robertson:]{.underline}**\
Yes, I can ‑‑ would that be, would it be good for you to, would you want
to talk to us or have CMS talk to us about that issue, or do you think
it will come up appropriately within that next piece of information?

**[\>\> Lorraine Doo:]{.underline}**\
Well, depends on, I guess, the outcome of ‑‑ and I apologize. I
don\'t ‑‑

**[\>\> Rose Marie Robertson:]{.underline}**\
Yes.

**[\>\> Lorraine Doo:]{.underline}**\
‑‑ the woman who just spoke, about that ‑‑

**[\>\> Rose Marie Robertson:]{.underline}**\
Deven.

**[\>\> Lorraine Doo:]{.underline}**\
‑‑ privacy policy analysis.

**[\>\> Rose Marie Robertson:]{.underline}**\
Right. Deven, is that going to be included, is that part of your thought
process?

**[\>\> Deven McGraw:]{.underline}**\
It certainly should be, so I\'m glad I hung on the line.

**[\>\> Rose Marie Robertson:]{.underline}**\
Okay. All right. So perhaps we will see how that, we will see what that
report brings forward.

**[\>\> Lorraine Doo:]{.underline}**\
Yes.

**[\>\> Rose Marie Robertson:]{.underline}**\
But that\'s a very important, very important point.

**[\>\> Lorraine Doo:]{.underline}**\
Well, it is the key starting point to the release of the information.

**[\>\> Rose Marie Robertson:]{.underline}**\
Right.

**[\>\> Lorraine Doo:]{.underline}**\
Exchanges can\'t have the data unless we figure out how to get it
authorized, particularly because they are not covered entities and it\'s
not for treatment.

**[\>\>]{.underline}**\
Right.

**[\>\> Justine Handelman:]{.underline}**\
One thing ‑‑ this is Justine from Blue Cross/Blue Shield ‑‑ that may be
helpful to the group :we have several of our plans that are working with
Health Information Exchanges in their communities. And obviously we have
a wealth of data. And I know Louisiana is one, for example, that has
brought together the whole community after Hurricane Katrina to rebuild.
We have been a key project. But the stakeholders have the hospitals, the
physicians. And this issue of data sharing has come up quite a bit, and
they\'ve grappled with a bit, but made a lot of advances in that area.
And part of that component as well is Blue Cross/Blue Shield of
Louisiana, which has the primary market share in that area, is rolling
out now a personal health record and will also be working with CMS in
that area. So there may be some lessons learned and some issues they
have overcome in working with the community and all stakeholders and
health information exchanges and empowering consumers with the tools.
That might be useful, and I would be happy to work with them or one of
our other plans in another state, if it makes sense to talk about some
of these issues and how they have overcome the data sharing, and whether
they have overcome it. In some areas they have, and where some of the
existing barriers exist and any recommendations they may have.

**[\>\> Rose Marie Robertson:]{.underline}**\
I think ‑‑ that would be very useful. I\'ve heard some about Louisiana.
I think it would be useful to bring that to the group. So, Michelle,
let\'s keep that on our list for the next time.

**[\>\> John Casillas:]{.underline}**\
There's something else ‑‑

**[\>\> Rose Marie Robertson:]{.underline}**\
Other comments or thoughts from the, from anyone on the Workgroup?

**[\>\> John Casillas:]{.underline}**\
Yes. This is John Casillas.

**[\>\> Rose Marie Robertson:]{.underline}**\
M\'hmm.

**[\>\> John Casillas:]{.underline}**\
\[inaudible\] Workgroup. A lot of work, we did four years of work on how
HIPAA applies to banks, and we would certainly be willing to ‑‑
\[inaudible\].

**[\>\> Rose Marie Robertson:]{.underline}**\
I don\'t know if others can hear you, but I can\'t.

**[\>\> John Casillas:]{.underline}**\
Sorry. I said we\'ve done a lot of the work in how HIPAA applies to the
banking arena, and we are certainly willing to provide that to this
group as well which is, you know, that\'s, that\'s kind of a complex
area. And the other thing is, when you guys talk about HIPAA-covered
entities, are you talking about health plans and providers or
clearinghouses or all three?

**[\>\>]{.underline}**\
Oh, it\'s ‑‑

**[\>\>]{.underline}**\
Yes, this is ‑‑

**[\>\> Lorraine Doo:]{.underline}**\
All three.

**[\>\>]{.underline}**\
‑‑ covered entities.

**[\>\> John Casillas:]{.underline}**\
Okay. Because the covered entity under HIPAA, if it is a clearinghouse,
the administrative safeguards are not as stringent a health plan or
healthcare provider. I just wonder which set of standards you are
looking at.

**[\>\> Lorraine Doo:]{.underline}**\
Which standards are you looking at?

**[\>\> John Casillas:]{.underline}**\
Well, in ‑‑ if you are a clearinghouse, the administrative safeguards in
terms of having a privacy officer and some of the other requirements
were scaled back because they always assumed that clearinghouses would
have business associate contracts.

**[\>\> Lorraine Doo:]{.underline}**\
Is someone from OCR there?

**[\>\> Susan McAndrew:]{.underline}**\
Yes. I mean, the references to safeguards (inaudible) ‑‑ but to be
administrative requirements.

**[\>\>]{.underline}**\
Yes, because administrative safeguards and security aren\'t scaled back
for anybody.

**[\>\>]{.underline}**\
Right.

**[\>\>]{.underline}**\
For security.

**[\>\>]{.underline}**\
For security.

**[\>\>]{.underline}**\
Talking about for privacy.

**[\>\> Susan McAndrew:]{.underline}**\
We did relieve clearinghouses of some of the administrative apparatus
that another covered entity would have because of their general lack of
direct consumer relations. So there was no need for a privacy officer
because ‑‑

**[\>\>]{.underline}**\
I ‑‑

**[\>\> Susan McAndrew:]{.underline}**\
‑‑ you know, a patient is not going to know that a clearing ‑‑ which
clearinghouse, if any, has ever transacted, been involved in the
transmission of this information, you know, so they have lighter
training requirements. They have lighter policies and procedure
requirements. And by and large, from a privacy perspective, they are
looked at more as a covered, more as a business associate than a
full‑fledged covered entity. But as Lorraine was saying, from a security
point of view, anyone involved in the electronic transmission of data is
subject to the security rule, and those requirements would apply.

**[\>\> John Casillas:]{.underline}**\
I think it might be applicable here, because we talked about these
intermediate health information exchanges, and they may not have a
direct patient relationship, is what I\'m getting at, and so they might
have more of a ‑‑ there needs to be a comparison, I think, with that
market structure and the HIPAA clearinghouse structure. It seems more on
par with what those guys are doing.

**[\>\> Susan McAndrew:]{.underline}**\
Right.

**[\>\> John Casillas:]{.underline}**\
Possibly. I\'m just ‑‑

**[\>\> Susan McAndrew:]{.underline}**\
Yes, within the Confidentiality, Privacy, and Security subgroup,
Workgroup, in looking at what to do, what kinds of privacy principles
ought to apply to entities not currently covered by HIPAA, one of the
considerations is, while they want the substantive, they\'re
recommending substantive privacy principles be the same across the whole
architecture. But some of the other HIPAA‑like principles may need to be
adapted, depending on what kind of function is being played by these
other parties, what kinds of information do they have, and for how long
do they have it. So all of that is being talked about.

**[\>\> Kelly Cronin:]{.underline}**\
Yes. And Sue brings up a good point. There have been a series of public
meetings that the CPS Workgroup has had now on this issue of what
happens beyond HIPAA and how do we assure that there is consistent
privacy protections outside of covered entities and business associates.
So ‑‑ and it brings up the point in general that a lot of our discussion
today really is going back to privacy policy, which is absolutely
critical to what we were trying to get our hands around, or our minds
around. But I think we need to, again, think about how we are going to
work carefully with the CPS Workgroup as we get further down this road.
Because there is clearly a lot of needs here. And they are
already fairly far down the road of considering what are they going to
do for these non-covered, non-business associate entities. And they
haven\'t probably had the depth of discussion that was here today in
terms of what does this future world look like, how might these actors
be working together? They have heard a lot of testimony, but not to the
degree that we heard today on what the future of personal health records
might be. So I think it is just some homework for us to figure out our
next steps in working with them and trying to really make sure that
whatever set of privacy principles and framework, or roadmap, whatever
is going to be put together for the next few months, that it takes into
account everything we\'ve heard today, in context. And either we
participate in sort of fleshing that out or they benefit from everything
that we have learned today.

**[\>\> David Lansky:]{.underline}**\
Rose Marie, this is David. If I could ask you and Kelly both, going back
full circle in this meeting, to Kelly\'s opening comments about the
trial implementations for the next round of NHIN, I would hope there is
a way we can fold today\'s discussion into that process so that the
successful applicants to those projects are working under the umbrella
of whatever the current best guess is about this policy. And I don\'t
know what sort of process and schedule looks realistic, but some kind of
dynamic.

**[\>\> Rose Marie Robertson:]{.underline}**\
Yes. Kelly, that\'s a good question ‑‑

**[\>\> Kelly Cronin:]{.underline}**\
Yes. Let me take that back to talk to folks here, I\'ll talk to Rob and
John in particular. We are close to releasing. It is in our contract
office now to just take care of the minutiae. So given that it is so
close and that we really need to get money out the door by the end of
our fiscal year, really over the summer, I\'m sure there is
opportunities, we not only plan to have public meetings around it but we
plan to have, really, an operational cooperative. And in some early
meetings, I think there could be a lot of context-setting and a lot of
information disseminated on here is the current thinking around privacy
and security. And I think we could probably somewhat synthesize the
testimony from today, and our discussion, in trying to get into the
formation of that. But I think there would likely be opportunities for
communication with the awardees very early on in the process.

**[\>\> Rose Marie Robertson:]{.underline}**\
Let me ‑‑ we have not yet turned to public comment. Let me just check
and see if we have any listeners who wish to make comments.

**[\>\> Matt McCoy:]{.underline}**\
There is a slide up on the Webcast now for members of the public who
have been following along. There is a phone number up there and simple
directions for alerting the operator that you want to make a comment. If
anybody has already called in, just press star 1 to signal the operator.
And I'll check back with you in a minute or so to let you know if
anybody dialed in.

**[\>\> Rose Marie Robertson:]{.underline}**\
Thank you. So, Kelly, thank you for that answer. Wanted to make sure we
didn\'t miss the public here.

Other comments or ‑‑ the testimony today has been very helpful, I think,
in terms of framing this area in terms of potential challenges,
barriers, and enablers. Any comments or further questions while we are
waiting to hear?

**[\>\> Christina Collins:]{.underline}**\
This is Christina Collins, AMA again. And I guess it\'s something that
certainly would highlight this, and perhaps another foundational issue
that maybe doesn't bear discussing or even noting right now. I think as
we sort of had our discussion of the role-based levels of security that
is afforded the health data, and certainly within the context of HIPAA
and what\'s going to cover who in what circumstances if you are a record
bank and whatnot, I think one principle that I would like to
respectfully submit that this, that we go very far to truly empower
consumers, ensuring that any privacy and security principles surrounding
EHRs be simple. Even as an attorney \[inaudible\] on my career on, with
the privacy securities responsibilities that they had. This is hideously
complicated. You can have this brilliantly constructed apparatus, but if
it isn't something the average consumers in the throes of trying to
receive or health care of their own, or have it delivered to someone
they care about. I think really has to be the guiding
principle \[inaudible\] privacy and security.

**[\>\> Rose Marie Robertson:]{.underline}**\
Thank you.

**[\>\> Matt McCoy:]{.underline}**\
Nobody is calling in with public comments today.

**[\>\>]{.underline}**\
Say again, I\'m sorry?

**[\>\> Matt McCoy:]{.underline}**\
No public comments on the phone today.

**[\>\> Rose Marie Robertson:]{.underline}**\
All right. Very good.

Then if we have no other questions on the phone we will, or comments, we
will adjourn today. Thanks, everybody, for their comments, and
particularly our testifiers. And we will get back together again June
13th, and we will hear from the subgroup at that point. Kelly or
Michelle, Judy, any other ‑‑

**[\>\>]{.underline}**\
\[Inaudible\]

**[\>\>]{.underline}**\
Thank you.

**[\>\> Rose Marie Robertson:]{.underline}**\
Very good. Have a good rest of the afternoon.

**[\>\>]{.underline}**\
Thank you.

**[\>\>]{.underline}**\
Thanks everyone.

**[\>\>]{.underline}**\
Bye everybody.

**[\>\>]{.underline}**\
Bye.