[This Transcript is Unedited]

DEPARTMENT OF HEALTH AND HUMAN SERVICES

National Committee on Vital and Health Statistics

Hearing on the Functional Requirements

for the

Nationwide Health Information Network

July 26, 2006

Hamilton Crowne Plaza Hotel
1001 14th Street, NW
Washington, DC 20005

Proceedings by:
CASET Associates, Ltd.
10201 Lee Highway, suite 180
Fairfax, Virginia 22030
(703) 352-0091

TABLE OF CONTENTS

P R O C E E D I N G S (9:04 a.m.)

Agenda Item: Call to Order, Welcome and Introductions

DR. COHN: Why don’t we get started? Would everyone please be seated?

I want to call this meeting to order. This is the first day of two days of
meetings of the Work Group on the National Health Information Network of the
National Committee on Vital and Health Statistics. The National Committee is
the national advisory committee to the U.S. Department of Health and Human
Services on national health information policy.

I am Simon Cohn. I am Associate Executive Director for Health Information
Policy for Kaiser Permanente, and Chair of the committee and this work group. I
want to welcome committee members, HHS staff and others here in person, and
also welcome those listening in on the Internet. I want to remind everyone as
always to speak clearly and into the microphone, so that those on the Internet
can hear us.

With that, let’s have introductions around the table and then around the
room, and then we will move into discussion and agenda review for the next day
and a half.

For those on the National Committee, I would ask, if you have any conflicts
of interest related to any of the issues coming before us today, would you so
publicly indicate during your introduction? I want to begin by observing that I
have no conflicts of interest.

MR. REYNOLDS: Harry Reynolds, Blue Cross Blue Shield of North Carolina and
member of the committee, no conflicts.

DR. LOONSK: John Loonsk with the Office of the National Coordinator for
Health Information Technology.

DR. GREENBERG: Marjorie Greenberg from the National Center for Health
Statistics, CDC, and Executive Secretary to the committee.

DR. WARREN: Judy Warren, University of Kansas School of Nursing, member of
the committee and no conflicts.

DR. HUFF: Stan Huff with Intermountain Health Care and University of Utah
in Salt Lake City. I am a member of HL7, actually a committee chair. I don’t
know that any business will come up relative to that, but I will disclose that
at this time.

MR. KELLY: I am Brian Kelly. I am one of the speakers today from Accenture.
I am obviously an employee of Accenture and therefore will disclose that as a
potential conflict.

DR. OVERHAGE: My name is Marc Overhage. I am representing the Connecting
for Health CSC Consortium as a speaker this morning, and am employed by Indiana
University and the Regenstief Institute and the Indian Health Information
Exchange.

DR. ROTHSTEIN: Mark Rothstein, University of Louisville School of Medicine,
member of the committee, no conflicts.

DR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention,
staff to the ad hoc work group and liaison to the full committee.

MR. BLAIR: Jeff Blair, Director of Health Informatics, Loveless Clinic
Foundation, member of the committee. I am not aware of any conflicts.

MS. AMATAYAKUL: Margaret Amatayakul, contractor for NCVHS.

DR. HOUSTON: John Houston, member of the committee, University of
Pittsburgh Medical Center. I have no conflicts.

DR. DEERING: Mary Jo Deering, National Cancer Institute, lead staff for the
ad hoc work group and lead staff for the work group on the NHII.

(Whereupon, the remainder of the introductions were performed.)

DR. COHN: I want to welcome everyone to this warm Washington summer.

I want to begin by especially acknowledging Jeff Blair and Harry Reynolds,
our co-chairs, for their leadership in terms of putting these sets of hearings
together. I want to thank you. Obviously we will be talking more as we go on
today. I also want to acknowledge Mary Jo Deering.

I should comment that having heard at least one cell phone go off during
our introductions, we would ask that everyone mute their cell phones if you
could, with the exception of Mary Jo Deering. Since she is expecting her first
grandchild any moment, I think she has the opportunity to leave her cell phone
on and then go darting out at any moment.

I also want to acknowledge and thank our other staff coming from other
committees and subcommittees of the NCVHS, especially from Standards and
Security, as well as the National Health Information Infrastructure work groups
who have come together to work on this particular ad hoc work group. And
occupational we are pleased to have Margaret Amatayakul as consultant for this
effort. I also want to thank the many testifiers who are going to be coming
today and tomorrow for coming on relatively short notice on what I think is an
important set of issues.

I think as you all know, the activities of this work group began at the
culmination of the very successful first Nationwide National Health Information
Network forum sponsored by the Office of the National Coordinator and supported
by NCVHS in late June. They continue with hearings today and tomorrow.

The NCVHS has been asked by the Office of the National Coordinator to
review and synthesize the results of that June meeting, and by the end of
September to find a minimal but inclusive set of functional requirements needed
for the initial definition of an NHIN and its possible architectural forums.

This work of course builds on the contributions of key health information
stakeholder groups, first the NHIN Architecture Prototype Consortium which we
will hear from this morning, but also HITSP, CCHIT, and of course the input of
the many stakeholders who attended the June forum.

I want to emphasize both to the members of the committee and the work group
as well as those in attendance that our rule today and for this activity is not
to make architecture or policy decisions, but it is to clearly designate common
requirements as well as requirements that are specific to the particular
prototype architectures. So everyone needs to keep that in mind.

Before moving to the agenda, let me also talk for a moment about next
steps. We have hearings for two days today. I want to make sure that everyone
realizes that there are opportunities for additional written comment up until
close of business on July 31st. That applies to our speakers today, those in
attendance at our meetings, as well as those listening in on the Internet or
are completely unable to attend. So we certainly welcome any written input that
you may have that amplifies or further defines what we are talking about over
the next day, day and a half. But we will need it by July 31.

What we would like to do, and we will decide more about this tomorrow after
we have gone through the initial hearings, we would like to be able to create a
draft and get it out to people for some initial comment in August. I don’t
think we can commit to that at this point, but certainly we would like to make
sure we have all of your e-mail addresses, and those listening in on the
Internet that may want to look at a draft document, please e-mail Mary Jo
Deering, so that she has knowledge of this stuff. We would like to be able to
send out a draft document for early preview and comment in the early to
mid-August time frame.

We are planning an open web call on August 31, from 11 a.m. to 3 p.m.
Eastern time, for discussion of what we hope will be at that point a final
draft of the report. We anticipate circulating that draft in advance for
comment and input. This is not meant to be a closed process, and we do invite
wide input into this initial draft of functional requirements. The final draft
will be discussed at the full NCVHS meeting on September 13 and 14, which will
be in Washington, D.C., and again broadcast over the Internet, which will
hopefully culminate this activity.

With that, let’s turn to today’s agenda. This morning we begin with a
review by Harry Reynolds of the NHIN draft discussion template that we have
been working on within NCVHS. Then we will move into testimony. We will be
asking each presenter to limit your remarks to 15 minutes. We know some of your
written testimony is longer than that, but we can review that at our leisure.
The reason is not to try to tightly conscribe you, but more that we have a
chance to talk to you about the issues and see where the consensus lies on all
of this. We have not had an opportunity for that sort of a frank conversation,
so we want to make sure that there is that time this morning, and as we move
into the afternoon similarly, for those sorts of conversations.

This afternoon we will hear perspectives from regional health information
organizations, and we will also hear testimony from a large provider
organization followed by a large payor managed care organization for further
input into these initial functional requirements, and we will continue with
hearings tomorrow.

We anticipate adjourning today by 5:30, if not a couple of minutes before,
though as you know, I have a reputation for doing things on time, but very
rarely early. Tomorrow we will reconvene at 9 a.m.

With that let’s turn to the first agenda item, which is a review of the
NHIN draft discussion template. Harry, I want to thank you for being willing to
lead that conversation.

Agenda Item: Presentation of NCVHS Draft NHIN
Discussion Template

MR. REYNOLDS: Thank you, Simon. The reason we put this document together
is, those of you who are going to present and those of you in the audience,
there are many ways to draw pictures. Our toughest thing is to have something
to continue to point back to that allows the discussion to stay centered on
what our responsibility is. That is, as the first couple of questions you ask,
what are the minimum but essential network functional requirements. If you look
in the middle box up there, that is where we are talking, the network
functional requirements. We gave some basic examples.

To reiterate what Simon said earlier, if you notice, very few times do you
see a slide with something marked out. That usually means it is an error. We
want to make it clear, we are not here to talk about the policy in any of this
picture, we are here to talk about the functionality. So we left that up there
purposefully to continue to make that clear.

The other thing that you will notice, a number of times and at about every
angle we could put it, we put confidentiality and security, because obviously
as a committee we have spent a lot of time in the privacy world and others, and
have made points on that. So we want to make sure that we realize that that
goes end to end throughout whatever happens. But we don’t want to stray outside
the internal box.

So that everybody is clear, if you notice when we mention ed systems, we
are not here to talk about the functionality of ed systems or any of that. You
notice the word real is not up there, which is a big word that floats around
right now, because we are not talking about entities and we are not talking
about what they may or may not be or where they may or may not reside or what
they may or may not do. We are talking about the base functionality of this
network.

So as we are listening to testimony, regardless of what you say, we will be
talking about this picture and focusing in on the questions that we have asked,
so we ask you to be prepared to focus there.

So a bit of a mundane picture versus a lot of the architectures you see,
but it really is our focus. We are going to stay with that focus, and we will
ask you to do the same thing as you are going through it.

The other thing is, any of you that have been involved in this, there were
already functional categories that have been established by ONC and reviewed
throughout the many meetings that they have held. So anything that you can do
as you are talking about these functional requirements, put them into the
categories that have already been discussed. Again, it starts to allow
everybody to start building a similar template and a similar discussion point.
Obviously auditing and logging would be something that would go out to ed
systems and everything else as you go later, but right now we are staying in
that internal box that we are trying to deal with.

So these are the same categories that we use, and we are trying to build
off collateral that already exists and not make it a whole new discussion about
a whole new subject, just trying to narrow it down.

So that would be our opening comments. If anybody has anything to add to
that on the committee or anyone else, we would be happy to do that now. If not,
then if you don’t hear any, Simon, then we can continue.

DR. COHN: Jeff, do you have any additional comments ont this?

MR. BLAIR: No, thank you, Simon.

DR. COHN: With that, why don’t we move into our first panel then?

MR. BLAIR: Actually, the only thing I was thinking which I might make a
comment on, it is that in addition to thanking the folks for coming to testify,
some of the documentation that you sent describes who you are. I think by this
time we are pretty much aware of each of the members of the consortium and who
the entities are, so there is really not a need to repeat that. Maybe we could
go directly, as Harry was pointing out, to the main subject at hand, which is
the functional requirements.

Thank you, Simon.

DR. COHN: As I said, our first panel is with the NHIN contractors and
consortia. Our first presenter will be Brian Kelly, followed by Marc Overhage,
Casey Webster and then Robert Cothren. We are going to have presentations, and
then we are going to take a break and have all of the presenters up at the
table together, observe a conversation around where the consensus lies in all
of this.

So I am aware that we have half the presenters at the table now, half the
presenters behind. We apologize for the awkwardness of this. We will figure
this one out. For those listening in on the Internet, this is a relatively
tight room, but we will make do.

So anyway, with that, Brian Kelly, do you want to begin, from Accenture?

Agenda Item: Panel I: NHIN
Contractor/Consortia.

MR. KELLY: Thank you. First of all, thank you very much, Dr. Cohn, for the
opportunity to present to the committee today. We are very excited to be here.

As I go through my 15 minutes, and I will keep to that time line, I just
want to reflect initially that as I thought through how to present this, this
has actually been one the more challenging talks to put together that I have
had, because to try to express a lot of the concepts that will go into this
discussion in a clear and articulate manner in 15 minutes I think will be a
challenge. What I have tried to do is to basically use the questions, use the
frameworks that you have had, and give a couple of examples of how this would
work, to illustrate how this might work.

From our perspective, the NHIN must be a multi-purpose information
infrastructure capable of supporting a wide variety of needs and end users,
including patient care, both remote and distant, personal empowerment, public
health needs, clinical research, drug and medical device safety and other
capabilities. The NHIN must support some key components of functionality.

So in answer to your question one, what are the minimal but essential
network functions, we think first, the NHIN must allow all pieces of electronic
information about the health of the patient to be designated as belonging to
that unique patient.

In order to do this, the NHIN and all systems that connect to the NHIN must
be able to identify that a record or document is associated with the unique
patient. This will allow the systems to request information about a patient
from one another, and insure that all systems are referring to the same
individual.

In order to conduct the paper based analysis required for public health and
clinical research, it will also be necessary to study complete longitudinal
health information across a large sample of patients. For these aggregated data
uses, it is not important to know who the patient is, but rather than all
unique pieces of health information have been identified as belonging to unique
patients to make up the complete health record for that patient.

Therefore, robust enterprise master patient identification must be a key
component of the NHIN.

Second, the NHIN must contain robust record locator service functionality
that can locate all pieces of health information about a given patient from all
data sources that connect to the NHIN.

Many types of data sources and systems will exist containing a variety of
data about each unique patient. Upon request, the NHIN must be able to pull all
these pieces of information together to complete this longitudinal electronic
record for a given patient.

Record locator services can be of varying degrees of sophistication. In a
simple form, they consist of essentially a directory that catalogs which
locations, either at the RHIO or source system level, where patient data
exists. In more complex implementations, they can contain the business logic
for determining what data is returned with a query for information.

Much of this business logic that resides in the core NHIN as opposed to
edge systems will need to be determined, and will be determined over time. Most
likely, much of this business logic will reside in edge systems.

Third, the NHIN must supply the infrastructure to support the exchange of
all types of electronic health information, both between core and edge systems.
This infrastructure must include the identification and implementation of
messaging, document exchange and terminology standards to support health
information exchange. These standards must initially support the exchange of
health documents between edge systems using standard header information.

In order however to realize the true benefit of health information exchange
for the NHIN and support public health and drug safety surveillance and paper
based analytics, many types of data exchange via the NHIN must be in a
structured, standardized, normalized format that supports complex data
analytics.

The NHIN must define the message and terminology standards it will accept,
which should then drive the adoption of standards by edge systems wishing to
connect to the NHIN to exchange and retrieve information.

Next, the NHIN must support the ability to anonymize and de-anonymize data
to support paper based analytics. Finally, the NHIN must support and insure
data security and privacy by thoroughly controlling access to health
information.

In order for patients to support and consent to the use of their data for a
variety of NHIN functions, they must trust that their data is secure when
exchanged between edge systems, that it will only be accessible to authorized
individuals, and it will be used appropriately for the delivery of care and
secondary uses that are in the interest of improved health care quality, cost
and safety in a manner consistent with the patient’s wishes.

The NHIN design must accommodate where and how a patient’s consent to share
his or her data is acquired, recorded, managed and implemented. While often
technical components for the management of the patient’s consent will reside in
edge systems, the overall NHIN architecture must provide guidelines for these
functions and how the edge and core system will interact to handle this
critical function.

In answer to the question, what are the specific edge system or entity
functions that will be minimal or essential for linking to the network,
essentially what will be so important will be the setting of guidelines,
policies and protocols for authentication, authorization, credentialing, data
access and many of the other critical functions that were entailed in the
initial slides presented.

Additionally, edge systems must have well defined processes, policies and
enabling technologies to anonymize and re-identify patient health information
for various audiences, based upon agreed-upon security and access rights. Many
aspects of clinical research and paper based analytics do not require knowing
who a patient is, but rather require visibility to the longitudinal health
record of a large number of patients. The technology must be in place to
support anonymization and aggregation of patient data, and relinking to
identify patient information upon request by authorized entities.

Next, in order to fully support many clinical research uses, edge systems
must be able to thematically normalize health information through accepted
messaging and terminology standards before transmitting these messages and
documents to the NHIN. Edge systems must be able to translate terms and local
standards into the format the terminology accepted by the NHIN for information
exchange. Health information that is standardized is critical to the ability to
deliver these complex data analytics which will be important going forward.

Finally, processes and protocols for how edge systems and core systems
interact, particularly around record locator services and data access services,
will need to be defined.

There has been a lot of discussion in the past around core versus edge. A
couple of general comments, and then what I would like to do is just give two
examples about, as we think about this functionality, where we see it
potentially residing.

When it comes to talking about core versus edge functions, I think it is
very important to recognize that we live in a world of shades of gray, and that
many of these capabilities will need to reside in both core and edge systems.

The NHIN core must define the processes and standards by which edge systems
interact with the NHIN to use its functions. Patient identification services,
record locator services, data exchange capabilities, national aggregation in
anonymized data will largely be driven out of the core functions.

Much of the business logic for many, and I might say most, services will
reside in edge systems, but the standards, processes and policies for how this
all will work together will be defined by the core functions and their
interface with the edge systems.

What I would like to do now is basically take your two slides and talk
about how they might in a hypothetical case basically be used for two examples.
One is, if I was a provider of I was a patient in an emergency room and I
needed to access data from a distant emergency room or a distant RHIO or data
source, how would I do that?

As you look through the core functions, where would these core functions
lie? First of all, from an audit and logging perspective, for me to be in this
remote ER and want to access data from where the patient lives, I would
obviously want to audit both the local request from that emergency room, which
would be an edge function, the audit log would have to then audit how the core
system reaches out to gain that data, and it would also have to audit on the
other side the retrieval of that data from its various edge system data
sources. So audit and logging would exist in both.

Authentication. While authentication would be primarily a function of the
edge system because that is the system the user would be using, national rules
on how we accept tokens and exchange tokens have to reside at both core and
edge systems.

From an authorization perspective, the business logic for who can request
what data on what patient under what circumstances, we think will mostly reside
in edge systems, but there will have to be common business rules that would
have to be shared among all edge systems, and would also have to be duplicated
in the core.

Confidentiality has to be ubiquitous. Credentialing would predominantly be
an edge system function, however there would have to be national guidance and
standards on how do you appropriately credential various users of the system.

Data access and uptake obviously would again be both core and edge. Data
content is primarily an edge system in the world where most data is stored at
the edge level. We recognize that a core set of data may need to be stored at
the national level to allow patient identification, but in our world, the more
we can federate the storage of data, the more we think that the system will be
accepted by users.

Data content and filtering will be primarily edge systems, however again,
we would look to the government and the NHIN to provide guidance on what that
data content should be.

Data mapping and translation would be primarily edge systems, but that
would allow us to get the data in terms that it is consumable and exchangeable
and standardized for exchange across different systems.

Data rendering is both a core and edge system, as would be data retrieval.

We do look at data routing would be primarily done by the core, but
obviously getting the information to the core for its routing between the NHIN
would be something that the edge systems would have to be able to accomplish.

Source data for the majority of data uses would be in the edge, and data
transmission, both from a push and pull perspective would involve both
components. Data would typically be consumed in this use case, where the
patient is accessing data from a distant emergency room, by the edge system.
Identity and information correlation has to be both edge and core systems, and
the ability to persist and store data would be predominantly done in the edge.
Record location will need to be recorded in both edge and core systems, with a
master index at minimum of what edge systems contain data on patients be
manifested at the core.

The second example would be one where a clinical researcher or a public
health official would be preforming paper based research. Rather than go
through all of the features that are the same, most of them are. The only
difference here is that data, although it would be anonymized data, would
likely be stored at the core system level. So if you were thinking about doing
national data aggregation for biosurveillance or a postmarketing surveillance
of drugs, or for some other public health effort, you may want to aggregate
that data in a more centralized way. But essentially, the other components, how
you authorize, how you get data, how you exchange data, how you insure security
and privacy, are similar.

I wanted to just end with, basically as we have thought through it, we
think that there are key core system functions that will be core components.
They have to do mostly with record locations, the identification of patients,
the exchange format, and the setting of interface specs for how edge systems
will interface, both from who can allow data exchange as well as under what
format should that data be exchanged, that will be critical components to
making the NHIN successful.

I would like to conclude my comments there, and I am looking forward to the
discussion later. Thank you.

DR. COHN: Brian, thank you very much. Our next presenter is Marc Overhage.
Thank you for joining us, and once again, thank you for ending in 15 minutes.

DR. OVERHAGE: I too want to thank the committee and listeners for the
opportunity to be here representing the Connecting for Health Consortium. I
like Dr. Kelly was challenged, trying to think through how to organize
something that would be useful for you to hear, as opposed to digging through
line listings of hundreds of detailed requirements, which is really what this
is all about at the end. I was tempted to pull out my Aristotle and the
Spheres, but decided not to do that, but to go to an equally sage source, the
Markel Foundation’s Connecting for Health documents.

Connecting for Health has identified a series of technical principles that
have guided the work. I want to briefly review those, because they have been
central in how we have thought about what things belong in the network and what
things belong in the edge systems.

At the top of the second page of my printed testimony is a list of those,
and I am just going to touch on each of those to explain what we mean by them,
and then I will reference them as I talk about how we have incorporated that
into our thinking about how the functional requirements fit into the model that
was laid out earlier.

First is making it thin. We think that the national network portion as
distinct from the edge portion, should be as thin as possible. There are a
number of reasons for that, including our desire to limit how much new content,
how much new system, how much new knowledge has to be created in order to move
forward. But also, to keep as much of the functionality at the edge as
possible, in part because is where it resides today, and in part because that
is where the opportunities for innovation are easiest, and if you create two
heavyweight pieces in the middle, we have concerns that that may limit the
capabilities that you have at the end. Think about the Internet and the
simplicity of IP as a transport mechanism and all the wonderful things you can
do with it, because we didn’t try to make it everything for everybody, but
rather a thin foundation on which you can build other things.

The second is to avoid rip and replace. This really refers to the edge
systems rip and replace. The basis for that principle was, number one, we tried
to look at building the Health Information Network in a specific time frame and
not in infinity. If we really practically wanted to have something built in a
fixed time frame, and you can argue over whether that is two years, five years
or whatever, you can’t replace all of the edge systems even in a particular
market very realistically, given the investment people have made not just in
the systems, but in the training and implementation. Also, there is a lot of
value there. As Carol Diamond often says, we can’t shut down the health care
system on Friday and reopen it on Saturday with all new systems. We have to
keep it running.

The third is a strong bias for separating the applications from the
network, for the reasons that I have already described.

Fourth is decentralization. This is really in federation, and I will talk
about those two together. The real driver for that is rooted in the believe
that these edge systems that exist and the business processes that exist today
need to be leveraged if we want to make rapid progress. So that seems to be the
easiest way, in addition to supporting the needs for patient privacy and
confidentiality.

The flexibility is more or less an obvious one. You want to craft any
architecture in a way that allows adaptation to unanticipated, unplanned uses.
In fact, I think many of us in software development finds the most joy when
somebody finds a use for something we built that we never anticipated.

I think that one of our goals in building the National Health Information
Network has to be not to constrain it in a way that people can’t be inventive
and flexible. I think that will be reflected — we look through different use
cases, the ability to have a fairly thin set of functions in the network that
accommodate a large number of use cases is really the test of that flexibility.

Privacy and security and accuracy probably don’t need any additional
comment.

As we developed our functional requirements for the Nationwide Health
Information Network, our make it thin and decentralization principles led us to
minimize the number of requirements placed on the network. At the same time we
had to balance the requirement not to rip and replace which dictated that
applications that are running at the edge to support health care today be
incorporated into the National Health Information Network.

We had — and the exact numbers are not important here, but I think it is
helpful for the group, as we try to look at these long listings of detailed
functional requirements — we had approximately 150 functional requirements
that we assigned to the edge systems, and only 50 to the network.

If you look on the first graph labeled Figure 1 on the bottom of page two,
several of those 50 are in the operational mode, robustness, scalability,
business rules and so on. When you look at the actual technical requirements,
the things that you have to build widgets to do, they are very modest, one or
two requirements in each of the categories that the committee has chosen to
organize the content around. So things like confidentiality have two, and
persistent data storage only one in the center, in the network functions.

DR. COHN: I have a question for you. What is the difference between the bar
colors?

DR. OVERHAGE: The hashed bars were intended to represent those functional
requirements which are operational in character. They were things that were not
on the list that was presented earlier by Mr. Reynolds, and were things that
aren’t something you would build, but attributes of the thing you would build.
The point there was just that many of those functional requirements are in
those categories of, you have got to make sure it doesn’t die in the middle of
the night, which is very different than, it has to be able to transmit a
message in a certain format and parse it within 8.2 milliseconds and those
sorts of things.

We have obviously chosen to impose more requirements in this model on the
edge systems, but these are often quite basic. There is an example in the
middle in the third page. You have to be able to accept queries and respond to
queries. So when you start counting these up and say 150 requirements on the
edge systems, many of those are — I don’t want to say trivial, because you
have to deal with them, but on the other hand they are not extremely
sophisticated things to implement.

So while we advocate this clear and strong separation between the edge
application, you can’t ignore those, because they do — as Dr. Kelly described,
they reach into each other in various ways, so you can’t think of them
completely separately, because your decisions about the functional requirements
that you put in the network are dependent very much on what functional
requirements you place on the edge.

So while you like to draw a strong separation, they interact in very
specific ways, so you have to look very specifically at which functionalities
go where. So I think we may be thinking at least of an even stronger cleavage
than was just described in the last group, in the sense that not being as gray
perhaps in our initial thinking, you always learn to be more gray as you get
into reality and get older, that you avoid making too strong a classification.

So we believe that many if not all of those requirements that we placed on
the edge system can be met using existing systems. Our basis for that is that
the same team as part of building the connecting for health prototype has
accomplished that in three different markets. In other words, taking the
existing operational edge systems and asking the question, can we meet the kind
of functional requirements that we have imposed on edge systems using those.

The answer is largely yes, accomplished in different ways. For example, in
Massachusetts they have incorporated a model of a gateway server, tightly bound
if you will to the edge applications, living inside a care delivery
organization’s firewall, perhaps, they can implement the necessary
functionality.

In California, these functions were provided by more centrally managed
resources. This is another subtlety in some ways, but some functions — there
is a very challenging thought process about, is a function part of the network,
or is it simply yet another edge system that provides the function.

Let’s use the example of anonymization specifically. You might think of
that as being a function very naturally that would occur in the network, but
you can certainly imagine a scenario where a care delivery organization who is
going to deliver data to public health could choose to utilize an anonymization
service which they have built, which public health provides, which a commercial
vendor provides, which their professional society provides or whatever, that as
long as it conforms to the functional requirements of the network would be very
easy to do.

So certain of these functions can be moved conceptually between the edge
and the network based on not so much technical requirements as personal choice
or care delivery organization choice, anyway.

These different approaches are possible because the existing edge
applications implement standards based functions through messaging or
application programming interfaces that expose the necessary functionality. In
other words, if you buy an off-the-shelf product today, while it doesn’t
implement the kinds of interfaces and the kinds of functionality that I think
most of us would imagine an edge system has to implement in order to
participate fully in the Nationwide Health Information Network, they do expose
the functions that seem necessary in order to connect them through an adaptor
in order to do that.

In Indiana, for example, we rely heavily on existing edge applications, the
ability to produce and consumer HL7 version 2.X messages. They are not perfect,
they are not consistent, they are not uniform, but they give the application,
the service or the gateway, whatever you want to think about, the ability to
accomplish the work it needs to accomplish with that edge application in order
for it to participate in a broader network and exchange.

Another point about this long list of edge functional requirements is that
most of those requirements already exist for edge systems. Things like user
authentication, you kind of have to do that today already. So that is not a new
requirement.

While I didn’t put it on here, if you look at the individual requirements
there is actually a fairly thin list of new requirements for edge systems,
because most of the kind of things they need to do they already have to do as
operational clinical systems.

This approach really gets back to and reinforces that principle of the need
to avoid the rip and replace of existing edge applications at the expense of a
modest amount of work to create gateway or centrally managed services that
allow those existing edge applications to participate in a Nationwide Health
Information Network. We are also pleased that this approach seems to
accommodate innovation at the edges.

The functional requirements for the network are by design quite modest at a
nationwide level, the ability to authenticate and authorize what we call
sub-network organizations, so that they can be accessed to have functions
provided through what we call the inter-SNO bridge or ISB, requires only a very
few functions, and even these functions are similar to those that the edge
applications have to implement, allowing the work that is done to adapt edge
applications to be reused and leveraged for that same purpose.

In fact, in the prototype work that we have done to date, it is literally
the same code base that is used to implement those functions, so it is not even
truly unique. At this sub-network organization or SNO level, a record locator
service or RLS also imposes a limited number of functional requirements. We
believe that this make it thin approach will facilitate creation and deployment
of those relatively few functions required at the Nationwide Health Information
Network and SNO levels, allowing the edge applications to be added to the
environment as possible. In other words, a fairly thin set of structures, a
fairly small number of functionalities that have to be deployed at a regional
or national level and the edge applications can join in as they are able to,
and don’t have to all be converted day one or something like that to move
forward.

Incorporating these edge applications requires implementing a number of new
functions, btu we believe building on the existing edge applications through
gateway or edge proxy approaches allow the current investment in edge systems,
which already implement most of the necessary functions to be leveraged,
avoiding the disruption in costs of rip and replace.

I appreciate this opportunity to share our comments.

I almost forgot one other thing I wanted to add. We were asked to comment
on the standards list that HITSP had been developing. I like many of you find
it daunting to wade through all those, and I may have missed something, but one
of those pieces that I have not found, and I would love to be informed, is
addressing units, which is an ongoing challenge.

PARTICIPANT: It is.

DR. OVERHAGE: It is? I knew it must be. But that was the only way that
stood out for me.

Thank you very much for the opportunity, and I look forward to the
discussion after the break.

DR. STEINDEL: Marc, may I ask a clarifying question on the graph while we
are making a change? Should we pay any attention to the number of requirements,
or just the fact that it exists?

DR. OVERHAGE: Thank you, I meant to comment on that. The exact numbers are
not so important. The relative quantities was the point I was trying to make,
that many of these are one or two in the network level and at the edge level a
few more. It is not the exact numbers that are important, but just the relative
scale that I think should be the takeaway from those particular figures.

DR. STEINDEL: Thank you.

DR. OVERHAGE: Thank you, Steve.

DR. COHN: Thank you. We will switch speakers now. Our next presenter is
Casey Webster from IBM. Thank you for joining us.

MR. WEBSTER: Thank you for having me. Good morning, everybody. I want to
echo something that Marc and Brian said. This is a different kind of
presentation for us. We have been doing a lot of these presentations together.
I am always surrounded by a couple of MDs and a Ph.D. I am an architect.

My viewpoint tends to be a little bit different, but in general in these
presentations we talk about the status of where our architectures are, how they
fit in the community, and this one came out as a different kind of question. It
set the question back to what should the NHIN be. There were some basic areas
that the e-mails Mary Jo sent out asked us to address. They really caused us
all to go back and think about some things that we hadn’t thought about.

My first question to myself in framing these is, what is the intent of the
NHIN. That should be an easy question nine months into developing an
architecture, but for those who were at the National Institutes of Health forum
last month, that is far from an easy question. There were some 580 people
there, and I’m sure there were some 580 versions of what the NHIN should
become. All of them are valid viewpoints. The question is, in the initial NHIN,
what do we think makes sense to try to drive to, what are the core
functionalities within the framework that make sense early on to reach an
effective and achievable NHIN without running so fast that we get too many
things wrong early on.

I know that we were asked to avoid policy discussion, and for the most part
I have, but it is absolutely impossible to separate policy out from some of the
functionality we will have to implement. It is easy to say you need to cover
role based authentication and authorization, but it is difficult to define what
those rules are without the policies to support them. It is easy to say you
need to support patient consent, everybody demands that, but what are the rules
around patient consent? What are the policies to enforce them? As an architect
it is difficult for me to design an architecture that supports that without the
policies being defined. I have been around this domain 20 years, and those
questions have been around a lot longer than that, and they are still coming
out.

The IBM viewpoint of what the NHIN niche should be is to promote the secure
sharing of electronically available patient clinical and demographic data to
authorize users throughout the United States. There are a lot of key words in
there. All of the use cases that we are currently working on can be supported
by this, the key being electronically available, sharing, clinical and
demographic data, and authorization of who can use it.

I don’t specify what an authorized user is in this statement. One of the
things that I will leave you with at the end is that question, who are the
authorized users of the NHIN. That will drive some of the features.

Implicit functional requirement. Clearly, patient identification matching
and lookup are core to the NHIN. If we are going to share data and create an
ubiquitous electronic health record or use it for other areas, bioinformatics,
research, biosurveillance, we have to be able to identify people to events. We
have to be able to do that as people migrate. We have to support the fact that
people do move throughout their lifetime, that they have multiple homes, and
that they may be skiing in Vail when they break their leg. We still need to be
able to get the record back from Maryland.

Document submission, location and retrieval. Now that I know who somebody
is, I have to be able to pull that data out. That doesn’t specify where the
data are stored or how it is stored, but the NHIN infrastructure has to support
that mechanism.

Implicit non-functional requirements. Some of these are more non-functional
than functional. Data storage. That doesn’t necessarily mean that the clinical
documents have to be stored within the NHIN. In all of the proposed
architecture there is at least some data at some point being stored, and it is
sensitive data, demographic data at the very least, which is still high patient
sensitivity, still has to be protected.

The transmission on capabilities to meet and exceed the HIPAA, the NIST,
and all of the other related state and federal requirements. Again, we have
been asked to avoid policy, but policy drives what those requirements are.

Authentication, role based authorization and patient consent, three very,
very difficult areas to achieve, but without those we are not going to have a
usable NHIN. It must be Internet based with a low barrier to entry. That wasn’t
actually covered as one of the functional requirements in your box, but that
drives a lot of the things we have to do around it. The Internet imposes some
restrictions. It also exposes a lot of advantages. We have to use the
advantages, we have to mitigate the disadvantages, and take care of the issues
that it creates.

Performance, dependability and scalability are critical to adoption. If a
doctor can’t depend on getting the data within a short time of needing it, it
is not going to get used. At that point it stops being functional as an
electronic health record.

So given that, the initial NHIN functionality, IBM’s viewpoint is that the
initial NHIN should focus on access to patient demographics, active
medications, allergies, immunizations, recent lab results, and recent or
chronic diagnoses and treatments. That is your basic paysheet for practice. I
am not a physician, but these are the areas that continually come up to say, if
I had these data items and nothing more, I would be far ahead of where I am
today in most practices, particularly the small practices that don’t have that.
If I can get that ubiquitously on any patient, I can treat them more
effectively, in an emergency room, on a walk-in basis or as a scheduled visit.

The nationwide access to these data elements gives the most immediate bang
for the buck. There is no technological issues in acquiring the data; the real
issues are getting the data from electronically available sources and creating
more and more of these electronically available sources.

For phase one of the NHIN prototype, we started with lab data, which is
pretty ubiquitously available in electronic format. But that is not true of
other types of data. Certainly allergies are rarely available electronically
outside of larger hospitals or larger clinics.

Active medications. Now with the recent Medicare changes and CPEP spread,
we are starting to see more of that, but that is still the exception rather
than the rule. So driving the NHIN to drive access to these data alone is a
significant challenge, and one that would achieve the most.

Standards already exist today. I’ll mention the most obvious ones, HL7,
clinical data architecture, CDA, the HL7 2.x-3.x, DICOMM, LOINC. They are out
there, but they are not being mandated.

IBM views the selection and promotion of standards as a key to the success
of the system. In many cases, particularly HL7 and DICOMM, they are already out
there everywhere; why not take the next step to say compliant systems must
adopt these standards? That will drive the easy integration of the systems into
the NHIN.

Initial focus to be on driving electronic capture of these data elements
and establish the framework and policies for sharing the data across multiple
communities. So it is two steps there, one, get the data, find where the data
is, second, put in a format that is sharable and generally usable, and third
and most critical, find a way to make sure that any valid user wherever they
might be can quickly and easily obtain it.

By adopting these standards as systems, they can easily integrate with the
NHIN without the major conversions or rip and replace that Marc just mentioned,
and bring the data into their own work flow reasonably transparently.

The NHIN should not be in IBM’s viewpoint a work flow driver. It is a work
flow supporter. There is no single work flow that works for everybody. If we
drive to these basic elements in the initial NHIN, that will be sufficient to
provide a basic EHR to support consumer empowerment, to support the
biosurveillance use case we are working on, and even the chronic care use case
is currently out of the NHIN prototype.

The second area that we were asked to talk about is our separation of core
versus edge. There is no clean line. All of the functionality that is out there
at some level is going to be in the core and in the edge. So what I have tried
to do is delineate the things where something is more of a core service or more
of an edge service.

IBM viewpoint, the initial NHIN should not attempt to provide the same type
of work flow and decision support capabilities that a commercial EMR or
clinical system can. It just doesn’t make sense. Focus on a lightweight
connectivity, let the existing systems produce the work flow and the decision
support.

The NHIN shouldn’t hinder these capabilities. The rationale for that is,
even simple decision support, the one that came up most often, drug draw and
drug allergy, still requires a tremendous amount of things that the NHIN can’t
control. To be able to do drug-drug, we need to codify drugs. We need them
electronically available and parsable. We need an ongoing administratively
available database to do these drug-drug interactions, which implies additional
costs. There are commercial engines out there that already do it, that are
ubiquitous; why should the NHIN duplicate that function when it is already out
there and available?

There are no adopted standards for clinical work flow. Different
environments operate differently. Ambulatory inpatients, ER and ED; even within
the same types of practices, a training institute versus a normal community
hospital have very different work flows to account for the residents, to
account for co-signs, things like that. The NHIN can’t drive these, they can’t
support them everywhere, it just shouldn’t hinder those. So let the local work
flows be the local work flows, let the NHIN drive the interconnectivity.

Support capabilities that work well in the closed environment rarely work
well in an open environment with multiple edge system vendors. It is not
unusual, in fact, I found dealing with our approach partners it is generally
the case that even within a single hospital, there are units within that
hospital that aren’t connected with themselves.

A good example is one of the hospitals I was in at in North Carolina last
week. They have three different demographic systems, one for their cancer unit,
one for their normal inpatient, and one for what they called their ambulatory
inpatient. They don’t have any interconnectivity, because they have three
different vendor systems and couldn’t find an easy way to bridge those systems.

They were looking to the NHIN prototype, to what we were doing for them, to
give them that access. It is nice to give them something back. It is better to
get a basic NHIN established and functional quickly, let the users drive the
evolution of the NHIN, spend the time to think about the policies so that when
we do implement the advance functions we understand what it is we are trying to
implement, and at the same time let the standard and policy bodies work out the
other issues. These are not the technical issues, these are the policy issues.

Just a quick breakout chart to simplify the harvesting of how I broke out
the essential and non-essential. I took the list, and on essential I listed
audit logging, authentication, authorization, confidentiality, ADAF, access to
data filtering, data integrity, data source, data retrieval on a pull, identity
and information correlation and record locations. Those basic functions is
enough to support an initial NHIN.

There is a mistake in the printed slides, because I included record
location on the right as well, and that was a last-minute typo. But that
doesn’t mean that those same things aren’t essential everywhere else. Things
that aren’t essential, clearly data quality is something that has got to be
addressed much lower than in the NHIN. Data rendering, that is an edge system
functionality. Data routing, now we get into work flow issues, data
transmission and push, one that we are actually implementing in the prototype,
but it is still not clear that pushing data in a world where people don’t have
a single seat and a single environment, is a good model.

Data usage, persistent data storage. There will be some persistent data
storage at the NHIN itself for demographics. The core of the data storage and
all of the prototypes is out at the clinical systems, Nobody wants to bring a
centralized data repository to the top; and transient data.

Questions to consider in analyzing the testimony that you are hearing.
First and foremost, who will use the NHIN and how. Care providers are given,
but what about patients? There is a lot of desire to have patient access, but
how is that controlled? What does that mean?

CDC and related government agencies, researchers, and if so are they
strictly governmental researchers, or are we going to let private researchers
to access it? And what type of data will they be able to access, in what
format?

Insurance companies, somewhat of a controversial one, but it can surely
come up.

One of the questions that has got to be resolved is, who is going to pay
for the NHIN. It is not a federal model, it is a national model. Given that,
what are the primary people who might benefit from paying for it, is it an
insurance company or an employer. But of course, that has got very, very
sensitive issues on the other side. Quality of care initiatives.

These are tough questions. There is no obvious answer. How will access to
the NHIN be granted and administered at the nationwide level? We know how to do
authentication. That just says you are who you say you are. That does not mean
you have the right or the privilege to view this particular document. Who is
going to make those choices, and how are those going to be administered across
communities? Should clinical data standards, DICOMM, LOINC, SNOMED, NCPDP,
Scrip, should they be adopted as part of the initial NHIN, which will raise the
barrier to entry, and it will certainly enforce a higher starting point, but at
the same time create a more clean data source early on, and save some of the
problems that later on may have to be addressed in retrofitting the data when
the realization hits everyone that if this data were more codified, more
clinically relevant at the electronic level, we could do more things with it.

That concludes my testimony. I did include some reference slides on our
architecture and how it supports this particular model that I won’t be
discussing here. But I do thank you for your time and I look forward to the
questions.

DR. COHN: Casey, thank you very much for a very thoughtful presentation.
Our last presenter of this session is Robert Cothren from Northrup Grumman.
Thank you for joining us.

MR. COTHREN: Thank you. I really appreciate being invited to come here
today. As I was speaking with Dr. Deering out in the hallway, I think one of
the challenges we faced in preparing for testimony here today is getting a
handle on what we believe is an incredibly important issue.

As I was coming here today, I was thinking that I don’t envy you folks in
trying to get your arms around this. But the truth of the matter is, I think I
do. The reason for that is that I think what we are talking about here is not
just going to have impact; what we do is develop architectures, but it is going
to have much more longstanding impact on what the NHIN really is, how things
move forward, impacts how adoption will happen, et cetera. so there is a real
opportunity to set the pace here.

We are now in July. We have been working on this for awhile. I have to
admit that I haven’t yet decided whether having Northrup Grumman begin with an
N and me being in the fourth seat is a blessing or a curse. It is a little bit
of both. Some of the things that you have heard from the other speakers today
you are going to hear from me as well. In particular, all of the speakers have
talked a little bit about the blurred line between core and edge. I think that
we have a tendency to blur that even more, and that things may get even
fuzzier.

So with that as an introduction, I think what I want to do is start off by
setting the context for which we internally at Northrup Grumman and in our
consortium approach requirement, how we approach NHIN, and I will set some of
the context for my comments later on.

First of all is how we think about core and edge systems. I have seen a lot
of definitions of core and edge systems. I am going to postulate a definition
for each of them here, just because it sets the tone for other comments.

In our mind, a core system is a system or service, and it is hard sometimes
to distinguish those two, but it is a system or service whose primary purpose
is national interoperability. That is what it is about. Edge systems, if you
were to simplify things, you would say that is everything else. They may
participate in interoperability, but that is not their core function. That is
really the only distinction that we make between those two. We will talk a
little bit about edge systems.

In particular, when you are looking at what are the essential and minimal
requirements for the core functions, it is important to understand some of the
definitions that you can work from. It is the bringing together the core and
edge systems that then makes up the NHIN, and it is neither one nor the other
by themselves.

Implicit in those definitions are a few things which they are not about.
For instance, they are not necessarily about location. We are not talking about
that core systems need to be nationally hosted, they need not be in a single
facility but still could be distributed among a number of different facilities.
It is not about sponsorship. Core functions aren’t necessarily sponsored by a
government organization, but could be sponsored by any type of organization
provided by a number of different organizations, and we will take a look at an
example of how that might end up happening. It is also not about multiplicity.
When we say core, that doesn’t mean one. It could mean several different
entities, several different systems that provide core functions. So it is all
of those things together.

Most of the discussions that we have focus on core functions. I am going to
focus on core functions today here also, but there is one thing that I think is
important to think about. A corollary for the definitions that I postulated
there is that you could have more than one core system, so some of the
requirements may be about how those core systems interact with each other.
Again, we will talk about a model where that might be necessary as we move
forward.

I think it is also important — I am not going to talk about our
architecture today. That is not what you asked me to talk about. But I think it
is important to set up what we believe our goals in designing that architecture
are. If you understand that, then you will understand where we are coming from
when we start talking about requirements.

We believe that there are two goals here, and that they are in conflict
with each other. The first goal is to develop and perhaps enforce nationwide
standards for nationwide interoperability. One of the reasons for doing that is
that it provides a model that really sustains interoperability over the long
haul. On the other hand, as other panelists have already mentioned, we don’t
want to take a rip and replace approach to this, because that is not
reasonable. So we also want to leverage the huge successes that we have already
seen there, and lower the bar for those initiatives to participate in NHIN.
That really facilitates adoption.

But you can understand how these two things are in conflict with each
other. On one hand, wanting to insist on standards, on the other wanting to
facilitate the adoption by systems that may not conform to those standards
today.

Finally, before we move forward, I did want to talk a little bit about what
we think of as the NHIN. We think of it as the system of systems. It is not a
thing, but it is a collection of a lot of things. Those things include both
edge and core systems. So you can’t really talk about NHIN without at least
considering both edge and core systems, and you can’t just talk about the core.

There are certain requirements for the NHIN that are somewhat of a given.
The NHIN must describe the interaction between core and edge systems. Those
requirements must also describe the interaction between core systems. As I have
said before, you can imagine an architecture that supports more than one core
system, but it cannot be about core or edge systems alone.

If we get down to requirements, this is one of the things that we think is
key and fundamental to our approach to requirements. That is, the full
requirement for core systems is to provide a level of abstraction for
interoperability. It provides a level of abstraction for those services that
requesters of data depend upon in order to achieve interoperability.

There are two reasons for that. First, it simplifies the interaction for
the requesting systems. It is part of that lowering the bar idea and that
lowering the bar goal. However, we do acknowledge that it complicates the
interaction itself. The core systems and the providers of information have a
potentially more complex job to do, but the receivers of information, it
greatly simplifies their participation.

It also provides a path for adoption to national standards, by providing a
method for organizations to participate against an abstracted set of standards
without necessarily having all participants take part in those standards from
day one.

I am going to point out a shortcoming in our thinking. When we talk about
abstracting those services, one of the questions we find ourselves asking is,
does that imply that there must be a canonical information model at the core
level. The truth is that we don’t see a path, at least a simple path, that does
not include a standard canonical information model.

Now, whether that is a requirement, should be levied as a requirement of
core systems, or whether that is a design decision to make in order to
facilitate easy interoperability, is still a question in our minds. Somewhat
related to that, it is also not clear whether standards organizations should
dictate what that canonical model is.

I can say for our prototype, we are adopting a canonical model, and we have
determined for the prototype activities that that is going to be HL7, B3
reference information model. Whether that should be levied as a requirement is
still a question in our own minds.

I think it is a little easier to understand the complexity of separating
core and edge systems if we work through an example. So I am going to do this
very quickly, and then we will get to the requirements. I want to explore an
example based on the consumer empowerment use case that requires us to gather
medication history information and provide it to a PHR. I am only going to talk
about that part of the use case very quickly.

I think that without really getting into what we believe are essential
requirements, we all agree, and you have heard it from the other three
panelists, that we have one thing that we must be able to do, find patient
information. There are two steps to that, identifying the patient and
identifying where that information is and retrieving it. Some folks call that a
record locator service. There are a lot of names that you could possibly give
that function, but I think we all agree that function exists.

I think there are three different ways that that function might be
achieved, and it shows how different those three models are and where the
functionality is and where the requirements might be. One we can imagine is
using a single provider at a nationwide level of medication history
information. RxHub is an example of an entity that might be able to do it.
RxHub has medication history information on approximately 180,000 million
people across the U.S. It maintains a very robust master patient index on those
patients and a repository of that information. Does it make sense for a core
function of NHIN to reproduce the master patient index or the repository, or a
source of information like that? I don’t think it does.

So what that means is that for a PHR asking for medication history, the
core functionality is to abstract what RxHub provides, but not provide the
patient lookup or the data itself. If we move forward, probably something that
makes a little bit more sense intuitively to folks, you can imagine that that
medication history might come from an EMR or a collection of mini-EMRs. In that
case, locating the patient might be easier for the NHIN to do at a core level.
However, keeping the data itself is something that you would want to retain at
the EMR.

In that case, the requirement is still, look up a patient and provide data,
but the lookup is a core function, and the provide data is an EMR or edge
function.

We have examples of this in our prototype as well. One example that we
don’t have in our prototype, but you can also imagine, is physicians that have
no EMR capabilities at all, but still prescribe medications. There might be
some facility for them providing that list of medications to some source of
information. You can imagine that an NHIN core function might be to not only
maintain the patients and a method for looking up those patients, but the data
itself.

So what we have looked at is looking at two separate extremes, where NHIN
facilitates patient lookup and data exchange, to NHIN maintains patient lookup
and maintains the data itself. You can imagine a full spectrum in between.

So when I talk about that it is blurring the lines there, the idea of
abstracting these services and that being fundamental to what NHIN does, it
blurs the line of where those functional responsibilities are, whether they
reside as a core function or an edge function.

Let’s finally get to the requirements, because that is what I am here to
talk about. If I look at what are the minimal and essential requirements of an
NHIN, I think this is the short list. This is the very high level. What I
didn’t want to do is come in here and rattle off to you folks the 200 and
some-odd requirements that we submitted to ONC. You have that in front of you.
These are what we believe are the high level essential requirements. Note that
I didn’t say that these are the core requirements; these are the requirements
of NHIN. It is that blurring between core and edge that makes it difficult to
necessarily say where these are.

Key requirements are translation for both message and structure
terminology. We believe that is a requirement to facilitate adoption. An
information model; we already talked a little bit about whether that is a
requirement or not. It is on our list for now because we don’t see a reasonable
path without adopting an information model.

Patient identification and location of that data. That is what we talked
about in our example. Message routing, facilitate the movement of information,
whether it be something that is solicited or unsolicited, such as
biosurveillance information, auditing to maintain a record of what information
is accessed by who, and confidentiality, which is a lot of different services
that we roll up into that, that includes authentication, authorization and
confidentiality, access protection of consumers. Those are the functions that
need to be there.

The edge participants in NHIN. I would agree with the list that you have
postulated. I think that there are a few other edge systems that we might also
want to consider, including portals, registries, et cetera, but in particular
you can also imagine things that you don’t necessarily think of as edge systems
like clinical messaging systems or data consolidators, that might be considered
edge systems if they don’t meet the fundamental requirements of a core, which
is that they can abstract those services to a single model.

Information consolidators, as an example, might be RxHub, who consolidates
information but might provide those services itself, or perhaps even RHIO
technologies. They can’t function at the core level of NHIN on its own, but can
provide patient lookup and/or data on a particular patient.

I feel like we need to get back to this, that the fundamental requirement
of core systems is that level of abstraction against those key requirements.

I left in this picture. This is not meant to be an example of our
architecture, but to illustrate the complexity of the problem we are talking
about. When we talk about abstraction, we are talking about federal court the
PHR asking for medication history, asking that use in an abstracted model of
the NHIN. That information is either looked up in an edge system, looked up in
the core of edge systems, or provided by the core. Data is either provided by
an edge system or provided by the core system. The key is that the receiver of
that information doesn’t need to know the complexity of NHIN. That abstraction
of the service is what provides that simplification of participation.

The last thing that I want to leave you with is the difficulty in going
forward with requirements, at least a difficulty that I perceive. It is very
tempting to look at a particular solution and built requirements around it. I
couldn’t even figure out how to talk to you folks today without an example. I
couldn’t figure out how to do it. In fact, the example looks like our
architecture because I couldn’t figure out how to do that, either.

We have to look at what are the requirements in the absence of an
architecture. We need to make sure that the requirements don’t end up
prescribing an architecture. I am going to give you an example of one place
where it is very easy to do that.

If you pick up the EHR use case, and you read through one of the data flows
in particular, it calls out a data repository and putting information into a
data repository and registering it with a record locator service.

Now, the author of the use case recognized that that could be prescriptive
of an architecture, and that the use case is not meant to be. It is meant to be
illustrative, not prescriptive, and so if taken out of context it sounds like
it calls out an architecture.

What if my architecture doesn’t have a record locator service? Is it
possible to find patient data without a core record locator service? In the
case of RxHub, yes, it is. So we need to make sure that as we move forward with
this and identify requirements, identify standards, et cetera, that we don’t
end up prescribing an architecture, but maintain the flexibility, so that
various architectures can still thrive.

Thank you very much. I really appreciated the chance to talk to you.
Looking at peoples’ faces here, I fear that I may have confused people than
clarified things, but at least we got a start. I really welcome the chance for
questions later on. Thanks.

DR. COHN: I want to thank everyone. This has been very, very useful. Now we
get into the fun part, which is asking you all questions.

We want to give everybody about a 15-minute break. I am hoping that maybe
we can get another table across the top here so everybody can sit together.

(Brief recess.)

Agenda Item: Work Group Q&A with
Contractors

DR. COHN: I want to welcome everyone back to our second session. The
purpose here is an open question and answer conversation, try to understand
similarities and differences of all of your views as we begin to work on this
minimal but essential set of requirements.

I want to start it out. I’m sure everybody will have questions, and we will
open it up in just a second. I want each of you to maybe talk for a minute
about your definition of core versus edge. I am struggling in my own mind,
trying to think — and I haven’t gone through all of this compare and contrast,
and I am trying to figure out, in all of your discussions, how much of the
differences that I am hearing are related to how you are defining the terms,
versus how much real difference there is.

So Robert, you were the most recent. I know you described — can you just
talk about how you perceive it? It feels to me like you are talking about
things differently than some of the others are. Do you want to just start for a
second, and then we’ll go around and ask —

MR. COTHREN: I can certainly start. I’m not sure that we have a very
different picture for what edge and core systems are, because I think in our
discussions, when we talk about what are examples of edge systems, we almost
always agree on what those examples are.

In our mind, the primary difference was all about what the purpose of the
system was. Is the purpose providing a service to a user, is it an application,
in which case it would be an edge system, or is the purpose to facilitate
nationwide interoperability. If it is about facilitating nationwide
interoperability, then that makes it core.

That doesn’t mean that a national provider of information can’t provide
core services, again, RxHub being an example of that. Some of its services
might be core because it has an MPI that has half the country’s population in
it. So it can provide services on a national level for looking up patients. But
really it is about, are the purpose of those services and are the purpose of
those systems really interoperability first and foremost.

MR. KELLY: I think Brim’s explanation captures the theme that most of us
believe. That is, when we are looking at it, we think about our provider
organizations as being edge systems. We think about how we link them together
as being the fundamental components of what is core and what is unique about
NHIN.

So it really is about how do you set up the capabilities. I like to view it
as capabilities, to talk about the capabilities to make those interoperable, to
find the records, to identify the patients, do all the things you have to do to
make those different edge systems, which are basically any system that provides
transactional processing to support health care, to make them all link
together.

So we as a group, we have heard each other talk quite a bit over the last
nine months, we are coming to agree that that is fairly similar.

DR. WEBSTER: I third that. I pretty much agree with that definition. It is
core if it is critical to supporting what the NHIN is supposed to be doing
within the framework that has been defined. If it is outside of that — a good
example of that is rendering. Rendering is outside of the core of the NHIN. We
may provide a simple web interface or something to lower the bar of entry, but
the actual rendering, work flow, distance support, those are not necessarily
part of the NHIN as defined today, so they become edge.

What we really try to say for the initial NHIN these are the key services,
these are the core. That doesn’t mean that five years from now that is going to
change; it certainly will. But I think the boundaries will expand and the gray
area will become larger and larger as functions are brought in.

But as it is today, if we are talking about a fairly simplistic model of
the NHIN, a lightweight early NHIN, then it is fairly straightforward to say
these things tend to be more core or more edge; they support that key
functionality.

DR. OVERHAGE: I’d like to build on those comments, in the sense that one of
those challenges is deciding — Dr. Kelly for example talked about
transactional systems as being — and de-identification is a good example of
something that you could think of as being in the center, in the network,
because it is a fundamental capability that almost everybody needs and almost
nobody has today. So you could think about that. Or you could equally validly
think about it as an application, an edge application, that is an opportunity
for service and support in the public health or commercial vendors or consortia
of providers could support an edge application which was capable of performing
de-identification, and I as a hospital or a physician practice might choose to
take advantage of that application. That is easy and enabled by those
consistent ways of exchanging data and interoperating that are part of the
network itself.

So I think that there are some pieces that you could move to different
places, depending on how you model. Or for example, I talked about the idea of
gateways or edge proxies. Are those part of the network or part of the
application? They may be in the middle, or you could think about them as an
application. That may be part of the fuzziness that you sense in this. There
are certain things that are fungible that you could put in different places and
implement in different ways.

The good thing is, I don’t think that any of the models that you are
hearing about, or the functional requirements that you are hearing about drive
you to have to do that in any one way in any of those.

MR. COTHREN: Can I add just one more point before we move on? I think Casey
brought something to mind. It is tempting, whenever you think about something
that for instance an NHIN provider, whoever that might be ultimately, something
they are doing that makes it core.

I would say that a portal that facilitates access to the NHIN isn’t
necessarily a core, any more than Verizon Yellow Pages are core to phone
service delivery. So just because it is something that is sponsored by the
government, something that is part of an NHIN service provider’s offerings,
does not make it a core NHIN service.

DR. COHN: Harry, I think you had a basic question.

MR. REYNOLDS: I thought all the presentations were outstanding. As I
listened, I am still struggling with, you are thin, and I hear it consistently,
but then I hear it start to move in on some of them.

For example, whether or not thin would be a very basic record locator
service that would have only the most pertinent data. But I heard it mentioned
by some of you that maybe the core has more rich information, some clinical
information.

So if everybody could just quickly comment on, if you really mean thin, and
if thin really means thin, including the data that you would have on that
particular patient in the core requirement. Obviously the functionality changes
dramatically, depending upon how much is in that core versus in that edge.

DR. WEBSTER: That particular example is getting a lot of press time, and we
talk about it again next week.

I don’t know that that really in our minds is what separates thin versus
thick.

MR. REYNOLDS: No, I didn’t mean to say that, but when you say thin, it
denotes certain things to some of us.

DR. WEBSTER: I think what we are talking about in terms of thin is, keep it
simple, stupid. Start small and build on top of that. But then what those basic
functions are in terms of record locator, adding the meta text, such as our
model versus not, that becomes one of an architectural limitation that says
early on, is it valuable — if it is not a technologically good thing to do, is
it valuable to be able to do more robust searches by having that data there,
versus the security issues that it brings by moving meta text data, which
starts to approach clinical data, out of the storage point and up into the
center.

Those are not to my mind — I have got one of those architectures that
supports the meta text, I don’t think those are what determines whether it is a
thick or thin issue. To us, that is a philosophical and usage decision, versus
the idea of bring in something beyond — ultimately that is all record locator.
It is how convenient that record locator service is versus bringing something
totally different that says, not only do we want record locator, but we want to
go back to work flow.

So it is how many functions we bring in, and not how robust those
individual functions are. I think we all believe within the area of the
individual functions, they should be as robust as possible without sacrificing
security or some of the other issues.

MR. KELLY: I think one of the speakers brought up, think of this as the
Internet, keeping it simple. I think that is really a good analogy to come back
to here.

You can make the NHIN as thick or thin as you would like for different
applications or for different functions. In my opinion that is going to happen
as we move forward. However, health care is a very local phenomenon. The
different things we do in health care drive very different work flows depending
on where you are, what you do, what part of the health care value chain you
are. If we don’t keep the way you connect and exchange data as simple as
possible, we will limit that flexibility and ability to move forward.

I think the real challenge is going to be to say how can we keep the NHIN
basically as simple as possible, and how do we define the interfaces so you can
get on and off the NHIN, as simple and straightforward as possible. Again, we
are going to move some functions, we are going to over time evolve more and
more on the core. That is okay, if that is the simplest way, and those are
standard functions that can be used over and over again.

All of our companies are moving to service oriented architecture approaches
and beginning to think about how do you build out these type of architectures.
If you think about it in the sense that it is a service that could be anywhere,
then it becomes a much easier and more acceptable model to think through. So
don’t worry about where the service sits right now. Let’s just get respect for
how we all share that service and get on and off. I think if we think about our
approach in that way, it will make things a lot more straightforward.

MR. COTHREN: I don’t really have much more to add to what has been said,
other than, one of the things that we are touching on here, simplicity and
whether it is a thin model, gets back to minimal and essential. I think all of
these things potentially thicken up and become more complex as soon as we move
off of minimal and essential. I think that is one of the challenges to keep
there, because it becomes simple and thin when that happens.

DR. HUFF: A couple of things that came to mind in listening to that. I
don’t know if these are just details that are covered under one of your
headings, or if they are actually a different thing.

In trying to do these things within our own institution, some of the things
we didn’t think about to start with were in fact capabilities of the service
relative to performance and to debugging. In other words, you have a service
out there. Do you send this thing out asking for data, and it comes back in
three minutes instead of in milliseconds, and you want to know, who answered my
query, and what series of systems did it go through, and how long did it spend
in each of those systems.

Is that a different category of requirements than what we have been talking
about, and do you see those as essential? Could I just get your thoughts on
those kind of things?

DR. WEBSTER: In our model all of these or most of these can follow the
model. First you have a community of RHIOs, whatever you want to call it, and
we connect those. The NHIN is proper to connectivity. At that level it is
implicit in all of our architectures, and stands for all the things we do. You
have quality service monitoring throughout that.

As Robert mentioned, we have all got an SOI architecture, and so we will
cross the service pluses that implement that SOI. It is very easy to monitor
that. It is particularly important when we have these federated data models
that we are all using. The last piece of data that comes across is your
bottleneck, the weakest link, and it is being hosted by some entity that is
outside of the control of the NHIN. So we can’t speed that up.

There are some things that can be done. One is, we monitor that, we
identify that six of these came out in two seconds and one took another two
minutes, and go back and look at what the root cause is. The system itself can
detect that, and start to do some healing on that or some administrative
things.

The other is that the edge systems themselves can be built knowing that
because we have a federated model, those things are always going to occur. So
they should be designed so they can prioritize what to display, not be
bottlenecked by the last data that is coming in, and also be aware that if I am
looking at an allergy patient, let’s bring up the allergies first. That is
going to be until I click the next page, anyway.

So it is a thing that the NHIN has to support and be able to identify, that
the edge systems can work around it and make the system much more useful in an
environment where that is always going to be faced.

DR. COHN: I see you nodding your head. Do you have another question?

DR. HUFF: You said that is inherent. I am trying to think how it gets
reflected in artifacts. If you are talking about the fact that what we need are
specifications for services, then that becomes just another parameter of the
service that allows you to monitor the performance or to know the pathway.

DR. WEBSTER: Implicit in SOI architecture that is quality of service
monitoring. Basically what we are doing is, every piece is instrumented or
metered to look for performance in an ongoing manner. It all gets audited, a
different logging from the uses log, an ongoing log, in the case of the IBM
system we will be using our utility systems, and they tend to be state of the
art, anyway, to say what are the bottlenecks.

Some are just the day to day differences with the Internet, routing errors,
the service things that will impact our availability, plus as I said the actual
availability of the data source itself is that clinic that is needing the data.
They may be having ongoing bandwidth problems, or maybe just a hiccup. We can
analyze those and we can deal with them in the same way that we deal with the
routing of the Internet today in all of these wide-area networks.

This is part and parcel to what all four of these companies do. We have it
implicit as we design architectures.

MR. KELLY: Stan, I would just like to add, as we work through these
problems, I think for the prototype it is going to be a little bit easier,
because we essentially will be responsible for bringing together our 15
provider organizations or three distinct health care markets. You have got
basically to make sure it works.

What will become much more difficult is, as we actually build out the real
NHIN, who is going to be responsible for basically monitoring and enforcing
those service level agreements for the operation of the edge systems, and how
they interface with it. That will become very important.

I think also, one of the things that those performance levels will drive is
how much data gets stored probably not at the national level, but in the edge
systems, and will that force some aggregation at more of the regional level, as
opposed to going directly to providers.

So I think there will be some tradeoffs between performance, between how
much you store at a regional center versus how much resides in the local
systems, that will be driven.

As we think through our usability, of how we want to present data for the
NHIN, one of the same questions we are struggling about is, do you show a
distinct health care market view of the data and then another essentially, go
fetch data from the NHIN? Or how do you parse the data and present it and store
it? I think there will be different approaches that will be driven by the
various performance.

So the prototypes will be less of an issue, because we have only got three
distinct health care markets, we have got one single vendor responsible for
making sure that connectivity is in place. But our architectures have to
support the complexity. Whoever will be in charge of the NHIN in the long term
will have to set those service level requirements and those interfaces.

Thanks.

MR. BLAIR: By the way, the testimony was extremely helpful from everyone. I
am grateful. I am especially grateful because this is really a challenge to try
to sort this through.

Let me state the premise of my question because it is based on what I hear,
and sometimes what I hear is faulty, some of your slides might say something
slightly different. But what I thought I heard seemed to be similar to a number
of the discussions that we have had on NCVHS here during the past few weeks
coming up to this area.

It has sounded to me as if there is this consensus that when we are
thinking of a thin set of functional requirements to the NHIN, almost everyone
seems to be saying that all aspects of privacy and security have to be across
the total network.

When they wind up seeing that, yes, there is acknowledge that at the edge
systems we need to have authorization, authentication, data access controls and
security such as encryption. I have been hearing those four elements. The thin
core NHIN has to include those.

Now, I am part of the chorus that seems to feel like it is very beneficial
to have thin. I am trying to sort through. When you talk about data security,
those four elements of data security, the primary elements of data security,
when I think of those, I know that almost every edge system has some aspects of
those four, or at least enable some support in some way.

So I am asking for some help here. I have no question that in terms of data
security for the network, some encryption or some way to protect the data when
it is in transit, that is essential. But on the other three is where I need
help. Is it really true that the core system — I could understand that you
have to authenticate that the entity getting on the network is who they say
they are, but the authorization function, is that really essential for the core
network? Is access control really essential for the core network?

So I am trying to parse this out, I am trying to understand it better.

DR. OVERHAGE: Let me take a stab at that, and you guys can correct me or
fix me.

The authentication in the Connecting for Health approach is really
distributed to the edge systems, and relies on a chain of trust, if you will,
from the organization that maintains and runs the edge system to the
organization that is maintaining and running the edge system that is consuming
data.

So through business schools, through contracts, through the P word that we
are not allowed to mention, there is an assumption, in other words, in order
for that to work, I have to be confident that the other organization is doing
its job and practicing good password hygiene or having multiple token
authentication, or whatever it is, that our business rules make me comfortable
that that authentication is faithful.

In that case, the Health Information Network doesn’t have to know very much
about authentication at that level. They do have to know authentication about,
I am getting data from Cincinnati and from Indianapolis, and Cincinnati and
Indianapolis have to authenticate each other. But that is at least in our
current model a heavyweight process. There is not an URL out there in the
Internet that anybody who conforms to the protocols can talk to; I am going to
exchange certificates or whatever it is with that other collection of entities
or sub-network organization.

So there is a trust at the server level, at the sub-network level, based on
a heavyweight authentication process. But for the individual producers and
consumers of data, at least we have chosen to try to distribute those as far as
possible, rely on business rules, policies and so on, to make me comfortable
that folks are properly authenticated.

Authorization is a little bit different story. Frankly I think it is a
maturing area for our thinking, and I’ll be interested to hear the solution
from these guys. But to date we have taken a fairly simple approach of not role
based, but level based, just because you have this challenge of roles being
inconsistent across licensed nurse practitioner versus a non-licensed nurse
practitioner, and a lot of subtleties, so simplify those a little bit.

You know you need those role based eventually, but maybe you just start out
at level zero, one, two, three. Then it becomes a question, at least for us,
of, as a recipient of a request for a particular piece of data from somebody
who I trust has become authenticated and has an appropriate access level
associated with them, because of business rules and policies.

So that again doesn’t have anything in the middle of the network. The real
question is, I as the recipient of a request or query for data will evaluate,
A, do I believe it is who it says and B, do they have the right level
associated with them by the organization that I trust. Then I will decide
whether to divulge the information or not.

So the network itself doesn’t necessarily have any knowledge of those
levels or roles, whichever they end up being, only has to faithfully transmit
them. It gets back to the speaker who pointed out that it is a simple component
of data models, of what roles, and being able to understand in a common way
what the roles are, but again, simple proxy level zero, one, two, three, takes
me a long way.

I don’t know if that answered your question. I’m sure I left out 27 really
important things.

MR. BLAIR: The only other piece on clarification is with respect to
authentication. You have been able to offload that from the core network,
because you did perform that at the sub-network level, is that correct?

DR. OVERHAGE: Yes, and even more than the sub-network level, at the care
delivery organization level. The sub-network has offloaded it further.

MR. BLAIR: How about the rest of our testifiers? Could you please weigh in
on this?

MR. KELLY: The way we are thinking about this is, we also are offloading it
basically to the lowest possible level. Quite honestly, you have to go down to
the provider organizations. They are the ones who know who the doctors are,
know who the patients are, and they are going to be fundamentally the ones that
need to authenticate these people.

I think what you really have to recognize is, and again, it is hard to have
this discussion without mentioning the P word, but what the NHIN has to do is,
it has to say what are the rules for an appropriately authenticated user, and
what are the different types of authenticated users.

As Dr. Overhage said, this is all about trust between organizations and
servers. Unless you know what those levels of trust are and what the rules are
for performing that, then you run into trouble.

The other thing I would just like to comment on a little bit about is that
while I absolutely think that authorization is primarily an edge function, as
long as the core system defines the rules for what is an appropriately
authenticated user, when we talk about authorization, while I truly believe
that most of the business logic for authorization should reside at the edge
systems because that is where the complexity that you can deal with this is,
over time that may actually become more sophisticated in the core system.

For example, if you were to look at the simplest model, where all that was
maintained at the core system was a DMS, a directory main server, that said
Brian Kelly’s records are in this location, this location and this location, it
is a pretty easy query to say fetch me all the records, and then I’ll let each
of those different edge organizations decide what information they might want
to serve back to me.

However, if we would like to be more selective in our request for
information for whatever, performance reasons or whatever, you may want to have
some of the business logic and the ability to ask different types of queries,
at least the policy set at the core system level.

So for example, we may initially decide the only messaging to do that type
of query is just, show me where the data is, and let us leave it up to the edge
systems. You may want to be able to define interface or a core system
capability that says, let me just ask the lab data, or let me just ask for this
type of data or that type of data, and that be a specific message.

Now again, we could send the message from the core system, but part of what
the NHIN would have to do is define what are the standards, how do you
interface, how do you manage this type of complexity.

So when we say the world is shades of gray, that is a lot of what we mean.
Again, it is trying to keep it as simple as possible so that the robustness in
those capabilities can be managed at the edge. But whenever they go across the
NHIN, there has to be policy and guidance and standards for how that occurs.

MR. COTHREN: Again, I don’t think there is much that I would add to that.
Our approach is similar, that we are looking at entity trust levels and
therefore authentication of an entity rather than individuals. Authentication
and authorization are managed by the edge systems.

I think what complicates it when we talk about NHIN though is that for the
first time, we are seriously talking about exchanging health information where
people are really concerned about privacy issues among organizations that don’t
do business together on a regular basis, and therefore need to develop some
level of trust among organizations that they are not used to trusting. Need to
feel comfortable that yes, that organization out in California is doing
authentication properly, is doing authorization properly, does have proper
controls on their system. It is not good enough for me just to trust the NHIN,
but I also need to trust all the other entities that are participating.

I think I am going to say the P word, because here we need to look at —
that there needs to be agreement on what those standards are if we are going to
get the trust levels where they need to be.

DR. COHN: And it is probably on these policies, procedures, et cetera.

DR. HOUSTON: We keep talking about edge functionality, and you all answered
Jeff’s question about things are going to happen at the edge, and
authentication and things of that sort.

I guess the question I have is really a basic one. Is there going to be any
capacity — or let me turn it around. Is the price of entry that the provider
has to have an EMR? And are we going to try to develop a method by which
providers who don’t have Internet capacity, don’t have information systems,
maybe pretty small practices, that have historically had very low adoption, is
there going to be a method, or is anybody contemplating a method by which those
providers can get information?

If that is the case, that does fly in the face of putting a lot of stuff at
the edge. So your thoughts on that?

DR. WEBSTER: I can tell you what IBM is doing. We still view the EMR system
as definitely edge. But at the same point, it is not a very interesting
demonstration unless you have an edge system to demonstrate on.

There aren’t a lot of vendor systems out there that are already enabled. We
are working with some who will be presenting some commercial products, but as
we get down into the smaller practices, a lot of those don’t have anything
today other than the small TMS system that is primarily financially based.

So what we have done is, all of the work that we are doing, all of the code
work, are open source based, anyway. We are planning to open standards, so it
means any relational database would work, any web server, application server
would work virtually on any platform. In following that mode and the open
source mode, we are working with OBMR and Clear Health and adapting their open
source, freely available systems to support the protocols we currently have.

So we can put out a system and say, at the very least we can set them up
with something that is usable. And we will support a rudimentary browser
interface. The data that we serve up is XML tagged. It is very easy to display
an XML CDA document on any modern browser. It will actually form itself fairly
nicely. There is always some way of displaying it.

But we do still view it — again, very clear, that is still very definitely
an edge system. It is merely to enable our community and to enable a more
interesting demonstration. We don’t see that as being part of the NHIN proper.
In fact, the team that is doing that is our research team as kind of a one-off.

MR. COTHREN: I think I can probably answer that question in two ways. At
this point we are not looking specifically at how you deal with single
physicians that are isolated from everyplace else, and how do they participate.
That comes as an edge function, how you service those folks, and therefore not
part of the core functionality.

That said, there are products that we are interfacing to that play
surrogate EMRs that physicians that don’t have full-blown EMRs are using as a
surrogate for that. Clinical messaging systems, data consolidators, et cetera,
that are served up by a portal, but still manage authentication and
authorization, but aren’t a full-blown EMR.

At least that is a step along that path. You can imagine how that might be
a much lower barrier for entry into practicing physicians to take that
approach.

DR. HOUSTON: The gentleman from IBM had referenced a couple of occasions
that he sees the Internet as the vehicle to transport data. Is that a given? Is
there any thought as to the fact that there is an infrastructure once it gets
past some of the rudimentary stages it is going to require some other type of
backbone in order to efficiently handle data at the level I think we are
talking about. Potentially we are dealing with image data and other types of
data that are going to be incompatible with using the Internet to transport it.

DR. WEBSTER: Two answers there quickly. First, it wasn’t given to us. That
was the starting point for the architectures. It was one of the initial
requirements, so we never dwelled on that.

That being said, I think that it is the right choice. When you look at the
amount of available bandwidth that is out there, I can tell you that the amount
of digging that has been done in my yard will last through — there is a lot of
it there. They promised my grass would grow back.

But there is tons and tons of bandwidth. With our encryption technology,
EPN and things, it really isn’t a barrier. The barrier becomes one of working
around some of the routing issues. As the Internet matures, we are having to
solve those problems anyway, because the world depends now on doing business on
the Internet.

We can’t let a single denial of service shut down the banking industry,
which is now doing it, we can’t let it shut down the medical industry. So we
will create the technologies that automatically do rerouting to prevent those
type of attack, and basically secure the Internet from the issues that I think
it would be most susceptible to right now.

So I do think it is the right choice. I don’t think we would consider an
alternative, honestly.

MR. COTHREN: I would completely agree with that. I would just add one
thing. Interestingly, the Internet 2 folks have approached us to talk about, if
there aren’t special capabilities for health-based approaches using Internet 2.
I don’t know that any of us are going down that path. I know we are not,
although we continue to talk to those folks.

DR. COHN: Mark Rothstein, you’re next.

DR. ROTHSTEIN: Thank you, Simon. I have one general question and three
sub-parts to the question. I will deal with the issue of privacy and come out
of the June 26, 2006 letter from the NCVHS to the Secretary on these issues.
The overarching general question is whether the essential elements that support
privacy and confidentiality are being built into the system architecture that
you have described.

Let me describe in particular the kinds of things I am talking about. The
first would be access controls for clinical applications. Several of you have
already mentioned that role-based restrictions are part of your system, but I
don’t think anyone has discussed the issue of whether there are limits on
classes of information that individuals could lop off and not disclose.

For example, I might authorize my records to be disclosed, but not my
psychiatric records to be disclosed by NHIN. Or another measure that gets to a
more detailed level of greater granularity would be blocking measures, where I
would say you can have all my information but not my HIV test results.

So from our letter that was considered by the committee to be the kind of
thing that needs to be considered for the architecture, that is the first.

The second area would be disclosures for my medical uses. We specifically
identified the possible use of contextual access criteria to limit the scope of
information disclosed to third parties for non-medical uses.

So an example would be, a licensure wants my medical record to see whether
I am insurable. They don’t need everything, they just stuff bearing on my
mortality risk. We wanted to know whether the potential capacity to do that is
going to be built into the system.

Finally, whether you are working on any sort of base functionality for the
non-medical users, because these people are not covered entities under HIPAA,
and so a policy decision might be made that no health information is going to
be disclosable by the NHIN to someone who does not have a secure system for
protecting it, because they are not currently required to have that in place.

If that is the policy choice that is made, I was wondering whether it was
within your purview and part of your plan to figure out what that minimum would
be, because it is not going to be necessarily the same as for the security
standard. Is it authentication, is it encryption? What sort of stuff would be
in it?

So those are the three parts of the general question.

DR. OVERHAGE: I’ll take a first crack at that. That is one of the reasons
that the Connecting for Health model leaves those decisions at the edge
systems. In other words, a query from a licensure for example would go to your
doctor’s system or its proxy, and that is the point where those controls would
exist, so that you and your provider can have decided what it is that would be
disclosed.

Then the question becomes, do those edge systems implement that
functionality, and that gets into the evolutionary nature of this work. Today
many of them do, because those are the kind of things the commercial vendors
build into systems, because of the kind of requirements that you describe.

So I can’t speak for sure from the others, but from what I understand, I
think in general we all have that kind of principle built in, the capability to
support that built into the model. It is not really part of the network,
though. That is the edge, because that is where the data largely resides with
some nuances of that.

Maybe I will talk about that topic first before I move on to your third
one. The first two are addressed by the answer that yes, that is very
important, yes, it is addressed, it is addressed at the edge application level.

DR. WEBSTER: IBM is a little bit different than that. Ours is implicitly
addressed within the NHIN with role-based assignments into the NHIN itself
using the technology.

The reason we chose role rather than tier, although in the process that is
going to be done at the tier level, is simply flexibility. It is not clear that
a physician working in a big hospital would be able to edit demographics or
change addresses. That is what your medical records are for. In the mom and pop
clinic they do everything.

So a single role there isn’t necessarily ubiquitous or tier. So we just
look at what we call the CRUD elements, create and replace, a big leap, that is
a common acronym, and a matrix saying does this role in this environment allow
this type of activity in this type of data.

Now, when we get into things like the HIV behavioral health, it is not a
straightforward answer. Our architecture is going to support that, because it
seems like that is the way the wind is blowing. We need to put that in, and we
think that it is important to build an architecture that supports our framework
for keeping the initial implementation for the prototype as thin as possible to
meet the requirements.

Where it gets tricky is first, granularity of data. As something comes in
as a lab result, if the test was for HIV, that is fairly straightforward, but
what if it is some type of a chem panel, the interpretation of which reveals
that it is HIV positive? How do I detect that? Where is that data coming from?
It gets back to the policies becoming codified, and we start to tag those
things.

HIPAA, and I have had the displeasure of reading through the whole HIPAA
thing, really only covers one area, and that is behavioral health nodes, which
will never be in the NHIN. So we get into, below that what does each state and
each institute want to start to get to. We can talk about that offline, but it
is in terms of the protection of — in Section 4C it talks about the behavioral
health nodes as the one real exception, and everything else is listed as high
sensitivity across the board equal to your demographic data.

It is a matter of, can I detect that this is a piece of data of that type
to restrict its access. That depends on the policy to say, go find me some way
to do that, some LOINC mechanism, some SNOMED mechanism, that I can parse on
and say, I recognize from here on out this data works on this type of
sensitivity, and then I can overlay the roles very easily.

So it is, give me the right data and I can enforce it, but the policies
have to provide that data.

MR. COTHREN: I guess my answer is probably going to be dissatisfying,
because I think that we do believe that there needs to be as part of core
functionality some mechanism for managing consent and exchange of information.

If you participated at all in the NHIN forum in June, I spent a great deal
of my time in the consumer empowerment groups, the PHR groups, et cetera. One
of the things that I was really struck with overwhelmingly, there was a huge
desire of the public to have an incredible level of control over the exchange
of their data at a very granular level, both from a data standpoint and an
access standpoint. I want to control whether this physician can get access to
this particular lab result.

So we believe that that needed to be something that was at least supported
in an NHIN architecture. The disappointing part is that Casey has described
some of the complexities to doing that. We are exploring that now. How much of
it will actually be built out as part of the prototype this year is yet to be
seen, but we believe that the architecture needs to support it, the
architecture needs to support whatever policies.

DR. ROTHSTEIN: So where does the disappointment come in?

MR. COTHREN: That I don’t know if you are going to see it at the end of the
year.

MR. KELLY: Just adding from our perspective, I will agree a lot with all of
the previous comments made. The point I would like to emphasize is that as we
have thought through this, we do believe that a lot of it is going to come down
to policy decisions. We do believe that a lot of this control is going to have
to be managed by the edge systems, because quite honestly, to a large degree
the business rules of who can access what data under what circumstances will be
set by local communities.

So while there may be some commonality of features that will roll up into
some sort of a superset of requirements on who can access what that may be
managed at the core level, much of this will be pushed back.

I would like to emphasize though that to do the complexity of what we are
talking about is something that we are all going to have to work through, and I
think will be built incrementally over time, for two reasons.

First of all, you have to do authentication, you have to do authorization.
You have to do role-based access. You have to do patient-provider
relationships, and then you have to have emergency, break the glass type of
functionality, which all in a distributed environment when you get outside of
the single health care organization is not without challenges.

The other thing is that to really do that correctly as was mentioned
before, you need a canonical data model, because until you have common terms,
then knowing what a document is, or what is in a document, or what is the meta
data associated with that becomes impossible.

Even if you have that canonical data model, the more complex you make the
business rules, the more you impede usability. While the patient clearly wants
control over who might have access to their data, if you are on the provider
side, you may push back and say, don’t just show me 70 percent of the record, I
need 100 percent of the record, and who is it to tell me that I can’t see that
record because you may be impacting my care.

Those type of balance issues have to be sorted out at the distinct health
care market level, at the provider organizations, and will be part of what we
are going to learn and will have to work through as we implement the
prototypes.

MS. BOWER: I am Cynthia Bower, Office of Disease Prevention and Health
Promotion at HHS. My question is primarily a conceptual one, but I think it
goes to this issue that we have been talking about with first principles and
what is the minimum requirement there.

In three of the four presentations, I noticed that there was an explicit
use of the word patient rather than say consumer or person. I am wondering if
anything about your remarks would change if you were to substitute either of
those terms and not talk about patient.

The reason I ask that is because explicitly in the IBM presentation, it
says the goal is secure sharing of economically available patient, clinical and
demographic data. Then in the Accenture presentation it talks about unique
identification of patients, and then also in the Northrup Grumman it talks
about finding patients.

So I am wondering, is there anything about what you said today that changes
if you don’t think about people as patients in that role?

MR. COTHREN: I don’t think so, to be honest with you. We are so ingrained
with some of the technologies that have P as patient in the name, that that has
become part of the lingo. But I don’t think that there is anything particular.

In fact, if you look at the consumer empowerment use case, it is consumer
empowerment use case, it is not patient empowerment use case. So I don’t think
that anything that I said would change if we could go through and replace that
word, and I feel comfortable with that.

DR. WEBSTER: And in the use case it is a patient health record we are
dealing with. Consumer implies a business kind of focus, and what we are really
focused on is medically related data. But there is certainly nothing that was
meant to be exclusionary about consumer. The word consumer seems to me to be
more business types of thoughts as well, and I don’t know that that is really
the focus we have had. It is the owner of one’s personal medical data, or
whatever term best describes that.

MR. KELLY: Probably the better term for me to use is just person, and a
person has lots of different roles. He may be a patient, he may be a provider,
he may be a lot of things.

We think about how we put our information model together. It starts with a
person. Again, the role could be consumer or it could be patient, so
fundamentally no difference at all.

MR. COTHREN: Do you mind, can I ask you a question back? Is there a way
that we should be thinking about this?

MS. BOWER: For example, one of my colleagues mentioned in a client role
when talking about social services data. The gentleman from IBM said it was
medically related data; social services data is not medically related data.

That was why I wanted to hear you articulate that. Are we really truly
dealing with medically related data, as an organization to organization
exchange of clinical data, because then I think we are talking about a national
clinical information network, not a national health information network,
because health goes far beyond what happens with medically related data. I
would argue a lot of prevention related activities generate data that are
currently not recognized by the medical system.

MR. KELLY: I think in all of our visions of the NHIN, we clearly wanted to
support the broader context.

DR. COHN: And we will be having a panel towards the end of the day on
consumer empowerment, so hopefully we will have a chance to talk more about
that.

DR. DEERING: I’d like to push you a little bit harder. Let’s take the
consumer for a minute in the PHR situation. At this point there are a variety
of vendors out there. I just want to be clear. Is the consumer, who has
purchased or required free of charge from some source a means of collecting
their own data, where do those business agreements reside? Is it with the
individual vendor? Is it with whoever has offered that system? And who is it
that puts into place the ability for that information sitting at 1000 Oak
Avenue in Smithtown, New Jersey the ability to be recognized and authenticated,
et cetera?

DR. OVERHAGE: This is a dicey one for a lot of reasons, but in the
discussions that we have with Connecting for Health, one of the challenges is
authenticating the consumer, the individual, how do you know who is there.

So this gets back to this notion of, if you have let’s say a commercial
provider or a public good well provider of personal health records, at some
level you have to insist that that provider of personal health records conform
to the same sorts of rules, protocols, processes as any other participant in
the National Health Information Network. They can be no different.

So the question then becomes, can I find a vendor of personal health record
systems, for example, that can credibly authenticate its users, the consumer,
at a level that the rest of the participants in the NHIN could find comfort it.
A lot of our discussions have come to say, we are not sure about that. We are
pretty sure, because we trust other entities that are clinical care delivery
organizations at some level, but maybe we trust another clinical care
organization to authenticate individuals, if you want to think of it as a proxy
almost for the individual, if you are a doctor or your health plan or whatever,
maybe they could authenticate you as a proxy.

But that really has nothing to do with being a care delivery organization,
but rather with the question of who could credibly do that function, which is
an essential function, to the level that other folks in the NHIN could buy it,
if that makes sense.

MR. COTHREN: There are a few things that make PHRs a little more complex,
but in many ways feeling comfortable about a trust relationship with a PHR is
really no different than a trust relationship with — you still need that level
of trust with the entity.

Then you need to address the issues of the level of trust and the
information that that entity holds, and that is a can of worms to open up when
you are dealing with a PHR. I have access to information that a physician may
act on. How do we deal with that? Do we need to start tracking where this
information came from, et cetera, so that you know that it is something I had
rather than another doctor, and you need to have that be part of your decision
making process when you are deciding how to treat a patient.

DR. COHN: Thank you. I just want to review what we are going to do. We have
got a number of other questions. What I would like to do is go a little past
noon, allow any questions from people in the audience also. I think this is a
useful conversation. I just heard from Mary Jo, we are allowed to go a little
after noon on this one.

I have two questions that I would like to ask, and one of them is a little
more painful than the other. One of them is just a clarification, so maybe I’ll
start with the clarification first.

Brian, it is for you. I was reviewing your presentation, and I saw your
representation of the template that you have described. I think part of this
may be a mistake, but I also had a question. You have added something to the
list, it looked like, which is called some anonymized data aggregation, which
appears to me to be a core essential requirement. I am wondering, can you tell
me a little more about that, and what specifically you mean?

MR. KELLY: Sure.

DR. COHN: And I am presuming you do not mean under, e.g., audit trails and
authentication, only meant to be under security?

MR. KELLY: Yes. I was trying to look at your document and trying to put it
in a framework that made sense.

You could do anonymization in data aggregation at multiple levels.
Certainly it could be an edge function. Essentially what the NHIN does is, it
says just send the anonymized data, here is the format I want it in. But if you
wanted to be a national aggregator of data under the future NHIN, you could
envision the world where the function might be. The only place you could
aggregate that data would be the bullet from all of the different edge systems
in the nation, and put it into a database at CDC or FDA, or the like.

We may decide for anonymized data that that could be considered a core
function. You could also say that could be any database anywhere, and what we
will do in the edge system is, we will say here is how you anonymize the data,
and just send it to me and we will store it in some central database somewhere
for CDC or FDA to look at and do data studies on.

So I basically look at that as potentially that could be a core function,
or we talked about before, it could be federated out. It really is a function
that I would like to see in the NHIN in the future, because without that type
of function in the NHIN, we will not be able to support public health
surveillance and drug safety and some other clinical research parameters that I
think are very important.

DR. COHN: Let me just make sure I understand. There is the function called
anonymization, and then there is the function called data aggregation, and then
there is actual data aggregation which is the creation of a database as a core
function.

You talked previously about the actual function of data anonymization. This
appears to be more describing a database that resides as a core function. Am I
confused here?

MR. KELLY: First of all, I think that all of us have a lot of — we talked
quite a bit over the last year about, do any of us want to have a core function
of the NHIN to have a lot of personally identifiable health information. I
think the general overall impression is no, we do not.

However, might there be national databases or potentially international
databases in the long term of anonymized data that we might want to be able to
leverage across many different sectors. I think the answer is potentially, yes.

So I would like to say for anonymized data, might that be a function that
the NHIN needs to support. I think it might. I think it is certainly worth
discussion. To say that that is not a capability, I think it should be
discussed.

MR. BLAIR: I think if I hear you correctly, you are saying the aggregation
function is potentially a core function?

DR. COHN: I am hearing two things. One is, the function could be that the
actual database could be a resident of the core.

MR. KELLY: Our charter was to talk predominantly about what were the
functional requirements. Let me couch it in a different manner. I think that in
my opinion, one person speaking, that a good requirement for the NHIN would be
the ability to do national studies on anonymized data. How that occurs, whether
the data is anonymized in the core system or in the anonymization process, is
an edge or core function, where that database resides, I think that was an
implementation issue. But I do think the ability to do national anonymized
studies should be a function of the NHIN.

MR. BLAIR: Could I parse that a little bit?

DR. COHN: Jeff, I want to hear from the other speakers. Then I’ll let you
toss it a little bit. I’m just curious about what the other —

DR. OVERHAGE: Number one is, you could think of aggregation of multiple
patients in multiple places, or you could think of aggregation for a single
individual, not necessarily stored, cached transiently.

We have that concept of a function, saying after you go and ask all these
107 places for data, something that assembles that data into a more usable
form, and it answers my question as an application, as an edge application in a
more usable fashion, instead of me having to do that, instead of every edge
system having to figure out how to bring all those things together in a
rational form. There are a lot of dimensions to do that.

So aggregation depending on the context might mean different things. I
think that in the Connecting for Health discussions, the capability to create
an identified or de-identified database of individuals from a broad set of
settings is certainly something that we would want to enable with the NHIN.
Whether that is part of the NHIN itself or it is yet another edge function, I
think we might debate. But it certainly can be an edge function enabled by the
NHIN, and then you can satisfy that functional requirement. You are able to do
that without necessarily having that aggregator or database be a part of the
NHIN itself.

MR. COTHREN: I think that is the way to look at it. If you come back to
minimal essential requirements, NHIN at least in my view needs to enable the
movement of information, whether it be anonymized or not for whatever purposes.
Whether that aggregation, whether that anonymized database is a core function
or not, it doesn’t seem to me that it makes a test for minimal and essential.
It is a desirable outcome of NHIN to have that facility, that it be a
requirement of the core system, doesn’t seem like that is necessary. For
example, CDC does maintain databases of surveillance information now, so
duplicating that as a core function would not make sense necessarily.

DR. COHN: The reason I am asking is not as a policy issue, but more that it
is in the box, trying to figure out how you were thinking about it. Jeff, did
you have a follow-on on this one?

MR. BLAIR: No, thank you.

DR. COHN: I thought this was going to be the easy question. The tougher
question is, before I blow you out of the water, when you had discussed
canonical information models, Brian, you had discussed canonical data models,
and Marc discussed HL7 version 2.x, and I don’t know exactly what you were
discussing about this one, is this all of your attempts to talk about canonical
information models?

Is that an essential requirement, essential now, essential later? Where are
we on that one? I didn’t see it listed in any of the 1100 requirements that I
was looking through, something in line with a canonical information model, but
I may have gotten sleepy or something.

PARTICIPANT: Let me answer your question. They explain what that is.

DR. COHN: Oh, please, that is even better. My question is, is this all the
same thing?

DR. WEBSTER: I think we are all using canonical frameworks, although
different ones, but for the most part some flavor of the HL7 rim, because it is
ubiquitous, it is low-hanging fruit. You need some way to share the data
amongst the entities that have commercial vendor systems that don’t speak
anything else.

So in the case of the IBM solution, we are using the HL7 clinical data CA,
R2, which is convertible from HL7 3.x or 2.x, and they are all built from the
same rim. We are using that as part of our IG framework to provide the ability
to say we should throw all the data into this format, and applying the 80-20
plus rule, most vendors can bring that in or send it out in some format. We
establish a low barrier to entry.

But that is also a pretty high level framework. It doesn’t necessarily
require — the underlying data itself is codified. They all allow free text,
they all allow ASCII or blobs or KFLs or anything to be embedded.

We go to the next step and say we want to get down in our case to the CDA
level three architecture where the data is codified, whether it is SNOMED or
LOINC or something we can use and permit outcomes analysis and other types of
intelligent use of the data at high levels. That is absolutely an IBM viewpoint
that that has got to occur.

Separately, Ivo Nelson from Ambience Health Care testified on the Hill
about two months ago exactly to that. We think that is critical to the future
of improving health care. You can’t do quality analysis, you can’t improve
medicine unless you take this corpus of knowledge and put in a way we all
understand it, and can run it through databases and data warehouses
intelligently.

MR. KELLY: I think it is a matter of how we incrementally build and go
forward. As Casey mentioned, and I think he said it very well, we have got to
eventually get to a common language for sharing health information, and that
means that we need to have a common data model, we need to have common data
standards, and there is a lot of work obviously going on in that area.

That is though a very high bar. If you have seen one legacy system, you
have seen one legacy system. The data in the next one is different, you can be
sure of that. So how do we basically foster adoption, but at the same time
chart a path forward that will allow us to get to the outcomes that we want to.

So it really is a balance. I think part of the leadership that can be shown
going forward is to say, here is the minimal criteria now, but here is where we
want to go. In three years here is how we want to incentivize people to move
this way. You have got to show the path, and part of showing the path is
setting what the future standards might be.

MR. COTHREN: Since I put it on my slide, I think I have to say something,
don’t I?

I don’t know that there is an important distinction between a canonical
data model and a canonical information model, at least for our purposes I don’t
think there is an important distinction. We are really looking at a structured
way to represent information we can all agree on, we can all share, and it
becomes part of the standard of how we talk to each other. Whether that is HL7
V.3 rim or whether it is something else is a completely different question,
whether you have an information model or whether you adopt the rim.

Connecting for Health is moving forward without necessarily standardizing
on V.3, and still uses an information model I’m sure in some of the
applications. The VA’s information exchange system that we designed several
years ago builds on a V.2 information model, even though the V.2 standard
doesn’t support an information model directly. But an information model is what
is important, whether it be the V.3 rim or not. I think we believe that it is
important.

DR. OVERHAGE: Nothing to add.

DR. WARREN: I just want to clarify here. We asked you to define the
canonical information model, because when you go out in the literature you hear
people talk about it all different kinds of ways. No one has defined what they
mean. They have given examples, but you never told me what you think you are
talking about when you say it.

DR. WEBSTER: I think it is easier for me to just point to the rim and say I
think that is a good example of a canonical model.

DR. WARREN: So are you saying that the rim is it?

DR. WEBSTER: No, not necessarily, but I am not in a position to make that
determination. I think the policy groups have to look at what is out there. I
am saying it is a good one today, and it is widely known and it is widely
adopted. That is the type of thing that I think we are all referring to.

MR. KELLY: I think — and again, I am not the HL7 linguist, but essentially
it is a model that basically shows relationships between entities and roles,
and the different things that go into an information model.

There are lots of different components to this, but to Casey’s point, go
talk to the HL7 rim folks, and they can tell you exactly what the definition
is, and I can’t.

DR. WARREN: That is exactly my point. I have done a lot with HL7, and those
words get thrown out there. I just want to be sure that I am hearing the way
you are meaning when you say the words.

MR. BLAIR: Can I do a followup question on that, a definition?

DR. COHN: Sure.

MR. BLAIR: Do you also consider an ontology like for SNOMED a canonical
model?

DR. WEBSTER: On behalf of IBM, I guess I do. I have worked quite a bit with
SNOMED, SNOMED-CT and their predecessors, for my previous companies developed
tools for it to be modeled in.

MR. BLAIR: Other than SNOMED and HL7 rim, maybe if you give us some other
examples that you might have in your mind, even though it is not a specific
definition that might help to answer the question?

DR. WEBSTER: There are lots of almost-there’s, I guess. You can point to
ICD-10, you can point to UMLS. They are all trying to do the same thing, which
is to establish the terminology and the role relationships between them in a
medically relevant world, but they have to bring in things.

Like, Comidas 4 is a modelable entity within SNOMED. So they get to the
point where we can say a subjective assessment, using real-world terminology,
we need that level of ontology. At the same point, that becomes hard to use in
a practical manner. It is a tough tradeoff, but I think that is the direction.

DR. COHN: I was just looking at our calendar, and I realized we didn’t have
quite as much time as I thought we did, so I apologize. I thought we could move
on to 12:30, and I don’t think that is going to quite happen. We will probably
have to wrap up over the next 15 minutes.

Harry, you have a question, Mary Jo has a question, we’ll see if there are
any questions from the audience, and then we’ll have a final comment or two.

MR. REYNOLDS: As you look at HIPAA, we have personal health information and
then de-identified. If you are a person, you are using anonymized and
de-anonymized. Are those terms of art? How do they relate to — in other words,
as we have tried to deal with the whole national scene and what we have done in
trying to put those four definitions, is there a set definition that each of
you are using for anonymized and de-anonymized, and how does it relate to the
things that are already on the table for consumers and everyone, based on
de-identified and so on?

DR. OVERHAGE: I think we are probably just casual about the terminology. I
think most of us when we think about those terms are thinking about the HIPAA
definitions of de-identified and facially de-identified. We are just informal.

MR. COTHREN: I’m not sure I completely agree. The de-identifying and
de-anonymizing is relatively straightforward. We are talking about relinking
patients that may have been identified through public health means, part of
surveillance, anonymized information that needs to be tracked back to the
patient for investigation. That is pretty straightforward.

What the use case for biosurveillance calls out is that we anonymize that
data, and that that is not the same definition as HIPAA de-identification. It
is a lower bar than HIPAA de-identification.

I think that you ask a good question, because part of understanding the
trust levels, the confidentiality levels, et cetera, of the NHIN, I think that
is an issue that we ought to be discussing; should we be talking about full
HIPAA level de-identification, or is anonymization stripping name, address,
birth date fields, sufficient, or do we need to go beyond that. Going beyond
that is difficult, but is that something that needs to happen in order to get
the trust levels for adoption.

So I don’t view it casually. I think there is something in particular that
we mean there, but I think the issues still remain.

DR. WARREN: Anonymized, you are going to revise the data, but do you want
to go back and re-identify that person or de-identify?

MR. KELLY: The difference is that there is a specific HIPAA definition
around de-identified, which means you really, really, really cannot tell who
that patient is. Anonymization is, you have basically stripped out most of the
demographics.

But if you had a small enough population, you were a two-year-old who had
Von Hippa Lindau disease in a city in Montana, you might be able to figure out
who that is. So the reason that we like to use the word anonymization is, it is
a lower bar, and it doesn’t have the legal ramifications of de-identification
around it.

MS. AMATAYAKUL: Could that become a limited data set under HIPAA?

MR. KELLY: I’ll be honest, I have to plead ignorance on exactly what HIPAA
defines as a limited data set. I don’t know if some of the other —

DR. HOUSTON: I think you need to be careful about using that. From what I
heard, it sounds like it probably doesn’t fit any of the HIPAA definitions, so
we have to be very careful about trying to shoot one in, because I think we are
talking about a different animal.

DR. DEERING: I have the opposite of the $64,000 question that you all have
been answering. My way of phrasing the question, since we have had such a
lovefest here and you agree on so much, categorically, can you point to from
your own individual perspectives, any place that you are unique, or that you
think you do differ from someone else, or from all three of the others? Is
there anything that is absolutely unique or different about your approach?

DR. WEBSTER: I think the IBM architecture is the only one that does
actually tag the locator data with more than simple patient identity and data
of record location. We do support tagging at one or two levels beyond that, so
that at the point of going up to the record locator, would it be possible to
determine is it a lab data or is it an allergy or whatever that might be, which
goes back to a discussion that Harry had mentioned as one of the examples.

I think we are the only one that does support that. Certainly we understand
the uses around not having it as well.

MR. KELLY: I think from a NHIN requirements perspective, we are coming to
fairly good confluence on what we agree on. I think what we are emphasizing in
our implementations for the prototypes is where we begin to differ. I think our
approach is more heavily emphasizing data standardization to the version of
three norm than some of the other vendors are. I think some of the other
vendors are implementing maybe more robust document exchange services as
another way of doing that.

So Mary Jo, from a functional requirement perspective, I think there has
been a fair amount of harmonization among our approaches over the last several
months, and I think we have all learned from each other, which is in many ways
a good thing.

I think what you will see exercised in the prototypes are different
elements and approaches, and different foci on specific elements of that type
of overarching function.

MR. COTHREN: I think I would agree with that. From a requirements
standpoint, I don’t think there is a whole lot of difference.

I do think that you will see differences among some of the different
approaches. Casey brought up one, that IBM supports a relatively rich
methodology for tagging information, whereas our approach does not require a
document registry at all. That is merely a different approach to, they locate
records different than we locate records, but we both locate records.

I would say that one of the other things that we have been trying to
explore, and I wouldn’t say this is a requirement issue either, but one of the
things that we have been trying to explore, since we are talking about a
nationwide health information network, what sources or consumers of information
on a national scale would make sense as participants in NHIN.

I keep coming back to one example because it is one that we are working on,
working with RxHub, which can provide medication history for a large number of
the American population. Should that be an NHIN provided service, as opposed to
linked into specific EHRs. It is exploring options like that is where you will
see differences among our approaches, as opposed to basic requirements.

DR. OVERHAGE: There has been a very rich dialogue, and all of us have
learned a lot from the discussions in these kind of sessions, and the questions
that come from the audience and so on.

I think if I had to try to pick something, it is that we tend to be a
little bit more extreme on pushing things to the edges, perhaps, or a little
less willing to put it into the NHIN if we can find some other way to do it.
That may be wrong at the end of the day, but it is a test we keep applying to
ourselves and saying, is it something that we absolutely incontrovertibly have
no other way to do. It may turn out that there are some things that you can’t,
and that will be some of the learnings from the prototype.

So I would echo the comments. I think that taking this next step of taking
a fairly homogenous set of requirements and turning them into a sane level of
reality will expose some of the subtler differences, because that is where they
will come out when you actually start to do it and go, I thought we could do
that.

MR. COTHREN: I think that is a good point. One of the issues that you talk
about, we all say that we are federated, but federated means different things
to the four of us. It is different levels of the type of information that we
actually maintain as part of core services, versus push all the way to the
edge. But again, that is an approach, not a requirement.

MR. REYNOLDS: Robert, as you were making your presentation, your comment
was, one core was not enough, that you have more than one core. So taking your
comment, if Casey has a record locator service that has tags, and they were
both set up as cores, how does that work?

MR. COTHREN: I think that is a really good question, because at least part
of the reason that we are looking at an approach like that is that I don’t
believe that you are going to necessarily have one provider of NHIN and you’re
going to be all done. There is a need for us to at least conceptually, how
would we link together what I would think of as IBM’s and NHIN’s solution as a
core to one of my cores. So those are the types of questions.

Now, from my standpoint, what that means is that defining rigorously the
interaction between core systems is something that we need to do. That means
that in querying one type of system you may be able to do a richer query,
whereas in another one because that information isn’t stored and you have to
reach out elsewhere to get that information, the mechanisms beyond things may
be different. What really needs to be established is a mechanism for
requesting. That is the abstracted request for services I was talking about.
There needs to be a method to request information on a patient, whether it be
from Indiana Health Information Exchange or IBM’s NHIN model, but there needs
to be a method to interoperate independent of the data representation
internally.

MR. REYNOLDS: So there is a base functionality, a base setup that can be
used for all, and then some become —

DR. WEBSTER: Largely so, or different. IEG, which is the parent framework
for IBM and Connecting for Health, Markel are actually already working
together. I was on a call yesterday, and he says no tag, we don’t to expose
anything. We support the tag, but ultimately it is a question of distributing
the query and ignoring the tag and saying, for this patient here are the URLs
that this particular SNO or community can provide. In doing that, CFH is
creating an inter-SNO bridge, or IEG is creating something similar, and we are
connecting through that.

So we are going to support that functionality, and I think over time you
will see those two models really become one. The idea of the middle tags
becomes an implementation to say, do we do it in this community or not. I had
the discussion with others, and nobody really disagrees. It is more
philosophical.

DR. COHN: I want to thank everyone. We are pretty much running out of time
here. We will re-start at 1 o’clock. I do apologize to our audience, because
without even looking at them I’m sure they probably have questions, and we just
don’t have the time. We are going to have a public comment period towards the
end of the day, so any public comments or discussion you can have with the
audience. I do apologize.

John Loonsk, I do apologize for not introducing you earlier. He is the
Director of ONC. We are very pleased to have you here. I know you want to make
a couple of comments. Then I want to close and give everybody lunch for 45
minutes. DR. LOONSK: Thank you, Simon. I think it was a very interesting
discussion this morning, and a lot of good conversation, and excellent
presentations.

I do think that it is important to revisit a little bit of what Harry
mentioned at the beginning of the morning, particularly around this concept of
core versus edge. We found it to be a very useful initial construct to start
talking about issues. As the discussion went today, and as the work has gone on
in the NHIN, it eventually starts to degrade as a concept and as a delineation.

I think at times, some of the conversation is about what is thin versus
what is minimal requirements, versus initially. So we have gone around several
of those issues.

Another related factor is requirements versus services. I just wanted to be
clear that in terms of what we see the need is here now, the requirements
relate to the totality of the effort involved. Harry said it, but it is worth
revisiting, particularly with the concreteness of saying that if there is a
requirement for an edge system so it can participate, that is definitely in
scope now. If there is a requirement for a system to exist on the edge that
doesn’t exist to accomplish network functions, that is in scope now, too.

So just revisiting that and trying to nail it down, so that we can all talk
about that in an ongoing way, is something that I think is worth doing as well.

DR. COHN: John, thank you, that is a very useful comment. Certainly from my
view, I think it has been a very rich conversation this morning.

I would suspect that by the end of the day tomorrow, we may have some
additional questions that we will send to the consortium representatives for
some additional clarification or otherwise. I’m sure there will be additional
issues that come up. I am hoping you will be available to respond by e-mail or
otherwise with that. But we do want to thank you for your participation.

What we will do is, it is now 12:17, we will break for lunch. We will
reconvene at 1:00. We apologize that we are running a little late, but I think
it has been very useful. Thank you.

(The meeting recessed for lunch at 12:17 p.m., to reconvene at 1:07 p.m.)

A F T E R N
O O N S E S S I
O N (1:07 p.m.)

Agenda Item: Panel II: Regional Health Information
Organizations

DR. COHN: Our next session is entitled RHIOs, Regional Health Information
Organizations. We are very pleased to have Blackford Middleton here joining us
to lead off the conversation. As I understand it, we have both Jac Davies and
Jan Root calling in via conference call to provide their testimony. You can
hear me and you’re both there?

DR. DAVIES: This is Jac Davies. Yes, I can hear you.

DR. ROOT: This is Jan Root. Yes, I can hear you fine.

DR. COHN: Great. I think I should first of all start by — we all commented
we have no conflicts of interest except when they come up, so I do want to just
observe that I am an advisory member to the HIMSS board. Just as a public
statement, I don’t vote on HIMSS issues, but do participate in the board
activity. Margaret A. is actually a member of the HIMSS board. Given that
Blackford, even though he is post chair of the HIMSS board, is not currently
acting chair. He is representing HIMSS in this discussion. So that is just by
way of public announcement and observation of possible conflicts of interest.

With that, Blackford, why don’t we let you begin? Also, thank you very much
for being here.

DR. MIDDLETON: Thank you very much, Simon. It is a pleasure to be back with
the NCVHS. Given this morning’s conversation, I was recalling testimony I think
I gave in ’98 or ’99 or so about syntactic-semantic interoperability. Those
terms have now come back to haunt us perhaps as we think about canonical data
forms and interoperability.

I do have prepared testimony, which I would like to go through with you
very briefly. There is a shortened form and a longer form. I would ask that the
longer form be added to the record, and the shortened form to be part of the
oral testimony. There is an accompanying slide set. I’d like to recognize the
hard work of many folks, Trisha Gerber, Tom Leary and others, Janet
Marchabroda, I am forgetting others, from EHI and HIMSS who did help pull this
testimony together, and I only had to do a few edits and tweaks.

Distinguished members of the NCVHS and its ad hoc work group and the
National Health Information Network, I am honored to be here today to testify
on the following: An overview of health information exchange and Regional
Health Information Organization development across the United States; lessons
learned from the e-health initiative and the Health Information Management and
Systems Society, HIMSS, work in this area, and make some joint recommendations
from HIMSS and eHI on the core functions appropriate for the initial rollout of
the Nationwide Health Information Network, hereafter referred to as NHIN,
within the NCVHS draft NHIN conceptual framework as seen through the lenses of
HEIs and RHIOs, and accompanying policy recommendations. I will de-emphasize
the latter, accompanying policy recommendations, as directed by the Chair, but
they are in the longer testimony, spelled out.

Thank you, Simon, for that kind introduction. My name is Blackford
Middleton. I am Corporate Director for Clinical Informatics R&D at Partners
Health Care, and chairman of the Center for IT Leadership in the Partners
Health Care system. I also serve as a member of the faculty at the Harvard
Medical School and the Harvard School of Public Health. I am testifying today
on behalf of both eHI and HIMSS, as I have said. In my remarks I will share
insights from these two organizations, as well as those that I have gained
through our research at the CITL.

The U.S. health care delivery system, as has been discussed already in
many, many different ways, is in the midst of a fundamental transformation.
Numerous reports from the Institute of Medicine suggest that the adoption of
HIT is a fundamental and required step towards improving health care.

Studies we have done at the Center for IT Leadership in Boston suggest that
electronic health records with advanced computerized provider order entry
capabilities if deployed nationwide could save the country $44 billion. If
these tools exchange data one to the other, the vision of the NHIN, a second
study found another $78 billion potential savings is available. I provide
reference and citations for those studies on the slide.

The economic motivation along with pressure to improve patient care,
quality and safety, is driving broad interest in health information exchange
and RHIOs. State, community and regional health information exchange
initiatives and organizations are becoming the underpinnings for a system that
will improve how health care is practiced.

The number of HIEs is growing notably. For example, eHI’s connecting
communities with membership now includes representatives from more than 280
state, regional or community based collaboratives engaged in health information
exchange.

Both eHI and HIMSS are active in supporting HIEs coast to coast in our
country. eHI’s foundation with funding support from the Department of Health
and Human Services supports multi-stakeholder HEI collaboration at the state,
regional and community levels, and has built a community of more than 280
state, regional and community based multi-stakeholder collaboratives working on
HIE within the U.S. They regularly insights and work to effect change through
the connecting communities program.

In regards to HIMSS, the HIMSS RHIO Federation fosters the RHIO and HEI
industries’ development through education, outreach, networking tools,
resources and advocacy activities at the local, state and national federal
level. The HIMSS-RHIO Federation has grown to 58 member organizations across
the U.S., Puerto Rico, and in Israel.

Tracking activity and the evolving world of HIE and HIT is a focus of both
eHI and HIMSS. I apologize for the acronym soup, but hopefully you are keeping
it all straight. For example, the HIE Dashboard, available at
www.hitdashboard.org, is the result of a collaborative effort between HIMSS and
the Center for Health Information and Decision Systems at the Robert H. Smith
School of Business, University of Maryland. It provides a color-coded, easy to
read visual interface, as you can see here on the screen, that attracts over
500 state, federal and private HIT initiatives.

Another tracking effort is an eHI Foundation’s survey of state, regional
and community based HIE efforts conducted annually since 2004. This survey
serves as a yearly report card on the current state of activities related to
interoperability and HIE across the U.S. Results show that a number of new HIEs
have emerged, and in general such efforts have matured considerably with
respect to engagement of key stakeholders, organization and governance, the
range of functionality provided, and the technical aspects of health
information exchange.

Some common challenges cited by HIE initiatives surveyed included standards
interoperability and mobilizing information electronically across the health
care system. Not surprisingly, these are similar to the challenges inherent in
developing an NHIN.

In regard to the states, the e-Health initiative has supported 21 states
across the country, 15 directly, and six through its work supporting the AHRQ
national resource center. State and regional demonstration programs, by helping
state leaders engage stakeholders, conduct needs assessments and develop plans
or road maps for mobilizing information in their states to improve health and
health care.

Research compiled in the new eHI report I will refer you to, states getting
connected, driving health IT planning in a majority of the states in the U.S.
reveals that about half of the states in the U.S. have either an executive
order or a legislative mandate in place, that is designed to stimulate the use
of HIT to improve health and health care. Most states are convening or
participating in multi-stakeholder groups, and increasingly states are
providing grants funds to support not only regional and local HIE efforts, but
also the development of plans.

A tangible set of tools is available in the public domain to address health
information exchange profiles created by IHE, at www.ihe.net, the integrating
health care initiative already referred to. A multi-year global initiative that
because of its proven process of collaboration, demonstration and real-world
implementation of interoperable solutions, IHE therefore is in a unique
position to significantly accelerate the process for defining, testing and
implementing the standards-based interoperability that is necessary for a
Nationwide Health Information Network.

Privacy, security and identity considerations have already been discussed
many times this morning. Keeping health information private and secure while
insuring appropriate access is essential to consumer trust and the success of
both HIEs and the NHIN. The contract work conducted within the Department of
Health and Human Services and the Office of the National Coordinator related to
privacy and security, standards harmonization, certification and architecture
all produce enormous learnings in this area, and will help pave the way for
improvements.

However, experiences in the field reveal the need for policies, tools and
frameworks for insuring that data is not only secure, but also that appropriate
privacy and confidentiality safeguards are in place, as well as communications
tools to effectively communicate with consumers regarding how these issues are
being handled.

When communities begin to implement privacy and security measures, they
often look to their peers and industry colleagues for guidance and assistance.
Our experience has been that members of the connecting communities and RHIO
Federation find value in information sharing amongst their groups. The
networking and relationship building leads to experienced sharing that is
trusted and effective.

Now to our recommendations. Recommendations on core functions for initial
rollout of the NHIN in the form of HIEs and RHIOs.

NCVHS requested that we address in our testimony recommendations on the
core functions appropriate for the initial rollout of the Nationwide Health
Information Network within the NCVHS draft NHIN conceptual framework and
standards to implement the core requirements as seen through the lenses of HIEs
and RHIOs. I will outline these joint recommendations now from both eHI and
HIMSS for you.

We believe that the initial rollout of the NHIN should set a minimal level
of standards for secure health care transactions over the Internet, and a
minimal set of services to support these transactions, leaving the NHIN open to
evolution over time in much the same way as the ARPA Net establish the
evolution of the Internet and the World Wide Web ultimately.

The proposed NHIN functional categories can be prioritized under this
philosophy into three categories. These are essential functions that must be
established before early adopter health information exchange initiatives can
take advantage of them, those early value functions that make it easier for HIE
initiatives to take advantage of the network, and those nice to have functions
that would provide extended functionality on the network.

At a minimum, all message centers and receivers must be authorized and
authenticated, and all messages must be signed and encrypted. These
characteristics require the following functionality above and beyond the basic
connectivity of the Internet.

Security. The word security implies a world of policies, procedure and
technology that must act together and in concert to accomplish a simple goal,
to be sure that information is used and disclosed only by appropriate people
and for purposes that are authorized. For this initial rollout of the NHIN
however, this concept can be reduced to the security features that must be
overlaid onto the Internet to provide confidential communications between and
among known participants in the NHIN, identity, authentication, electronic
signature, encryption and authorization are the cardinal features.

Nationally accepted standards for these functions must be implemented by
all who wish to communicate over the NHIN. There are several standards,
approaches and technologies available today for each of these functions.

HITSP, the Health Information Technology Standards Panel, has established
an initial process for resolving gaps and overlaps in the HIT standards
landscape, as you well know. In June 2006 with the involvement of nearly 200
stakeholder organizations, HITSP reduced 570 candidate standards to 90
appropriate standards for secure exchange of medication, lab and demographic
data.

No later than by September 29 of this year, HITSP will deliver unambiguous
interoperability specifications, God willing, which will enable secure exchange
of medication, lab and demographic data. These specifications will enable
vendors, hospitals and the government to create software components for
clinical data exchange, HITSP’s attempt to bring the consensus of industry as a
result of significant directed activity by the federal government.

We believe that the NHIN functional categories of confidentiality,
identity, authentication and authorization should be given the highest
priority, with the understanding that the standards for electronically signing
to assured non-repudiation, for example, and encryption to preserve
confidentiality of information, are essential components of the secure
infrastructures that must result.

In addition, these standards and technologies to support security,
agreement is required between the participants and the NHIN on basic
principles, policies and procedures to maintain confidentiality of the
information that is being exchanged. I’m not sure if those were part of the P
set of words that are excluded today, but it must be mentioned again. These are
well described in the Connecting for Health framework documents referred to
earlier.

At the early value priority level, having standards for some simple high
value potential use cases of health information exchange would be very useful.
These cover the functional categories of data content, data retrieval or pull,
data transmission or push, identity, information correlation and record
location. The Connecting for Health common framework also sets standards for an
initial set of such functionality.

Such standards are also being refined and tested through the work of the
HITSP and the NHIN prototypes we have heard so much about already, funded by
the Office of the National Coordinator. Development of these standards will
lead to many benefits, including identification and effective implementation of
minimum data sets shared across organizations representing patient clinical,
demographic and payor information.

Universal identification and implementation of these standard data sets can
support solving many health care delivery issues experienced today that arise
from the lack of quality and consistent patient data exchange across
organizations. The ability to exchange good solid information across all RHIO
and HIE stakeholders including providers, patients, payors and employers, will
lead to successful integration with the NHIN and achieve the value I described
earlier.

In addition, existing technology tools can be more effectively used, such
as with enterprise patient indexing, which is a critical tool to manage
specific patient records within organizations, as well as facilitate effective
use of record locator standards at other organizational levels.

In short, these efforts build the foundation for a consistent and standard
technical environment, supporting all the key stakeholders, including patients,
providers and payors as well as the NHIN. We consider the remaining NHIN
functional categories to be nice to have, and expect them to be given a lower
priority. If these recommendations are followed, the NHIN can truly fulfill its
goal of fostering widely available services that facilitate the accurate,
appropriate and timely and secure exchange of health information.

I close our recommendations with the important observation that the success
of HIEs and RHIOs across America is of course not based on successful technical
and information sharing practices alone, but instead on a complex interplay of
organizational, legal, governance, funding, sociocultural and workforce change
issues. Underlying all this must be informed public policy approaches that
support and incent care system transformation and information exchange, as well
as further stimulate market mechanisms that support HIT adoption. I will just
reiterate, the prepared written testimony goes into some of our recommendations
in this area in more detail.

While standards are a fundamental requirement, addressing these associated
policies and issues are essential for the future success of RHIOs and HIEs, as
well as subsequent integration with the NHIN.

In conclusion then, I would like to thank the NCVHS for providing me the
opportunity to share my insights and expertise as well as, more importantly,
those of eHI and HIMSS today. There is a long road ahead, but it must be filled
with the promise of better health for all Americans in their own communities if
we work together and get it right. Nothing could be more important, and HIMSS
and eHI will be there to help every step of the way.

Thank you.

DR. COHN: Blackford, thank you very much. We will have discussion and
questions after we have heard from Jan and Jac. Our next presenter is Jac
Davies. Thank you for being available.

DR. DAVIES: Thank you very much for accepting my testimony by phone call.
It certainly saves me a very, very long trip. I do want to ask if you have the
slides there to view that I sent in? It’s not critical, but I just wanted to
check.

MR. BLAIR: There should be a handout.

DR. DAVIES: Okay, that’s fine. I’ll just let you know when I am moving on
to the next page.

DR. COHN: We are in the process of getting it here.

DR. DAVIES: Let me go ahead and get started with my introductory remarks.

Good afternoon, and thanks again for the opportunity to address the
committee. I am Jac Davies. I am Director of Program Development for Inland
Northwest Health Services, but I am going to be speaking this afternoon on the
functional requirements for the NHIN from the perspective of a functioning
RHIO.

Inland Northwest Health Services or INHS provides the technical
infrastructure and support of the Northwest Regional Health Information
Organization, which is a collaboration of health care organizations and
providers in Eastern Washington and Northern Idaho. IHS has connected 34
primarily independent hospitals in the region to a common information system,
and makes data from that system available electronically to clinicians around
the region. IHS has also collaborated with area imaging centers and
laboratories to bring those data into the system as well, all unified by a
common master patient index, so that physicians can access comprehensive
patient information from a single source. Physicians view the data via a web
portal, or if they have an electronic medical records system, they can receive
the data via HL7 messaging.

Do you have the slides up now?

DR. COHN: Yes, and we are on general principles.

DR. DAVIES: Good. Before I start in with the specific functions, I would
like to review some of the general principles that INHS and its partners here
in our region would like to see incorporated into the development of the NHIN.

Most important, the NHIN must recognize that health care is local.
Consequently, the vast majority of health information exchange occurs at the
local level. All technology activities that tend to facilitate health
information exchange must have local health information exchange as their
priority.

The regions served by INHS, like many other communities in the country, is
well ahead of the national health information exchange activities. We have
already established an extensive infrastructure to support the exchange, and
are moving ahead rapidly to fill in gaps. Because of this, we believe that the
NHIN should be derived from and developed in concert with these local efforts.
While it is appropriate to develop national solutions that also work well for
local levels, the emphasis has to be on local functionality.

We would also like to point out, and I’m sure that this is not something
that isn’t news to you, the health information exchange is useless unless
health care providers have electronic medical record systems. It is critical
for the NHIN at the local level and RHIOs at the local level to provide
guidance and support to clinicians in their purchase and implementation of EMR
systems.

Because of our focus on health information exchange at the local level, we
believe that the primary roles for the NHIN are related to the development of
policies, adoption of standards and education of the public. The policies
developed by the NHIN should relate to the overall processes adopted for health
information exchange, including policies to define and certify regional health
information exchanges. We also see roles for the NHIN in establishing the
common data standards and information exchange standards that should be
incorporated into all of new health information technology systems. Finally, we
believe that the NHIN has a very important role in educating the public, so
that there are common messages across the country around health information
technology and information exchange, and why they are so important to the
future of the health care system.

Focusing specifically on the technical functionality, we see the technical
functions related to health information exchange as being distributed across
three different levels of both infrastructure and responsibility. The majority
of the technical functions are most appropriately handled at the organizational
level, whether it is a physician office, a hospital, or a large clinic system.

Some functions related to health information exchange are going to best be
handled at the regional or the community health information exchange level.
Only a few technical functions we see as being appropriate or necessary at the
NHIN level.

At the organization level, we see most of the functions that you have
defined in your NHIN technical framework occurring. These build on the
organization’s historic and current responsibilities and capabilities.
Organizations are in the best position to manage any approvals for the use of
their information or resources. This includes authorization for access to
information.

Credentialing has historically been handled by individual organizations or
community groups such as county medical societies. There are sound reasons for
making the credentialling process less localized, such as giving health care
providers the ability to practice in other communities in case of emergencies.
However, that should not be an NHIN function. Tracking of the health care
provider’s credentialing status may best be handled at a state level in
conjunction with professional licensure programs. Again, it doesn’t seem to be
an NHIN function.

Health care organizations have historically been responsible for managing
their patient’s health care data and access to that data, including content,
usage and storage. There is no reason that they should not continue to have
that responsibility. Information systems intended for these types of
organizations should include the capability to carry out all these management
functions, incorporating national standards as necessary. Individual
organizations or groups of organizations may contract out these activities, or
may choose to participate in a collaboration similar to NHIN, but absent a
national health care data repository, it would not be appropriate to make these
a function of the NHIN.

As I mentioned at the beginning, the vast majority of health care
information exchange is local, and therefore it is logical to manage the
technical aspects associated with health information exchange at a community
based, RHIO or similar organization. This includes auditing and logging health
information exchange activities and the technical activities associated with
the actual data exchange.

A central body to retrieve or push the data, and that really depends on the
technical model that has been chosen by the community, to manage the
translation and routing of information is the most efficient mechanism for
health information exchange. Having these functions controlled at the community
level also increases the opportunities for the consumers and the providers in
the community to have control over and input into the processes and outcomes.

So what is left should be a technical function for the NHIN, in addition to
the quality functions that I outlined earlier. A national record locator
service to help identify where patient records reside would certainly help when
a patient needs to receive care away from his or her home community. While this
can and should be a national function, some level of record location service
will also be need to be established at the community or regional level if the
community has not adopted a centralized database model for their health
records. It also makes sense for the NHIN to serve as a place to access data
from national data sources such as laboratories. This would save RHIOs and also
the national business themselves time and money. The RHIOs would have a single
source to approach for protecting this information, and the national businesses
would not have to develop multiple connections.

While there are detailed technical functions that should be managed at each
level, there are some functions that cut across all levels, and so require
shared responsibility and potentially shared technologies. Authentication of
individuals trying to access health information needs to occur, whether it is
the physician trying to get patient data in the physician’s clinic, or whether
the physician is contacting a hospital across the country. Ideally, the
authentication process should be standardized or at least standards will be set
to allow one institution to accept another’s authentication process.

Confidentiality is the responsibility of any organization that is handling
personal health information. That includes organizations that provide the
record location service, as the location of a patient’s health information can
provide clues as to that patient’s health status and history.

Data quality is primarily the responsibility of the organization that
manages the data. However, because data quality can be affected by data
transmission, all organizations involved in the data exchange must have
processes in place to avoid data corruption.

Finally and probably most importantly of all the functions I have
discussed, correct identification of patients is critical. It has to occur at
all levels. We here in our communities believe that the best solution to this
problem is the unique national patient identifier. But whether or not there is
a unique identifier, all organizations involved in sharing a patient’s health
information have a responsibility to assure accurate identification of that
patient. Ideally, all levels will use common approaches to identification,
simplifying the process and decreasing the chances of incorrect matches.

In summary, I again want to reiterate that the majority of the
functionalities related to the exchange of health information should reside at
either the organizational or the RHIO or HIE level. This provides a solid
foundation for the NHIN from which to provide direction and guidance while
maintaining a minimal technical role.

With that, I am prepared to take any questions and participate in any
discussion of the group.

DR. COHN: Thank you very much. We are going to hold questions until Jan has
had a chance to testify also. Then we will have questions and discussion.

Jan, are you there?

DR. ROOT: I am here.

DR. COHN: Thank you. We have written testimony. Do we also have PowerPoints
from you?

DR. ROOT: No PowerPoints, I’m sorry. I apologize. We are in the middle of
implementing a pilot and things are really, really busy here.

DR. COHN: In that case, we want to thank you for giving us some written
testimony. Please go forward.

DR. ROOT: Thank you for the opportunity to contribute to this dialogue.

I am Dr. Jan Root. I am the Assistant Executive Director of the Utah Health
Information Network. We are probably better known as UHIN.

UHIN wants to thank NCVHS for the opportunity to give testimony on this
important topic. Just briefly, for those of you that aren’t familiar with us,
UHIN began as a community Health Information Network in 1993. UHIN’s primary
mission is to reduce the cost of health care and improve the quality of care
through the exchange of standardized messages.

Currently we are a coalition. On our board there are 19 health care
entities, many of whom are competitors with each other. We have been self
sustaining since our inception, and are currently handling about 60 million
messages annually, and we connect to about 2,000 different health care
entities.

For the purposes of this testimony, we wanted to step a little bit outside
of the questions that you asked us to address in order to get to the questions
that you asked us to address. So I would like to, if you will allow me, to
digress slightly, and to talk first about the definition of a RHIO.

I think most people would agree that there is no widely accepted definition
of a RHIO, Regional Health Information Organization. So for the purposes of
this testimony, we would like to propose a definition. Our proposed definition
is that a RHIO is a community-centric, nonprofit company that exchanges
standardized secure electronic messages between various information silos as
represented by its members.

Hence, organizations that are more educational in nature, some of which I
have seen called a RHIO, we would suggest that these are not actually RHIOs.
They are very important, but in our view a RHIO is an IT company that runs a
network.

There has also been a lot of discussions about whether national
organizations such as the VA or Labcorps or Quest or HCA are RHIOs. Again, for
the purposes of this discussion, UHIN would propose that they are not
themselves RHIOs. However, we believe it is in their best interest to
participate with RHIOs. All of these national entities have a need to connect
with very local and sometimes very small health care entities scattered across
the country. If RHIOs could be created, these national entities could reduce
their connectivity costs by simply connecting to the RHIO and then allowing the
RHIO to connect to the local entity.

So we believe that although we would not consider big national companies to
be RHIOs, that it is in their best interest to participate with RHIOs.

To get to your first question, what are the minimum but essential network
functions for the initial rollout of an NHIN, again, I know that this question
is focused upon functional requirements. But we believe that there is a really
important question about the NHIN that we don’t believe has been addressed,
that is, what is its core sustainable business function.

We believe that the RHIO and the NHIN, that their sustainable business
function is to act as a means to securely exchange standardized messages for
very low cost across these very independent data silos within whatever their
defined market area is.

RHIOs and the NHIN may elect to perform additional services, but we believe
that exchanging message is the core sustainable commodity that RHIOs and NHINs
can offer.

What we envision the NHIN to be is not actually any kind of stand-alone
network run by an independent company. We believe this similarly to have — the
Internet is not run by any one company. Instead, we see the NHIN really as
being a coalition of RHIOs. We envision that the NHIN itself, similar to the
Internet, is a collection of standards that allows data interchange between
RHIOs.

So the four areas that we believe that standards need to exist in are, one,
message formats and codes for exchanging those messages between RHIOs,
communication protocols, privacy and security policies, including the
authentication of end points and users in the RHIO, and then finally, some kind
of standard RHIO to RHIO business associate agreement.

Essentially what these all boil down to is interoperability standards. When
we look at the business case for the NHIN, we don’t think this question has
been answered yes, what is a viable business case for the NHIN, because the
business case will determine the architecture, and that will eventually get us
to answering your very important questions.

So our first question is, what business need does the NHIN meet, so who is
going to want to exchange messages at a national level, what messages will they
want to exchange, what is the volume of the messages they want to exchange, and
finally, what value does such an exchange bring to the RHIOs and their users.

I think Jac mentioned this, that we see that the primary traffic for
information exchange is local. This little map I put on your handout is an
attempt to illustrate this from Utah’s perspective. It is supposed to be right
over Utah, I don’t know how good I hit it or not, but the basic idea here, what
we are finding is that most of the traffic here is within the state, but we do
have a need outside of the state, for example, Colorado and Wyoming have
already approached us.

We already know we are going to need to exchange information with RHIOs
that develop in our neighboring states. We believe that there will be enough
traffic in those exchanges to create a sustainable business model.

However, as you get outside of the local, the regional area, contiguous
states, contiguous market areas, we believe that what we will find is that the
traffic will decline. It is not to say that it is nonexistent. Utah is a big
tourist state. We have people that come here from all over the world who
unfortunately occasionally need health care. But what we are not sure is
whether there will be enough volume in that exchange to create a viable
business model to send data to Vermont or Georgia or someplace like that, and
that is a question that needs to be answered.

The other big issue that we see about the NHIN is one of the core
functionalities that has been proposed by several groups, this whole concept of
a record location service, which I understand has not been conclusively
identified as to exactly what it is. But for the purposes of this discussion,
what we envision it as being is a way to discover information about a patient
from some remote site.

Again, we are not entirely sure that this is a sustainable business
commodity. There is no question that it could bring some improvement of health
care if you could address some of the very challenging technical issues that
are involved in it. But ultimately for us, the question is, the exchange of
information needs to work to drive down the cost of health care and not
increase the cost of health care, that if we do something that increases the
cost of health care, the chances of it being adopted are quite remote.

So again, what we are thinking about is for a sustainable business model
for the NHIN, because this is going to drive the architecture, that you do
something quite prosaic, you just deliver documents electronically, standard
documents.

This is the pilot that we are involved in running right now. The excitement
about this pilot is a little overwhelming, actually. Just to get rid of the
paper, for example, we have a paperless multi-specialty clinic here in Utah
that runs an AllScript system. They have somewhere in the neighborhood of 60
physicians in this corporation. As a paperless clinic, they still have to
handle over 4,000 paper documents every day that come in, that they then need
to scan, place in their electronic medical record system, and then shred the
remaining paper.

Several of our hospitals receive tens of thousands of paper documents per
day. We believe that there is a huge business need to be met here, simply to
get rid of the paper. It is our hope that in meeting this business need, we
then develop a platform can then extend out to some of the other needs where
the actual return on investment may be a little more tenuous, or may inure to
another entity besides the one that actually exchanges the data such as the
payor for an improvement in quality of care.

So our proposal is that toward the NHIN, we believe the NHIN is a set of
standards that are adopted by its members, and the members of the NHIN are the
RHIOs, the users of the NHIN.

The minimal but essential network functional requirements for the initial
rollout, we think of the initial functional requirements would be to convene
the members of the NHIN, and to begin a process of creating an NHIN
association, an NHIN group that will adopt these standards.

We understand that this is a little contrary to some of the strategies that
have been currently adopted by HHS, but we believe in the NHIN. We believe it
is an important function that the United States can aspire to. So in light of
that, we are offering our best suggestions for this.

Your question two for specific edge systems or entities that would be
essential for linking to the network. The ideogram that was presented in the
PowerPoint in our mind represents a RHIO. It is the RHIO’s job to connect the
various entities. As I think Jac mentioned, we strongly concur that local
communities are in the very best position for understanding what those
connectivity needs are, for creating privacy and security policies and
procedures that best fit that community, and for developing services that best
fit the needs of that community.

So in our vision, the edge systems for the NHIN are the RHIOs, not public
health or laboratories or things like that. The edge systems really are the
RHIOs.

As we explained in your first question, the minimum but essential functions
for linking RHIOs encompass an adoption of a set of standards around four
areas, message formats and codes, communication, privacy and security policies
and then some kind of standard RHIO to RHIO to NHIN business associate
agreement and contract.

I tend to be a little — if you ask me to do something, I tend to do
exactly what you ask me to do, so you have these lists of different categories
about what would be an essential function. Basically, what I did is, I took
your categories and organized them according to the four areas that we believe
need to be addressed to move an NHIN forward.

The first one is message formats and codes, the data content, the choice of
messages; how is the NHIN going to actually transmit, in other words, where is
the largest business need. Is it lab results, is it credentialing information,
is it claims, is it discharge summaries? What is it? That needs to be decided
again based on need.

The data source under these message formats is obviously going to depend on
what kind of messages and what kind of services are offered, what is the
exchange that the NHIN is going to support. So that is again something that we
needs to be, we believe, driven by the business needs that the NHIN is proposed
to answer.

Communications we believe is absolutely essential. You can have a network
without communication, so you would need data routing, audit logging,
authentication, authorization, data transmission. Whether it is push or pull is
probably going to depend again upon the kind of services that the NHIN offers.

In addition, we would add encryption standards, some kind of encryption
standards need to be worked out, performance monitoring, and security
monitoring will be critical to the communication portion.

The privacy and security. As you can see, some of these topics are
mentioned in both item two and item three. In item two there is a technical
part to it, but then in item three, there is a political social aspect to it.
Different communities are probably going to be comfortable with different kinds
of confidentiality, and somehow that needs to — confidentiality policies and
procedures, and somehow that needs to all be brought to a common not only
technical standard, but something of a social standard within the NHIN between
the RHIOs. I’m not quite sure how to do that, but I know that it is very
important. Something we would add to your list is a RHIO to RHIO business
associate agreement or an NHIN contract.

The other things that were listed, we believe are things that will vary,
depending upon whatever the sustainable business case for the NHIN comes to be.
Several RHIOs may offer something like a record location service or an ability
to aggregate data into a central database. Other RHIOs may not be comfortable
with offering those services. So we believe that these other things that I have
listed under variable are going to be driven over time. They are going to be
driven by what people are going to be willing to pay for, and we don’t have an
answer to that.

You asked about HITSP and the standards that are being developed. We have a
list here of the HITSP standards, as far as we could determine that they are
developing right now, that we believe could be used by a RHIO, could be used by
an NHIN.

The HL7 messages, I have listed those there, NCPDP, I have listed those,
X12, ASTM. We believe that there are some standards that are missing. For
example, the NCPDP formulary and benefit standard, we believe that should be
part of this.

There is a missing piece inside of HIPAA which I believe is going to be
addressed, which is the 277 front end claim acknowledgement. We believe that
there needs to be a standard there.

Error handling inside of X12, HL7 and NCPDP desperately needs to be
standardized. This was omitted in HIPAA, and it has caused a lot of problems as
a result. We are really hoping somebody comes up with a standard for error
handling in these three different standards. If the CCR were to be adopted
under ASTM messaging standards, then we would hope that there would be some
error handling standards there as well.

There are XML messages that we believe provider enrollment or
credentialing, data exchange, things like that, that are being developed now.
We would hope for some HL7 message documents standards, history and physicals,
op notes, progress notes, et cetera.

One of the areas that we find the most interest in exchanging are what we
are calling render — PDF, TIF, those things. Utah has a fairly high rate of
EMR penetration amongst our providers, but even here, at most it is somewhere
in the neighborhood of 25 percent of our physicians have access to an EMR. So
that leaves me with 75 percent that don’t.

However, anybody can create a PDF, that is very low cost. I realize that
there are disadvantages to using PDF, but again if our goal is to help reduce
the cost of health care by basically moving away from a lot of very expensive
manual processes, by allowing PDFs to be exchanged, you could inch the whole
industry forward, moving them away from phone fax, sneaker mail, et cetera,
into at least getting these documents exchanged electronically.

As I mentioned earlier, those services are in Utah apparently in high
demand from our most advanced trading partners, the hospitals and the paperless
clinics. They are very, very interested in getting rid of all that paper. If
that means PDF, they are fine.

Password standards are another thing that would be extremely useful, user
authentication standards, encryption standards.

A couple of notes about the things that HITSP is doing. We have found that
if you shoot too high at the beginning, things like CDA, HL7 version three, we
don’t get adoption. So our suggestion is that HITSP and other standards
adoption processes consider what is being done on the ground right now, start
there and then move forward, bring the whole industry along, but at least get
them on the bandwagon to begin with.

The other note that we have is that currently when you listen to these
discussions, or when I listen to these discussions about the NHIN and RHIOs,
there is often an attempt to bifurcate and set aside administrative exchanges
and clinical exchanges and talk about them as if they are two separate things.

It is our experience here, and our pilot is beginning to support this, that
they are actually not two separate things, particularly when you look at them
from the perspective of a provider. If you take a lab result, the lab result
can be used in a clinical setting to inform the treatment of a patient. The
identical lab result can also be used as a claim attachment, so that identical
transaction moves into the administrative arena. The same lab result may even
be used as a public health report.

What we are proposing, and what we are testing here in our pilot is a
concept that if a provider needs to share a lab result with somebody, they
should be able to share it using the identical format to the greatest extent
possible, regardless of who is going to get it. One of the things that we are
testing is sending HL7 or PDF as claim attachments, as prior auth attachments,
as public health reports, as well as using those messages for clinical
exchanges. So we would like to make that point as something to consider when
people are bringing up standards.

That concludes our testimony. I want to thank you again for this
opportunity, and I would be very happy to answer any questions.

DR. COHN: Jan, thank you very much. The floor is open for questions or
comments.

MR. REYNOLDS: Thanks to all of you. I especially like the chart that shows
Utah as the center of the universe. Stan has reminded us of that regularly. We
hadn’t actually seen it in writing.

As we heard the presentations, there are a lot of RHIOs out there, but not
everywhere is there a RHIO. As we look at this functionality, if you go by the
premise that it is the RHIO, then you are starting from the fact that those
organizations exist and they are viable, and they have viable business
positions, too. In some of the states that we are in, they don’t necessarily
have that same position as they do in all the states.

I would still like to hear from each of you a little bit about how this
works if it is not RHIO based. You have broken it into three types of entities,
and there is a difference between the architecture, and you set up kind of a
business model. So if there is anything you would say different based on the
fact that it would not be RHIO based, I would be interested to hear any
comments that you had on that.

DR. MIDDLETON: I’ll take a crack at it. In the Partners health care system,
in many ways we are an NHIN in situ. What I mean by that is, it is a large
multi-facility, multi-clinic, multi-provider integrated delivery network that
has tackled many of these information exchange problems within its own borders.

When you have that organizational context within which to work, it is not
an NHIN obviously, and the standards applications, the common standards
architecture and infrastructure is the usual stuff, HL7, ICDs, CPT, other
coding standards and architecture software standards and whatnot. We now are
shipping huge amounts of data around the place very effectively.

To the point though about the absent NHIN, or even in Jan’s point, absent a
business case, oftentimes I like to make the following observation. If I was to
ship a patient from the Brigham and Women’s Hospital across the street to the
Brigham, the patient has to carry a paper-based record from one very
sophisticated clinical information system to another. Nevertheless, the patient
has to carry a paper-based record, because as the CEO of Partners Health Care,
Jim Mongan, likes to say — or has said, I’m not sure he likes to say it, but
he has said there is no contribution to margin to exchange that information.

So absent a financial reason or a business case to ship that information,
there are many disincentives in place against shipping that information, and
despite that we have the technology infrastructure well in place to do that
kind of connectivity, we simply don’t do it. So absent the NHIN, it is not
happening.

DR. DAVIES: I think Jan illustrated quite well that there is a business
case for removing the paper trail from between competing organizations in a
community. The business case is on both sides, both the sender and the
recipient of the information. That is the thing that we have seen, similar to
what they are seeing in Utah, that we have seen here in our region.

As we reviewed the questions and as we reviewed the functional requirements
for the NHIN, I have to admit, our reaction here was feeling a bit of concern
that the NHIN is moving rapidly in a direction of being unsupportable and
unrealistic.

I think that rather than putting so much effort at the NHIN at the national
level, your question was, what happens when there aren’t RHIOs. Rather than
creating an NHIN because RHIOs don’t exist, I think the emphasis should go on
creation of the RHIOs, because the RHIOs are built upon the referral patterns
and built on the community relationships that already exist, and they are built
upon recognized business need, as Jan emphasized, in the community.

I think that beyond this initial infusion of federal money, if you don’t
build that kind of sustainability into the model, it will not continue.

DR. ROOT: The alternative to RHIOs, because I concur with what Jac has said
— plus I have to tell you, we only got about one word in ten of what you said,
so I may not have picked up everything you said — but what we have found is
that it really is driven by the business need. I am very aware that there are
communities that do not have RHIOs, and may even not have any plans to have
RHIOs.

The alternative, assuming that the business need exists, the alternative to
a RHIO, to an NHIN, already exists. These are the for-profit clearinghouses
that are currently used by many providers and payors to ship claims and
remittance devices. Those clearinghouses very wisely are beginning to position
themselves to carry other kinds of transactions such as clinical transactions.

My sense is that communities are going to make a decision. They will either
be able to get it together to make a RHIO, which is not an easy thing to do, it
is a very difficult thing to do, or they will for a variety of reasons either
decide to do that or simply not do it. But if the business need still exists,
that business need will be met through the large for-profit clearinghouses.

So I would concur with what Jac said. I hope that we could begin to
emphasize the development of RHIOs so that you can employ these not-for-profit
models that can reduce the cost of exchanging this information dramatically,
and allow communities to keep that in mind.

If at the federal level there was a sense that there was a large number of
communities that couldn’t put RHIOs together but you still wanted all these
folks on an NHIN, it certainly is possible to make a default RHIO that anybody
could join if they wanted to. It doesn’t really matter where the RHIO is. This
is Internet based stuff. It is better if the community controls it. I think it
is much more economically viable, but it is not required.

So there are some gray zones here that could be considered.

DR. COHN: Blackford, I think you had a comment.

DR. MIDDLETON: Just a quick followup to supplement the comment about
Partners as the NHIN in situ. We do have a proto NHIN in the form of NEHIN, the
New England EDI Network that some of you may be familiar with. Absent any NHIN
initiatives, this began in 1988 approximately in response to Kennedy-Kassebaum
and HIPAA regulations and whatnot, and serves only the purpose of
administrative claims transaction.

So it really is not NHIN in the sense that it does not have a lot of
clinical detail, but it does route two million transactions now per month. The
business case here was very simple, that there was need for these
administrative claims transactions to occur, and the savings have been received
locally by each participant at relatively low cost, for example, Partners
Health Care cost per administrative claims transaction management has gone from
approximately $15 to 15 cents.

DR. COHN: Well said. Jeff, you have a question, and then Mary Jo.

MR. BLAIR: Thank you. Blackford, one of the requirements that you listed
was non-repudiation. I was wondering if you could — the testimony we had this
morning, no one listed that. You are representing Connecting for Health and
HIMSS and Partners; they are all impressive organizations. Is this the
consensus of all of those groups? Could you tell us a little bit more about why
you feel that that is an essential minimum core requirement?

DR. MIDDLETON: Yes. Jeff, it is the consensus of opinion, as represented by
the testimony, so I will put that there for the eHI and HIMSS, who I am
representing today.

The issue of non-repudiation though I think goes directly to many of the
issues talked about this morning, where I heard of the demonstration project
presentations and that Q&A. If you think about critical functional
categories of authorization and authentication, encryption, non-repudiation is
the underlying conceptual information management principle for making sure that
the data is what it is and who sent it, is agreeing that what you receive is
what it is, this principle, whether it is implemented through a PKI, public key
infrastructure, or other mechanisms I think is an absolutely critical
requirement.

With respect to health care information, you cannot repudiate what the
information is. The receiver cannot repudiate what the sender has sent at some
level to insure the integrity of that clinical message.

MR. BLAIR: Thank you.

DR. COHN: Can I ask a followup on that one, just to make sure that I
understand? When I hear non-repudiation, I think of PKI and other sorts of
security requirements. So you are postulating that any use would require that
sort of infrastructure as an underlying piece. I just wanted to make sure that
I am hearing that correctly.

DR. MIDDLETON: I don’t think the testimony calls for PKI per se, but it
does identify the principle of non-repudiation as a requirement.

MR. REYNOLDS: Just a followup. Does that then preclude the ability of
clearinghouses and others to translate data once it is passed on?

DR. MIDDLETON: I don’t think it does. It does not preclude them, because it
might happen as was discussed this morning, on a server to server
authentication basis.

DR. DEERING: Thank you very much. I really appreciate this testimony,
especially the people who chimed in over the phone. Thank you, it is a little
bit hard to be remote sometimes.

This morning an issue was raised about the role of the consumer, not a
patient in this. I guess what I would like to raise, especially for Jan and Jac
who spoke so fervently about RHIOs, your RHIOs are institutionally based,
institutionally oriented. You serve the business needs of your institutions.

I have a two-sided question. At the highest level, the question is simply,
what is the role of untethered personal health records in your model and
specifically any functional requirements there, pointing out specifically that
untethered PHRs are not regionally based.

So I wonder how you would accommodate consumers who wished to participate
in the NHIN, not through a tethered PHR or linkage, but through some more
independent third party approach.

DR. DAVIES: We are looking now at the technical models that will allow us
to upload data from a consumer’s PHR into a clinic’s medical record system and
vice versa, download data from the EMR into the PHR.

Fortunately, the physicians in this community have agreed upon a fairly
short list of EMR products, so technically it is easier to do. From a policy
standpoint, we do have consumers participating in the discussion process and
the decision making process, because they serve on the boards of our various
organizations. I believe that we do need to do a better job of getting consumer
input, not just from a patient perspective, but from a member of a wired
community perspective. That is something that is on our agenda for the coming
year.

DR. ROOT: We are at a very similar role to where Jac’s organization is. We
are looking at how UHIN could accommodate PHRs, given our current model. We
don’t have an answer for that yet. We do have a consumer advisory board that is
working with us on issues like this, although right now they are actually more
concerned with privacy and security issues. We hope to be able to connect to a
PHR basically the same way you would connect to any other data source, in the
sense that they are just another data source.

So again, depending on what our community decides they want to create as a
product for the community, that is going to impact our ultimate answer to how
we interact with PHRs.

DR. MIDDLETON: I have a quick followup on Mary Jo. It is a great question.
This issue of the PHR tethered versus untethered of course has implications for
where and how authorization and authentication is managed.

In the tethered world of PHRs that are basically a derivative of an EMR, I
think the onus and responsibility lies with the users of the EMR, just as they
authenticate and authorize their provider users and perhaps other
administrative users as we do in our system with our home-grown EMR and our
PHR; we authenticate and authorize users of the patient gateway.

The other key player though here might be another purveyor of PHRs or
perhaps not the vendor necessarily, for example, the payor community. I would
suggest that the same onus would lie with the payor community to authenticate
and authorize users of PHRS which might be then source systems for clinical
data.

The last issue about the PHR though is, just like I can’t update my bank
account balance from Quicken and have the bank necessarily accept it, I would
suggest that those data that arise from PHRs or the home, workplace or other
clinical context environments, if you will, or other sources of data, require a
second issue to be addressed.

That is, at some level a clinical attestation to the viability or
correctness of those data before they are entered into the clinical record or
made available in an edge server to the NHIN. What we do for example in our own
tethered PHR in our environment is, the patient may make suggestions about
changes or edits to the problem list, med list, allergies, et cetera, advance
directives, and even submit clinical data, but it is always reviewed by a
clinician before it is viewed as correct and appropriate for inclusion then in
the EMR record.

DR. COHN: Jeff, I am going to let you take the last question, and then we
will take a brief break.

MR. BLAIR: We are fortunate that we have some testifiers here that are
working across — not across networks, that have multiple networks. Inland has
a health information exchange, but they also have a telehealth network, and
Utah started with a HIPAA transaction network, and is now beginning to look at
sharing clinical data.

My question to both of you is, when I look at the way telehealth and health
information exchange networks are developed, they appear to have different
architectural appearances. When I have looked at the way health information
exchange with record location services or architecture, they appear to be
rather different than when health claims are being shared with HIPAA
transactions. The basic network constructs are different.

So Jan, I think you said that you think that these can be converted. Jac,
you didn’t mention the telehealth network, but are you doing anything to
integrate them? And if you are, how do you do that?

DR. DAVIES: There is common types essentially for running the telehealth
and the information network. Other than that, they are not integrated
technologically. We are doing quite a bit to leverage the two systems to
deliver services, particularly in the rural communities.

We have got a couple of programs that we are rolling out, a tele-pharmacy
program that combines the video conferencing functionality with access to the
patient’s medical record, so that pharmacists in Spokane can oversee operations
of the pharmacies in rural hospitals that often cannot retain or hire
pharmacists. So the two technologies work synergistically to support that
program.

Similarly, we have a tele-ER which is the same kind of thing, where
emergency room physicians in Spokane provide consultation to the providers in
rural emergency rooms, using a combination of videoconferencing and the
information system, so that they can see the patient record, they can look at
the images that are on site, they can talk to the patient or the provider at
the other end. We have found that synergistically the two systems work very
well together for these kinds of outreach programs.

DR. ROOT: I would echo again what Jack said. I guess I need to say that we
didn’t talk to each other before this meeting. In Utah, there is a separate
not-for-profit company called the Utah Telehealth Network, which has created a
telehealth network. It is largely for rural entities. They are one of our
members, and we exchange information as Jac said through the same pipe. The
kinds of information that are exchanged, they do videoconferencing, they do a
variety of things that we do not do. They access the IST for their rural
members, and that allows their rural members to also exchange through us. So it
is a very synergistic relationship.

We also have a relationship with the educational network here, which is not
a telehealth network, it is a tele-educational network, but the similar kind of
a system, that goes to the schools and allows the schools to connect to us as
well when the schools want to build, or hopefully later on if they want to
exchange any clinical information.

So it is not so much that they are the same, but the pipes are the same.
Once you get on the Internet, it is the same. You can exchange different
messages and hence have different kinds of applications at the various end
points, depending on what they want to do. But by working together, it really
expands the availability of both services across the entire state of Utah.

DR. COHN: Thank you. Stan, I saw you raise your hand. Hopefully it is on
the functional requirements conversation?

DR. HUFF: Yes, it is I think a core question. One of the things that I saw
in a couple of slides as a required function was credentialing. I just wondered
if you could make sure — I’m not sure I know what credentialing means in this
context. Could somebody say what you mean by credentialing?

DR. ROOT: What I took credentialing to mean was not that the RHIO or the
NHIN actually do the credentialing, but that you exchange standardized
credentialing information. We are doing that here. CAQH is doing that on a more
national level.

There is a huge need to standardize credentialing information and
standardize the information that is exchanged. It is currently a very labor
intensive, highly wasteful process that providers and payors go through, that
could stand to be improved considerably.

DR. DAVIES: Just from my background in public health, I am also aware that
this is a major issue in the public health community in the area of emergency
response. There are efforts on that side to establish a national mechanism for
if not credentialing, at least tracking the credentials of health care
providers.

I agree. As I said in my testimony, I don’t see it as an NHIN function,
other than the kind of activities Jan just described, where there is the
ability to exchange and accept credentialing from another part of the country.

DR. COHN: I want to thank everyone for your participation. Those calling
in, I know how difficult this is, but we do appreciate your input. Blackford
coming down here from Boston, so thank you.

We are going to take about at ten-minute break, and we will start up again
a minute or two before 2:30.

(Brief recess.)

Agenda Item: Panel III: Large Provider/Payor
Networks

DR. COHN: Why don’t we get started? I do want to comment, we have all had
the experience of this very intimate room. The good news is, tomorrow we move
to a larger room, with hopefully better ventilation. Hopefully the Chair can
see the people here if I see questions and comments. So there is hope for
tomorrow.

With that, why don’t we move back into our discussions. This panel starts
out with Linda Fischetti from the Veterans Administration. I want to thank you
for being here today. We also have Jon McBride from Humana. Thank you for
joining us on what we realize is pretty short notice, so I want to thank you
for being here.

Linda, why don’t we have you lead off with your testimony?

MS. FISCHETTI: Thank you, I’ll get started. I do want to make one short
clarification. That is, when we had originally set out to bring in the
testifiers for this panel, we had intended to bring in a variety of both
providers and payors.

Because of the short time line between when the invitation went out and
today, we had a number of folks who were not able to join us, not because they
were not interested or they didn’t want to be here. The issue was just that
they could not pull the testimony together in time and have it go through
clearance as needed.

So with that, we do not have a provider on this panel. As the Veterans
Health Administration, I am one of those examples of the provider and payor
being in the same entity. We also know that those are the entities that have
accelerated health IT adoption within the United States. So with that, I will
go ahead and start.

Thank you for inviting me to participate in this important NCVHS NHIN work
group hearing. My name as you know is Linda Fischetti. I am the Director of
Health People in the Office of Information in the Veterans Health
Administration, Department of Veterans Affairs.

The VHA runs the largest health care system in the United States, treating
over five million patients every year. External entities such as the Wall
Street Journal, Business Week and the Ash Institute at Harvard University have
publicly recognized VHA as a point of optimism in the use of health IT to
provide higher quality, safer and more effective care.

Our patients have benefitted immeasurably from having their full record
immediately available at any VHA medical center or clinic, regardless of where
the data was entered from within the VHA system. Approximately 40 percent of
our veterans though do receive part of their care in the private sector, and we
want those doctors and nurses to have the same knowledge advantage at the
request of the veteran.

This is our motivation to support the work of the Department of Health and
Human Services and the Office of the National Coordinator and the projects that
they have undertaken, and we fully support the work of their office.

We do have rich experience in health information exchange with the federal
health information exchange project. FHIE — and there is a reference at the
bottom of the written testimony if you wanted to pull up a recent publication
— integrates the longitudinal records of more than ten million active duty and
retired members of the U.S. armed forces. It includes substantial
infrastructure for exchanging electronic health records between the VA and DoD
military health care system.

In the spirit of participating in the health care stakeholder community,
VHA is here today to share our early thinking and experiences as it relates to
how we envision the future National Health Information Network.

This is where you can tell that I am from D.C., because I am traveling with
a disclaimer, as we typically do when we work inside the national Capital
Beltway. This testimony is based on our understanding to date. It is our
current best guess of the future state of the National Health Information
Network, and how VHA will actively consume services and use the National Health
Information Network. This testimony is not intended to commit VHA resources or
strategies. Please recognize that this is simply an act of participating in the
larger community to share ideas so that we can all reach out together and move
forward in a synergistic coordinated manner, where all stakeholder needs are
met.

The views presented today are not intended to imply that all entities
should interact with the NHIN in the same manner. VHA recognizes that other
organizations and entities that will choose to participate in these discussions
will have different business needs, different limitations, different
legislative and policy requirements. As a result, we recommend a flexible
strategy that would make this endeavor one in which the greater health care
population can participate. This is critical to bringing the whole health care
industry along on this adventure.

When preparing for this testimony, we assembled the experts at VA. After an
initial discussion, we appeared to have some conflicts. But we quickly
recognized that when we added the continuum of as is, which is an architecture
term to describe how your systems are currently built, short term to be, our
vision of how systems could be built based on existing policy and standards,
and long term to be, our vision of how the systems could be built based on a
utopian future that included changes in policy to support safe, secure,
ubiquitous interoperability, then those conflicts in the language disappeared.
We think that this use of a time line might help with the NCVHS activities as
well.

In this testimony I would like to address several minimum core functions as
we have been asked to do that VA believes are critical success factors within
both the edge and the core systems. The NHIN minimum core functions, privacy
and security. Let me spend just a minute explaining the first slide. This looks
almost like the slide that was distributed as a template, but as I explained to
Mary Jo, it is almost like you move the refrigerator magnets around to make it
look the way you want it to look at that moment in time.

So on the left, we have the Vista electronic health record system, a list
of the minimum edge functions which I am going to read through right now. You
notice that the gray, which has been used as the core, has been made smaller
and has a minimum set of functional requirements within the core that are
different than what was on the original template. Then we have examples of who
we may be sharing information with over on the far right-hand side.

NHIN minimum core functions, privacy and security. The first concern
related to NHIN is the area of how the data shared within this model will be
kept secure, and how the confidentiality, integrity and availability of the
data will be protected. In addition, how will the protections and rights
afforded to patients under the HIPAA Act privacy and security rules, as well as
the many state and federal laws applicable to participants in both this core
and edge data sharing must follow.

An example of how this must be considered is that all protected health
information is defined within the HIPAA privacy rule, including demographic
information, should be stored within an edges system. A security perimeter,
unless it is released pursuant to a written authorization to a business
associate under a specific business associate agreement, or other legal
authority under the HIPAA privacy rule.

Under a business associate agreement, the information may be stored inside
the business associate’s edge security perimeter for the time necessary and in
accordance with standards sufficient for edge participation to comply with
HIPAA. The security requirement for the network is to provide confidentiality,
availability and integrity to the data in accordance with the security rule
requirements, and for federal agencies, compliance with the Federal Information
Security Management Act, FISMA.

This requirement is in addition to other security that may be provided by
message level security, edge systems or entities.

Availability should include security protections from physical and
electronic threats, including denial of service. These expectations are from
the perspective that all health care entities who wish to participate in the
National Health Information Network will likely be covered entities.

Transport of data. Transports to make data available to the NHIN must be
industry recognized transport types supported by readily available run time
system vendors. The transport layer of the architecture should not be unique to
health care; rather, it should for example be compliant with IP Version 6. The
content and application protocols would be determined by the health IT
standards panel along with the transport to which they are bound.

Edge registry. The core NHIN must maintain a registry of edge systems and
support connection and disconnection from the NHIN, either permanent or
temporary. An edge registry may also contain a record type locator which
identifies the type of record and functions which an edge can perform. In no
case will this registry contain individually identifiable information,
including a unique identifier.

The edge registry will support the maintenance of the registry data by the
edge systems for maintenance of their own registration. The edge registry may
be centralized or co-located with the edge system that can be outside the edge
system’s security perimeter.

For the edge system minimum functions, secure authentication. Two
approaches are considered for secure authentication. The first minimizes the
changes needed for an organization’s security infrastructure. The second and
longer term covers more global mechanisms.

Minimum change. The relationship between edge systems managed by covered
entities under Title 2 of HIPAA will be considered a trusted relationship to
prevent the need for cross provisioning, and is currently not scalable. To meet
HIPAA security requirements, user authentication and level of user access must
be passed as part of the protocol when a user is performing information
transfer. If a covered entity is utilizing a business associate to access the
NHIN, this will be considered a trust relationship only if the valid business
associate agreement with the vendor is maintained by the covered entity.

Matching of patients to their records. Matching of patients will be done
with a federated MPI scheme, where the MPIs are within the — and to answer the
question earlier, that would beg Master Person Index — where the MPIs are
within the edge’s security perimeter. The MPI becomes a person locator service
by extending the correlating process to include the edge identity as the
context for the person ID. Thus, the MPI associated with a given edge knows the
other edges that know the person and the identifier each edge uses for the
person.

A balanced matching algorithm will be used so that correlation results will
be identical regardless of the sequence of matching initiation. Identification
of providers, once the national provider identifier is fully implemented, it
would be VA’s expectation that this number would be the means to uniquely
identify a provider and that a national provider identity would be necessary
for a provider to use the NHIN.

Transport mechanism. This is a first step which will have increasing
specificity as the standards develop. Transport should not be health care or
application specific. They should instead be system platform independent and
should be able to be composed into a standard set of message exchange
protocols, for example, HL7 version 3, Corbone web services, SMTP such as
e-mail.

Privacy and security in terms of an edge system will protect all
information associated with this connected systems, including system and people
identities from other edge systems of the NHIN. Edge systems will be able to
communicate only if parties have implemented the agreements, and the NHIN will
be conducting the connection service on behalf of all of these health care
providers who are presumed to be health care providers under HIPAA, if
participating in this electronic record system.

Security protocols for an edge system should be at a floor level standard
of the HIPAA security rule requirements, and at whatever ceiling requirements
that are applicable to a specific edge system. An example for this with VA is
that an edge system that would comply with the HIPAA security rule is a minimum
set, but because we are a federal agency we do have higher requirements as
well. Likewise, the edge system will adhere to the HIPAA privacy rule
requirements as a floor level standard as well as any more stringent privacy
standards applicable to the edge.

With this, I was not going to read through the standards section. You have
that as part of your written testimony that has been submitted. But based on
the comments of the last panel, I would like to jump to page seven,
credentialing. This was one of the — we originally had the IT security
architect create the testimony. We then ran it through the privacy policy
group. This was a place where we had a language disconnect.

Credentialing can mean two things to these two different groups. There is
system credentialing, which is electronic certifications from system to system
which the architects use, and then there is also the user credentialing, which
of course we recognize as user credentials as well as certification of
education and being credentialed within a certain entity as well.

And with that, I am going to go ahead and end, and had it over.

DR. COHN: Jon, please.

DR. MC BRIDE: I would like to thank the committee. First let me say, I
don’t have a PowerPoint, so I will be going from my testimony here.

DR. COHN: Do we have copies of your testimony?

DR. MC BRIDE: It should be provided, yes. It has Availity at the top.

DR. COHN: We said this earlier and you weren’t here. We are trying to hold
the verbal testimony to about 15 minutes so we have a chance to talk about the
issues and all of that.

DR. MC BRIDE: I can do that. Again, I would like to thank the committee for
this opportunity. It is an honor and a privilege to provide my thoughts to the
National Health Information Network, which I will also refer to henceforth as
the NHIN, especially as it relates to commercial health plans and the proposed
NHIN requirements.

My name is Jon McBride. I am a computer scientist and a chief technology
officer of Availity. I have worked across a broad spectrum of health care
information technology, HIT, from clinical IT, electronic medical records,
developing emergency department clinical systems to global provider portals, to
my current position which deals with provider-payor collaborative IT.

I too have a disclaimer. I am not actually from a payor, however I am here
at the request of Humana, and I speak from my experience working with many
commercial payors across the country. I understand that additional payors were
not able to testify today because of the abbreviated preparation time. I also
understand the importance and applaud the effort of the march toward completing
deliverables. However, I recommend that the committee consider providing
additional venues for payors to share their insights for the public record
about the proposed NHIN requirements. The NHIN success depends I believe on the
involvement of the payors.

My employer, for context Availity, is an independent company created in
Florida in 2001 by a joint venture between two large health plans, Humana and
Blue Cross Blue Shield of Florida. One of the purposes for Availity’s creation
was to provide a collaborative and secure Internet solution to Florida’s then
looming HIPAA compliance deadline. Another purpose was to improve provider work
flow and reduce health care costs by consolidating provider portals.

The payors funded both the creation and the operation of the consolidated
portal with no cost to the providers. This Availity portal, in contrast to the
batch legacy systems that continue to proliferate, provides real time health
care data exchange, which fundamentally improves health care and I believe
should be an explicit goal of the future network.

In addition to its payor owners, today Availity connects to over 1,000
payors nationwide, including approximately 80 percent of the payor market in
Florida. Using standard Internet technology, Availity securely services over
100,000 HIPAA compliant real time requests every business day in the state of
Florida, while processing well over 100 million total HIPAA compliant
transactions per year nationwide.

Over 14,000 out of approximately 15,000 provider sites are registered with
Availity. In addition, Availity is significantly expanding its operations into
Texas, New Mexico, Oklahoma and Illinois as health care service corporations
join the venture. This expansion should provide further economies of scale,
reduced costs and provide more opportunities to develop and offer additional
real time technologies and functionalities.

Since I last testified before the NCVHS just over a year ago, Availity has
worked closely with Blue Cross Blue Shield of Florida and Humana on something
called the Availity care profile, which is a payor based health record. As a
group, we determined to deliver technology that we believe has the potential to
significantly improve health care. Together we rolled up our sleeves to design,
fund, develop and deploy an application that securely accesses and delivers
patients’ health information from their respective payors to providers on
demand, again through the existing portal.

This application delivers all claims information to providers at the point
of care, including physician visits, diagnoses, lab and radiology orders and
prescriptions. Based on technology standards including the ASTM continuity of
care record, the application relies on the federated data model that Availity
has employed from its inception, so we feel that we are beginning to do some
clinical and administrative together, utilizing the same architecture.

We took the standards based federated approach, that we can quickly deploy
the Availity care profile to additional payors and stakeholders. The federated
data model also allows data access even in disaster situations such as
hurricane evacuations, which we have to deal with in Florida quite a bit.

With just Humana and Blue Cross Blue Shield of Florida participation alone,
this potentially can help nearly five million lives in Florida by providing
information at the point of care. Many other payor and vendor initiatives are
greatly furthering HIT, including a Minnesota project which like Availity
supports multiple payors. Other payors in Louisiana, Tennessee and South
Carolina are working to support similarly innovative projects. We heard about
the NIHIN earlier as well, so there are many things that we can look at. I
believe this body should take time to examine some of these projects in detail.
Let’s look for successes and lessons learned and try to relate them to the
National Health Information Network.

Regarding the functional requirements, the approximately 1,000 requirements
submitted by the NHIN consortia represent a great milestone for health care and
embody a collaborative national effort. A successful HIT project requires all
of the core requirements categories at least in abstract terms, especially the
security functions. The details of each specific requirement merit
consideration and clarification for inclusion in any final system.

A published standard interface for operating with the NHIN may be the most
practical approach to provide edge to edge connectivity initially at least, as
long as certain functional requirements are met.

The following outlines some of the specific thoughts and observations on
NHIN requirements which are or should be considered for inclusion. These are
not in priority order. Recovery, again that is very important, was specified
but backup was not. Data versioning should be a requirement different from
logging and the other requirements that I saw. An exact recreation of a record
as it existed at a particular point in time may be needed for many reasons,
including legal and medical reviews. Standards based entry points to the NHIN
should be specified, including the security standards. Master provider and
master person indexes, or at least minimally specified standards could be
extremely useful and prevent duplication and errors in edge and other
downstream systems.

Partitioning and de-identification of data for research purposes has very
different requirements for storage and data structures to support identifiable
transactional data, and should be specific accordingly. Opt-out rather than
opt-in should be supported for certain functions of the NHIN such as for public
health and treatment purposes. I mentioned this, as opt-in was referenced in
the thousand requirements that I reviewed.

While it is important to move quickly to define network requirements, we
should keep in mind that we should not outpace the privacy policies. Although
the ONC has said that the functions of the NHIN, at least the technical
functions, and the privacy will be handled separately, there is a potential
that the technical requirements may come in conflict with some of the policy
issues unless these efforts are aligned appropriately. I would have to question
how far to specify functional requirements without dealing with many of the
existing policy issues in a coordinated fashion.

Self service and stakeholder education and training, though perhaps not a
requirement, should also be built into the system.

Despite the urgency behind the time line of deliverables, we should allow
ample time for additional payors to weigh in on the NHIN requirements. The
payors have demonstrated through many actions their value to HIT. The industry
as a whole is busily working on other important initiatives such as
implementation to support the national provider identifier, planning for the
ANSE X12-5010, ICD-10 support and other state and local initiatives such as
RHIOs and state networks, all of which present significant challenges. We
should also complete the rollout of HIPAA, a precursor to the current important
effort. We should not leave behind a string of unfinished business as we
attempt to bring about new business.

I urge the committee to formally review some of the existing efforts and
successful network models in the course of shaping the NHIN. Further,
government and commercial entities should be held accountable to the same
standards. We should not have a different set of rules and requirements for the
privileged and the unprivileged or for those older than 65 and those younger
than 65, or for large facilities and small doctors’ offices. The concept of a
national health network should be just that, national and singular in purpose,
to improve health care for everyone.

Finally, the government should continue to convene the appropriate parties
and take the lead on pushing the NHIN forward. Additionally, there must also be
focus on enforcing and managing existing national regulations and policies. The
NCVHS should assist or lead in mapping all of the various health care entities
and their current roles in defining NHIN direction and priority, similar to
what we saw earlier in the testimony of Blackford Middleton, which was the HIT
Dashboard.

I also have referred to previous testimony that covers a little bit on the
standards, and I am not going to go all through that.

Thank you.

DR. COHN: Jon, thank you very much. Questions from the committee? Harry.

MR. REYNOLDS: Thank you very much for both of you. Linda, a question for
you. You made the comment that you felt that every entity would be a covered
entity using this, whereas we heard from the RHIOs earlier, and I don’t believe
the RHIOs currently necessarily fit under the definition of a covered entity in
HIPAA. They may be a business associate, but depending upon that not-for-profit
is set up and who is connected to who and what, I’m not sure that all the RHIOs
that I am aware of fit into that category.

So how would that — I think as we go forward with more and more vendors
wanting to offer services, and this becomes capabilities that are not centric
to an organization, where we build around brick and mortar, it opens the door
further for them. So how would you see your testimony be adjusted if it turns
out that some of them are not covered entities?

MS. FISCHETTI: Sure. This is one of the time line issues. We want to be
able to be interoperable sooner rather than later. Therefore we believe the
first step will be very much within the construct of our current policy law and
regulation, in terms of how we can share information.

So in terms of a very near term future, we do see that we will need to have
those protections in place for those folks that we share information with. We
would like to eventually be able to be in a situation where we can offload a
great deal of the authentication and those types of activities to possibly,
maybe, the National Health Information Network. Then it becomes more of a
trusted network, and we are able to share information a bit more freely.

MR. REYNOLDS: I also struggled a little bit with your edge registry,
exactly what that is, and exactly how — if information is in an edge system
and you registered the edge, what data resides where to match it in your
locator service and so on?

MS. FISCHETTI: Let me tell you where this comment came from first, and then
it might make a bit more sense. This is one that came from the technical
architect. They are the ones that know how to build these networks so that they
work, and that everybody knows where they can go for information.

Part of that function, and we are talking about network functions, so I
went ahead and put it in there, is that they would have to have a widget in
place called an edge registry, so that they would even know where to go and
look for information. So this is a very low level architectural widget that my
team thought needed to be called out.

DR. COHN: Can I follow up that? I like the widget concept. But beyond that,
I was reading through because like Harry, I was trying to figure out your
diagram versus the discussion template we came forward with.

It appears, at least as I read your edge registry, I can’t tell whether
record locator information is in the edge registry or not. It seems to me to be
a little unclear. Can you contrast these two?

MS. FISCHETTI: Sure. Until we have a way to identify folks throughout the
nation, until we have for example a protocol for a record location service, the
way that we would need to do this would be to have what the Internet has, some
sort of a widget out there that knows where the VA is, where the hospital
across the street is, and be able to ping them and then rely on the response
from the edge system.

DR. COHN: They would ping them? So basically you would ping them, and then
all that information would be held outside the core?

MS. FISCHETTI: Exactly. There was more the algorithmic lookup, but having
to do it at the edge systems.

DR. STEINDEL: Linda, let me see if I understand this correctly. What they
envision is an edge registry that contains information on how to connect to the
edge system, like the DNS lookup on the Internet.

MS. FISCHETTI: Right.

DR. STEINDEL: They don’t envision the edge registry containing any
information. So if you wanted to know what the edge system does, you would ping
the edge system and say, what services do you provide?

MS. FISCHETTI: Sure.

DR. STEINDEL: Or do they envision the edge registry actually containing
meta data for the services?

DR. STEINDEL: Who is connected, are they connected now, can we ping them
now. Very low level.

DR. STEINDEL: Very low level.

MS. FISCHETTI: Very, very low level.

DR. STEINDEL: Thank you.

DR. HOUSTON: With regards to the edge registry and the system credentialing
and user credentialing, it almost appears from your diagrams that that is part
of the core.

MS. FISCHETTI: There would need to be an edge registry in the core that
understood where VA is and edge system was. Then system credentialing certainly
would take place everywhere, so that is security.

DR. HOUSTON: But that sounds like it is still a core function, though. It
can’t figure out what your systems are.

MS. FISCHETTI: It would need to be replicated at all of the meridians, the
medians between all of them.

DR. HOUSTON: But it would still have to be coordinated by something at the
core. Or no?

MS. FISCHETTI: I don’t know. I don’t know exactly what would.

DR. WARREN: In response to John’s, I can’t remember now, one of the early
contractors said that some of these systems would have to be both edge and core
in order to facilitate the communication. So I am wondering, this edge registry
might sit in both places.

DR. HOUSTON: One would have to be looking like DNS, where you would have
different tiers within DNS, and they are authoritative systems. It sounds like
at some point there has to be some coordinating and authoritative source that
sits at the core that is able to replicate data out to the edge.

MS. FISCHETTI: I know that my technical team is listening on the web, and
they are just dying.

DR. HOUSTON: They are pulling their hair out.

MS. FISCHETTI: So how about we go ahead and resubmit the written testimony
and maybe add a little more information on this particular topic?

DR. HOUSTON: That would be helpful.

MR. REYNOLDS: And as part of that, if you would — I still don’t get what
you are willing to deal with as far as the record location service.

MS. FISCHETTI: Okay. We have said that we will pursue the minimum amount of
information that would need to be outside of our entity to be able to identify
and locate a person. That is almost at a higher level than what we are talking
about here. The edge registry is at a lower level.

In terms of a record locator service, our health information management
office, who is of course the custodian of our records, has agreed and endorsed
the Connecting for Health version and picture of a record locator service. When
we then look at record locator services that have additional information such
as meta data about documents, we have decided that we will not go in that
direction at this time.

MR. REYNOLDS: So you are doing minimum necessary in a match.

MS. FISCHETTI: Yes.

MR. REYNOLDS: Thank you.

DR. COHN: Other questions or comments?

DR. WARREN: I just got confused. A record locator service I don’t see on
your slide. Is that edge? Or is that part of number two?

MS. FISCHETTI: Yes, over on the left-hand side. We need that as a primary
thing to move forward.

DR. WARREN: I just saw that as identify the patient. I didn’t see it as the
record, too.

DR. COHN: Let me try this again, Linda. I really appreciate the fact that
you are willing to run this by the architects again. I know how interesting it
sometimes is, having prolonged conversations with the architects, and please
don’t be angry with me for that comment.

Having said that, though, does this become one of those definitional issues
of what is edge and what is core? I think we heard for example, Marc Overhage
earlier had talked about matching patients to their records, being on the side
of the gateway that was within the enterprise, as opposed to in this NHIN
space. Yet later on they referenced it as being core functionality.

Is this the same thing we are talking about here? It is really more a
question of definitional pieces, what you mean by core versus edge and who is
in control of what? Or do we mean something else by this?

MS. FISCHETTI: I think the size of VA also plays into this as well, are we
multiple different hospitals residing within different RHIOs, or are we a
single RHIO. We do plan to have a single portal engagement to the NHIN, which
would make us look much more like a RHIO versus individual hospitals within
multiple RHIOs.

So we would as a de facto RHIO do that for ourselves. We would keep within
our edge the responsibility of receiving a request, retrieving the documents
wherever they reside, and then providing that back alley.

DR. COHN: Just to make sure that I — and once again, I am thinking of what
I heard from Marc Overhage. Obviously he was the model that you were endorsing
as something that the VA was comfortable with. They both identified this as on
the enterprise side of the gateway, but they also described it as a core
function. So you would be agreeing with that as a conceptualization.

MS. FISCHETTI: Since there has been a conversation nationally about MPI
record locator, document registries, I was trying to purposefully skate around
these, not endorse any one so the national conversation could move forward. We
just need a single national solution that is ubiquitous throughout all of the
RHIOs and throughout all engagement and connectivity to the NHIN, which we can
then act on.

DR. COHN: So you will run this by the architects again?

MS. FISCHETTI: Yes.

DR. COHN: Other questions or comments?

DR. HOUSTON: I’ll wait for the architects to weigh in.

DR. WARREN: A procedural comment. I really appreciated Jon’s reminder that
we really do need more payors. We did try to reach many of them, but Simon
points out that we overlooked AHIP even early in our location process. So I
think the fact that as Simon announced earlier this morning when you weren’t
here, we can foresee a couple more stages of input, that we can go back out to
these people and solicit written testimony, which unfortunately that only gives
them until Monday close of business at this point, but there will be a couple
of specific — at least up to two, opportunities for them also to comment on
work that we have done.

So we did hear you, and we do regret that there aren’t more of them here.

DR. MC BRIDE: Thank you.

DR. COHN: Any other questions for the moment? I want to thank both
testifiers. Our next act hopefully will be a short break, if that is agreeable
with everyone. Let’s take a ten-minute break, allow people to move around and
get reset, and we will start in ten minutes, and that will bring us back up on
time.

Thank you.

(Brief recess.)

Agenda Item: Panel IV: Consumer Empowerment

DR. COHN: Why don’t we get started with our last panel for the day? This
panel is entitled Consumer Empowerment. I want to thank the three presenters.
Phil Marshall will be starting from WebMD. David Lansky will be following up
from Markle, then Elaine Blechman will be talking from the perspective of the
Health Information Technology Standards Panel.

As always, we ask for the testimony and then we will be having questions
and discussion afterwards. I would remind you as I have reminded others all
day, we are trying to hold the verbal testimony to about 15 minutes per
testifier so we have time for questions and discussion. It makes it a lot more
interesting.

So with that, Phil, why don’t we ask you to lead off? Thank you very much
for being here.

DR. MARSHALL: I sure will. Thank you for the invitation. It is nice to be
with you again. I don’t have a PowerPoint presentation today. Usually whenever
we go anywhere we have a large volume of pretty pictures, but not today. You
will have to rely on the verbal testimony today.

WebMD Health is pleased to discuss the role of personal health records as
part of the emerging environment of consumer empowerment within the U.S. health
care system. Our experience with providing PHR solutions to consumers on behalf
of commercial health plans and employers has shown that consumers can be active
participants in the process of insuring that essential health data is available
when and where it is needed.

Regardless of its context, either in the design of a National Health
Information Network, for emergency preparedness, or for providing the
foundation for greater health care choice and consumerism, the PHR can serve an
important role as an application that helps the consumers to gather, store,
manage and share their essential health data.

Gathered from across multiple providers, systems and data sources, the PHR
can support improved treatment, benefit and provider decision making and
enhance communications with other health care providers. The PHR is an enabling
technology, but not an end unto itself. The PHR is a vehicle for consumer
choice and can serve as a bridge across a fragmented health care system.

The key points that we would like to make today and believe are important
are as follows. While a personal health record can be created in a variety of
ways using a variety of data sources, the objectives remain the same. They are
to enable consumers to gain insight into their health history in order to
provide a better context for their decisions, including treatment, benefit and
provider decisions; to enable care providers to have the essential actionable
health history in order to make clinical decisions, especially when a clinical
record on a patient is not otherwise available, then finally, to support
consumer mobility across our health care system.

The consumer should be engaged in the process of gathering, storing,
managing and sharing their essential health data. Many things can support that
engagement, including populating their health record with electronic data
sources, providing value added function and decision support, and even
providing incentives for participation. Consumers can be trusted as full
participants in the health information exchange process to apply their own
discretion on who to share their personal health information with and how best
to share it.

A consumer-centric health record is we believe an essential enabler for
consumer-centric choice, and supportive of decisions within the context of a
health care encounter as well as outside the context of a health care
encounter. While the value of the PHR within the context of a health care
encounter is often discussed, the value outside the encounter might be even
greater.

In the private sector, the PHR today is serving as a secure and actionable
profile for automated delivery of personalized patient education materials,
targeted clinical messaging, health management services and individualized
decision support services that support greater consumer involvement in their
health and health care.

Because the value of a PHR is so great outside the context of a given care
provider, WebMD believes that a PHR that is tied to a particular care provider
or the system used by that care provider could be disadvantageous potentially
to the consumer and care provider. It could be disadvantageous to the patient
consumer, because it could decrease their mobility and choice within the health
care system.

It doesn’t necessarily provide information from across the continuum of
care, and does not provide the foundation for broader consumer decision making.
It could be disadvantageous even for the care provider, because many care
providers are unprepared to offer a PHR application for the consumer to manage
their health information, and especially one that has a view across the
person’s life and across the continuum of care.

True consumerism should, we believe, include open market based choice of
care providers based upon quality and cost whenever possible, and the PHR, we
believe, can be an important enabler of that freedom, and should never be a
barrier.

The NHIN and RHIO efforts must contemplate the potential of consumers using
their own systems to connect into the NHIN. Yet, we recognize that both data
portability and user authentication are essential issues to solve. Perhaps
reflective of these two challenges is the fact that from our observation, most
of the NHIN pilot projects to support the consumer empowerment use case are
only enabling closed access to the NHIN, whereby a consumer may only access
their information through the provider’s tethered system.

WebMD believes that these barriers can be overcome. Allow me to describe a
couple of suggestions and ways that that might be overcome.

When it comes to user authentication, for example, a valid identity for the
consumer should be able to be established not only by a care provider, but also
by other trusted parties. At the very least, we believe that covered entities,
including health plans and plan sponsors and the services and systems that they
employ should be trusted to validate the identity of a consumer.

It is important to recognize the role of plan sponsors, aka employers, in
the national health care landscape, especially in the topic of authentication.
Employers know their people, and they most often serve as the source of member
identity for the health plans.

On the second topic, which is data portability, we believe that data
portability is critical for our health care system, but in particular it is
critical for creating a longitudinal person-centric record that can support
health care consumerism, in addition to the needs at the point of care. We
believe that consumers can drive the process of data exchange with multiple
systems through their PHR.

I’ll provide an example, using tokens, for example, or similar mechanisms
that express both the consumer’s identity and their desire to engage in data
exchange. With that, consumers should be able to use their PHR as a bridge,
motivating data exchange across multiple systems, including with EMR systems.

Finally, we would like to address certain specific questions that have been
posed by you. In response to the question of what are the minimal but essential
network functional requirements for the initial rollout of the NHIN, we believe
that while the consumer is considered by most to be an essential participant in
the process, as certainly reflected in the consumer empowerment use case, the
network functional requirements should consider how a consumer might actually
connect to a network, and the data that might flow over the network as a
result.

While quote-unquote edge systems, PHR systems or other systems might
provide the consumer identity validation and data management, the functional
requirements of the NHIN as a collection of standards should provide an
appropriate highway for that exchange. While the Internet itself provides we
believe an appropriate and redundant infrastructure for secure data movement,
the following could also be considered important features of the NHIN and the
systems that connect to it.

First, we support the CCR document format in the HL7 message standards as
standard formats for data exchange. We support many vocabulary standards,
certainly SNOMED-CT as well as all common billing vocabulary standards
including ICD-9, CPT, HCPCS and NDC, and exchange data to identify the clinical
meaning of that content. We support the efforts to include identity mapping
procedures as part of the NHIN, but these should account for consumer provider
identities, such as the use of a special identifier or token deemed by the
consumer to be appropriate and known to be unique within the system.

Next, in answer to the question, for specific edge systems or entities,
what functions would be minimum but essential for linking to the network, we
believe that perhaps the most important aspect of any system used by the
consumer to connect to the NHIN is how it authenticates its users. Establishing
their identity within a provider hosted system, in other words, a closed or
tethered system, is a logical option for insuring the consumer’s identity has
been validated by the provider prior to the consumer’s access to the NHIN.

However, we believe that a tethered system should not and must not be the
only way the consumers can access this information. Such a model would tie the
consumer indelibly to the provider system, preventing the level of mobility
within the health care system necessary to support flexible consumer choice of
providers based upon cost and quality and other factors.

Therefore, at the very least, we believe the consumer identity can be
validated by health plans and plan sponsors, in other words, by HIPAA covered
entities. We are working today on behalf of health plans and plan sponsors to
validate the identity of consumers facilitating their access to data gathered
from a variety of sources. Access to the NHIN is another logical step in that
process.

But even though covered entities might take responsibility for initial
validation of a consumer’s identity, that doesn’t mean that we believe that a
consumer should have to be bound to that environment for ongoing access. The
consumer for example might be able to generate a unique token, as we discussed,
within that environment and then carry that to another system that meets the
NHIN security and data access standards in order to gain ongoing access to
their information. Such a token could be known by the NHIN, would be unique for
that individual, and should be able to be disabled or regenerated at any time
by the consumer, as an expression of both the consumer’s identity and their
desire to facilitate data exchange. Such a token could be an important
reflection of consumer control within the NHIN.

The final question that I would like to answer is the question of the
Health Information Technology Standards Panel and its identification of
standards for the NHIN and for specific users. We believe that the standards
mentioned above, including the Internet, CCR, HL7, SNOMED-CT and common billing
coding standards when combined with the HR systems capable of authenticating
users to the NHIN, and that meet security and data retrieval and transmission
standards supported by the NHIN, will help facilitate direct consumer
involvement with the NHIN.

In understanding the scope of consumer involvement with the NHIN, we
support the HITSP in its effort to identify and document appropriate use cases.
It will be, we believe, useful to have a variety of use cases in addition to
the registration of medication list use case in order to get a more complete
view of how consumers might utilize and benefit from the NHIN.

A few examples might include laboratory test results. One of the most
attractive features of a PHR to consumers is the ability to retrieve their lab
test results in a timely way. A use case may be helpful that showcases the
relationship with the clinical labs, EMR systems and PHR systems in this
regard.

Patient to care provider messaging would be another useful use case. While
the focus of the NHIN has appropriately been on the exchange of clinical data,
the exchange of messages between patients and their care providers is another
potentially useful use case involving the consumer’s PHR or similar system and
its messaging to the care provider’s clinical work flow solution.

Then finally, health assessment data and health conditions could be
important in another use case. In support of a consumer’s choice of health
benefits, optimal contribution to their health savings account and even
supporting better treatment and provider decisions, it may be important for the
results of a health risk assessment and the consumer’s list of current health
care conditions to be made available through the NHIN to the user’s personal
health record.

The assessment results and health conditions provide a foundation for
predicting future health care expenses, and support the user’s current
evaluation of treatment and provider options. A use case illustrating this
exchange may be useful.

So in closing, thank you again for allowing WebMD Health to comment and
offer its perspective on the role of PHRs as a part of the emerging environment
of consumer empowerment within our national health care system. We stand ready
to support the U.S. Department of Health and Human Services and the NCVHS in
this important initiative.

DR. COHN: Thank you very much. Our next presenter is David Lansky, and
thank you.

DR. LANSKY: Like Phil, I have not prepared a visual presentation, but I
hope you all have a copy of the text. I won’t read this all the way through,
but I’ll just cover some of the key points we wanted to share.

First, on behalf of Connecting for Health and Markle, let me thank you for
letting me join you today and talk about functional requirement issues in
support of the consumer empowerment use case. As you all know, Connecting for
Health has been working for four or five years to develop an approach both for
the technical and the policy architectures necessary to support a nationwide
health information environment.

We have tried to do this in a way that addresses public interest
objectives, including improving clinical care, efficiency of the system,
privacy and security and aggregation of personal health data for population
purposes. We recently published a common framework in April of this year, which
included 17 documents that lay out some of the components we think are
necessary to support the health information environment consistent with these
objectives.

Today I won’t walk you through all 17 papers, but I do want to highlight a
couple of the features of the common framework that I think are germane to the
discussion today.

First, we believe that the network itself should be as thin as possible,
leaving most functionality applications to the users at the edge of the
network. We think this approach creates the maximum opportunity for innovation
and the emergence of new applications that will meet the great range of patient
and consumer needs.

The network should provide the ability to move information securely among
authorized users and under patient control. This approach in turn means that
all of the users of the NHIN must operate in a way that creates trust. As you
all know, trust is a key feature and strategy of the Connecting for Health
approach. Any organization that holds and supplies personal health data must
have confidence that every other network participant will handle that data
appropriately, be attentive to legal requirements, and to the liability risks
that may come to bear upon that data source.

Secondly, we think that a trustworthy information environment to protect
patient information from loss or inappropriate sharing, that the technical
design of the network must incorporate and achieve a priori policy objectives.
The policy concerns cannot be deferred in discussion and planning until after
technological decisions have been made or deployed.

To address policy objectives such as protecting privacy and assuring
patient control, we have advocated the development of a decentralized and
federated architecture for the NHIN, a network of networks, in which patient
information remains in the hands of the care providers to import as initially
provided, and is then linked together by means of various indices which we call
record locator services.

Finally, in the common framework work, we believe that the policies
implemented by the nationwide network should reflect public values and a public
process. Increasingly in this time of common data breaches and identity theft,
consumers are wary of making their sensitive personal information accessible
over the Internet. The initial efforts to develop a consumer empowerment use
case will quickly face the challenges of soliciting patient consent, enabling
patient control, and managing secondary uses of personal health record, among
others.

Each of these questions touches a core public value. Failure to employ a
process that produces transparent and trustworthy solutions to these issues
could jeopardize consumers’ willingness to use the NHIN, regardless of how it
is constructed.

There are many technical functional requirements for providing consumers
with access to the NHIN, and I won’t talk about them today. HITSP and other
groups are doing excellent work in evaluating those. Instead, I want to talk
about a couple of the policy requirements that must be enabled by the
functional requirements of the NHIN. All of thes would fall into the category I
call building trust.

First, policy issues associated with the consumer empowerment use case must
be resolved in a uniform and well understood manner in order to be scaled.
Unfortunately, many of these policy challenges can’t be easily addressed by
established technical solutions or established public policy. In other words,
many of these areas are new in light of the emerging technology and the
emerging use cases we are trying to tackle.

The existing institutions that have been contracted to work on the use
cases do not now incorporate a robust policy development mechanism, which is
needed to be alongside the structures that support the technical work. Even
then, merely identifying technical or policy solutions to these issues does not
assure that those solutions can be procured or implemented.

This core idea suggests four implications for us. First, we collectively
cannot expect even the most sophisticated and best intentioned technology
vendors to come up with answers to these policy questions. It is imperative
that a thorough, transparent and broadly participatory public policy making
effort be embraced to develop the appropriate policies and functions as this
committee is doing today.

Such policies must be developed immediately, so that the vendors who are
even now helping us build a sound Nationwide Health Information Network are
able to select and deploy technologies that implement the policy requirements.

Second, at Connecting for Health we have attempted to answer some of these
questions during our prototype work conducted last year prior to the NHIN
prototype contracts. We tested the NHIN architecture that Connecting for Health
had developed in order to exchange RLS queries, medication lists and laboratory
results. I think we now see that the consumer empowerment use case is even more
challenging and even more complex, and the solutions are less developed than
those we worked on in the enterprise use case.

Third, our work to date illustrates an important aspect of developing
policy and technology together. In many cases last year, we identified
technologies and we hoped to implement policies, but we could not put them in
place because the technology was immature. Conversely, we had technology
aspirations that couldn’t be put in place because the policies were not there
to support them.

We have learned that policy and technology expertise must work together
hand in hand through a continuous process of system refinement and evolution,
in other words, separating technological development and policy development is
not going to be crucial in our view.

Finally, we think that the more we allow the application that serves
consumer and providers to evolve to address a variety of technology and policy
aspirations over the next several years, the more rapidly the nation will
realize an NHIN that meets a broad array of needs. In other words, we do not
think that we should burden the network with anything that can live in the
application layer. The NHIN should be rooted in a set of common policies that
everyone can adhere to, without having the features, functions or application
details determined or constrained by a particular network architecture.

Connecting for Health believes that consumers need reassurance that certain
practices for accessing and managing personal health record are universally
followed by all participants in the NHIN, and that therefore common well-known
policies must be in place and supported by contractual enforcement provisions,
the feature of the federated model we have worked on.

We also recognize that many functions that are essential to proper
achievement of this use case, the consumer empowerment use case, are not
functional requirements of the network per se.

For example, we believe that consumers should have the ability to
communicate information about errors they might detect back to those who hold
the clinical data. This capability is key to the concept of empowerment, and
they should be required in fulfilling the use case. But the network
infrastructure does not need any special capabilities to fulfill this need.
Consumer applications can exchange error and correction information, point to
point with data custodians, using established standards.

Indeed, we believe that this thin network approach is critical to achieving
the underlying objectives of the consumer empowerment use case, which are to
give individuals the power and autonomy of accessing and controlling the use of
their own information.

Let me tick off several requirements for the nationwide network that we
think derive from the way we have been working on this, and how we think about
it. You will see a list here. I’ll talk about each of these very briefly.
Decentralization of personal health information, authentication and issuance of
certificates, interoperable role based authorizations, patient consent and data
standards.

With regard to decentralization, in general Connecting for Health believes
that personal health information should remain in the hands of the entities the
consumers trust to select and manage that information. The emphasis on a
decentralized architecture requires mechanisms to assure trustworthy
identification and message exchange among the dispersed participants on the
network.

These two requirements suggest the need to us for entities that are
recognized by all participants as trustworthy, secure and accountable. Such
entities, which we call patient proxies, will be needed to aggregate consumers,
issue them with identity credentials, and vouch for them as network users,
insure that network policies such as privacy and information practices are
followed.

There may be a variety of forms and types of organizations which act as
patient proxies. Health care organizations that now issue user credentials to
their patients or members may play this role, but we equally envision consumer
membership organizations, software companies and other service providers
playing this role.

The second area is identity management and verification. The consumer
empowerment use case imagines 300 million new nodes on the National Health
Information Network. This scenario not only presents daunting questions of
scale and complexity, but new risks to security and privacy. The single
greatest challenge to implementing this use case is identification of every
user, and this task is made more important by the great sensitivity Americans
report about controlling access to their health information.

Today we have no generally accepted methods or policies for initially
proving the identity of each individual in order to issue online credentials,
nor for the repeat authentication of that individual’s identity as he or she
returns to the online environment. In a Nationwide Health Information Network,
those who hold personal health data will need to be highly confident that the
person to whom they transmit that data is who they claim to be. Common reliable
methods for initial proofing and repeated verification of identity will be
essential to the use case. This is again probably not a function of the network
per se, but it is a function of each participating sub-network or RHIO and
application that connects to the entity, and it is a matter of policy setting
as to the level of security and confidence that are required for participants
in the NHIN to trust one another.

Thirdly, authorization. Now, authorization is not a network problem per se.
Meeting the requirements of patient authorization is essential for the NHIN to
function effectively. In pragmatic terms, we do not envision a system where
every individual provides specific permissions for every intended user and for
every data need. Early experience with such models suggest both the burden of
implementing such a system and the infrequency with which patients make full
use of it.

It may be that the contextual access criteria approach recently suggested
by this committee will assist in resolving this challenge of creating more
nuanced role based authorizations. Nonetheless, we would suggest that the
functional requirements of the consumer empowerment use case provide some level
of consumer control over who is authorized to access personal data, and how
consumers can enable or block access as they wish. As with authentication, this
capability need not be implemented in the network itself, but may represent a
set of policy agreements for data and messaging standards, and a set of
conventions regarding definitions and communication about authorization types
and levels.

Fourth, patient consent, notification and audit. It is essential that
patients know how their information will be used, with the opportunity to
restrict access to it, and to have the opportunity to review access to it. The
functional implications of these principles are that the policies implemented
by each NHIN participant must be transparent to the public, and that some
degree of uniformity be expected.

For example, patients should be confident that the uses of which they had
been notified and the uses to which they have provided their consent are the
only uses which occur.

Finally, expanded data standards. The consumer empowerment use case
anticipates many worthwhile functions such as detecting medication errors,
simplifying the registration process in the clinical setting. These consumer
based applications will necessitate the development of new standards for
capturing and transmitting such data.

There is no commonly used standard today to allow a patient to document
medication side effects or changes in symptoms or even the quite
straightforward contents of the medical office clipboard. Other applications
will also require interoperability with diverse data systems and raise the need
for more standardized patient based data such as coding medication compliance,
such as dose skipping or pill splitting or dietary habits.

We recognize that the most basic premise behind a consumer empowerment use
case will give consumers greater power in their health care experience. It
means that we must not select functional requirements that constrain consumers’
access to their information.

It is important for example that development of the NHIN recognize as its
goal not only to directly connect professionals, but consumers themselves, and
that the state of policy and technology development makes achieving this goal
quite daunting. Public policy must make it possible for each person to access
their own information regardless of where it was originally acquired and where
it is now maintained. Solving a problem like authentication, the NHIN needs to
make sure that eery American has the opportunity to gain the necessary
credentials and take advantage of the information channels that exist without
being subservient to any particular gatekeeper.

We very much appreciate the opportunity to address these issues that are
raised by the consumer empowerment use case, and of course I will be happy to
answer any questions and take part in the discussions.

Thank you.

DR. COHN: David, thank you very much. Elaine Blechman.

DR. BLECHMAN: My name is Elaine Blechman. I am here in my role as professor
at University of Colorado-Boulder, and co-chair of the HITSP CE, Consumer
Empowerment, Technical Committee. I want to thank Mike Glickman, who is here
and is the facilitator of that TC.

I am going to give you an abbreviated presentation of my written comments.
I have completed a manuscript that looks at the alignment of individual and
national interests via the particular kind of PHR that I will be talking about
with some core capabilities. Feel free to contact me if you are interested in
that. I also address issues such as HIPAA and policy issues that David Lansky
was talking about.

I thank you for this opportunity to discuss the core functions for the
initial rollout of the NHIN. As part of the HHS health IT strategy, the AHIC
was created to advise the Secretary of HHS and recommend specific actions to
achieve a common interoperability framework for health IT. AHIC is a forum for
participation from a broad range of stakeholders. Breakthroughs, the health IT
applications that could be realized in two to three years, have become primary
products of the AHIC.

At a second AHIC meeting, five breakthrough areas were identified, and
these were narrowed down for purposes I will talk to you about to three that
could reasonably be addressed in this calendar year. These are biosurveillance,
consumer empowerment and electronic health records. You are going to hear from
co-chairs of the biosurveillance technical committee tomorrow, and from the
co-chair of the PHR technical committee.

These three breakthrough areas, biosurveillance, consumer empowerment,
EHRs, were translated into what are typically referred to as use cases. The
task of developing a process for standards harmonization to support each use
case has been contracted to HITSP. HITSP was formed under the sponsor —

DR. COHN: Elaine, I don’t mean to break in, but we are very familiar with
AHIC. We are very knowledgeable about all of this.

DR. BLECHMAN: Wonderful. That will make it possible for me to go to what I
really am here to talk about.

DR. COHN: Thank you. We do appreciate all this background, but —

DR. BLECHMAN: Okay. So in that case, with great joy and thanks, I will turn
to the current consumer empowerment use case, which is the reason for existence
at this point for the HITSP CETC. We conducted a series of open sessions to
create HITSP work products and deliverables related to this use case. We have
gone through a tier two criterion analysis of projected standards in the first
NHIN forum June 28-29. We have been coordinating standards in preparation for
our September interoperability specification documents.

My testimony attempts to represent the discussions our committee has had
faithfully and concisely. This use case allows consumers to — and I am going
to state this very clearly for you because it is most important in terms of how
we proceed — to establish and manage permission access rights and informed
consent for authorized and secure exchange viewing and querying of their linked
patient registration summaries and medication histories between designated
caregivers and other health care professionals, health and human service
professionals that they have designated.

The PHR plays a key role in current and future CETC use cases and in any
rollout in linkage. Operational definitions and technical standards for
provider controlled EHRs have evolved since the early 1990s, culminating in
HITSP’s harmonization of interoperability standards. However, definitions and
interoperability standards for consumer controlled PHRS are just now emerging.

The PHR must have the attribute of consumer control and interoperability in
order to meaningfully empower consumers, and engage a significant number of
consumers and providers in NHIN rollout and linkage. The term PHR is now
applied indiscriminately to many systems that vary in consumer controlled
access privileges and interoperability.

If we talk about a consumer controlled PHR, we are talking about one in
which individuals establish and manage granular role and relationship based
access privileges for exchange of their personal information with specific
persons, including family, caregivers and health and human service providers.
Interoperable PHRs permit the exchange of consumer information with diverse
PHRs and edge systems.

The CETC use case is arguably the one that relies most on the establishment
of a yet to be determined policy that governs the behavior, roles and
responsibilities of the various systems and actors involved in the use case we
are dealing with. Given the current dearth in widely accepted policies, the
requirements for NHIN rollout must accommodate conservative yet reasonable
policies relating to the use case. I very much appreciate David Lansky’s
description of the need for ascertainment of these policies.

One principle at work in this regard in our committee now is the pushing of
responsibility toward the edge systems where policies may be applied while
sanitizing the NHIN from most contextual requirements, so that the NHIN is
rendered as close as possible to a pure or thin infrastructure, as could be
divorced from many business rules.

Therefore, that was our first requirement for the consumer empowerment and
consumer controlled interoperable PHR.

Regarding policy, our recommendations that I am going to go through now for
NHIN attempt to steer it in a direction that is definitive enough to enable
actual selection of standards in the absence of many policy decisions that may
be made by other bodies while HITSP is forced to go on with standard selection.
So we have to be able to do that standard selection knowing that various policy
options are going to be out there, and that that landscape of policy is going
to shift, and yet we have to have standards in place for NHIN rollout.

So here is our first requirement: Meaningful consumer empowerment, and what
I have called here level four, or sometimes I call it a CE PHR, is a
prerequisite for our current and future CETC use cases, and for NHIN rollout
and NHIN linkage. Only the CE PHR can support the exchange of information
across the NHIN with multiple edge systems, including perhaps a RHIO hosted
document repository.

The second requirement for NHIN rollout is that the NHIN function as
trusted steward of consumer health information. The NHIN must unquestionably
serve American consumers, health care providers, local RHIOs, by efficiently
and effectively storing and retrieving, but not transforming, processing or
replicating consumer data.

NHIN repositories when edge system may not be able to support them, must be
faithful document in-document out information holders, but not processors. NHIN
rollout requires consumer trusted tamperproof transparent end to end transport
of document content.

The third requirement for NHIN rollout is that the NHIN function as a fully
transparent information mediator. Now we come to NCVHS. The NCVHS functional
categories now identify data push and data pull. These categories should also
include document object sharing that is both push and pull where NHIN is a
fully transparent trusted steward mediator.

The fourth requirement for NHIN rollout is that edge systems control data.
We believe that a trusted steward of consumer information must avoid certain
functions that NCVHS has delineated for the NHIN.

The following functions list — I am not going to read them to you all, but
giving you some of the ideas of functions that should reside with edge systems,
such as data rendering, data usage, data filtering and so forth.

The fifth requirement for NHIN linkage is that PHRS control permissions.
Successful NHIN linkage requires a robust infrastructure which guarantees that
patient permissions are imposed and maintained. The PHR as an edge system must
function to establish the source and to manage and maintain the individual’s
role and relationship based permission controls, granular consumer consent. The
PHR system must control the promulgation and perpetuation of consent to all
edge systems attached to the NHIN.

The sixth requirement for NHIN linkage is that edge systems communicate
over the NHIN. The NHIN by definition must act as a trusted transparent
unobtrusive information steward. Individual Americans must perceive the NHIN as
an effective means to better health care, but not as an intrusive force.

The NCVHS discussion template positions the NHIN as an all powerful force
in which communication of edge systems goes through and is, we perceive,
controlled by the NHIN. We recommend an alternative discussion template that
positions the NHIN as an underlying infrastructure in which communication of
edge systems moves over and is facilitated by the NHIN.

The Consumer Empowerment Technical Committee would like to thank you for
the opportunity to comment.

DR. COHN: Why don’t we open it for questions? I need to clarify for you,
you do need to be aware for clarification that the only thing that the NCVHS
produced as a draft discussion template, and all the other 1100 requirements
were developed by the prototype consortia. Our job is to identify what are the
minimal but essential requirements.

I just wanted to make sure that you were aware of that, and that we were
not responsible for the development of those 1200 functional requirements.

DR. BLECHMAN: I appreciate that. I also will tell you that the discussion
template was a very useful heuristic device.

MR. BLAIR: It seems as if we are receiving a message, sometimes with
different words. David, I am going to parrot back this concept to you, and
please tell me whether I am observing things correctly or not.

It seems as if almost everyone that has testified to us is recommending a
thin network. And no matter how they come at it, from whatever perspective,
their vehicle for achieving the thin network is to move some of the critical
security functions and translation functions to what are either called SNO,
sub-network organizations, or RHIOs or other entities, which seem to have the
responsibility of performing these functions.

Have I heard your message correctly, and the other messages correctly,
David?

DR. LANSKY: I think so, from our point of view. The requirements for
security and translation messaging should be uniform, but their execution is
done on the edges.

MR. BLAIR: But there is a clarification here, because the edges is not just
DHR systems. It seems to be sub-networks or RHIOs.

DR. LANSKY: Right, I think that is right. We had this concept of a SNO
bridge, I don’t know if Marc talked about it this morning, where some of those
functions are housed. The gateway between the local network and the larger
network.

MR. BLAIR: To me that becomes a very important distinction, because it is
not just edge. It is moving it to the sub-networks or the RHIOs that will
perform that function. I think that is an important thing for us to understand.

DR. LANSKY: I’ll just add one more comment to Jeff’s question. I didn’t
except for a paragraph get into it here, but the notion that I call patient
proxies, we used to call it a consumer SNO. The notion we have been working up
is an aggregation of consumers into a network of consumers which has the
security functions Jeff described. It is symmetrical in structure to a RHIO or
a SNO at an enterprise sort, but made up of consumers. There is still a
function which does the job of authentication, managing the secure messaging
and so on, on behalf of consumers as direct users of the NHIN. But even there,
we propose a mediating role for the SNO bridge.

MR. REYNOLDS: Phil, you mentioned tokens, and David, you mentioned the
patient should have the right to choose and make available, and Elaine, you
talk about when you get to your slide 15, which talks about interoperability
versus consumer control. So tokens are pretty structured and consent is a
process.

How do you see this working as far as base functionality, as to how these
would go? We talk about a record locator system, when you start getting into
tokens and getting into other things, that leads us away from there a lot
stronger. So just trying to close that gap between base finding records and
then how much control is there about how it gets released and who is who.

DR. MARSHALL: I appreciate that question. I’ll take a stab at responding.
When it comes to tokens from our perspective, they simply are a representation
of a consumer’s identity and their desire for data to be exchanged between a
system they might be using and various other systems across the continuum of
care.

In no way would I imply however that we believe that the NHIN itself should
issue or manage such tokens itself, but rather be a set of standards that would
allow them to be serving in the role of identity in data exchange, identity
that can be an expression of the consumer’s desire to exchange data with
multiple systems.

So I think it is reflective of our recent conversation about edge systems
or other systems that utilize the NHIN as the highway, the expression of that
identity, the use of that, the validation process that might leverage it, we
believe would be the role of these systems which connect in. So I would like to
clarify that point of view.

But we do believe that something used by the consumer that can be used
independent of any given closed system or tethered system is going to be
important as the consumer will have mobility within the health care system and
to be able to express their choice and being able to choose providers in a
variety of criteria, not one of which would be necessarily to offer the PHR
system that allows me access to my data.

So I hope that —

MR. REYNOLDS: You are not eliminating the possibility of a locator service?

DR. MARSHALL: In no way.

MR. REYNOLDS: To get to a person’s record. That is where I’m going.

DR. MARSHALL: That’s right, but I would add to it, however, two things. One
is that a consumer generated and managed token, as long as it is derived in the
context of an appropriate validation system, should be a part of what is used
in that record locator service to be able to locate information, for example,
that the consumer might self report.

But also, I think an important discussion to be had is the value-add of the
NHIN, the record locator service and other components of it, to the consumer.
What I would say on that regard is that we believe that it can have tremendous
value added in helping the consumer to gather information from across the
continuum of the care without having to personally go and retrieve it at every
point of care that they may have interacted with, which of course we are all
very used to.

MR. REYNOLDS: So the token tends to become the identifier that the RHIO
might have or that a provider might have?

DR. MARSHALL: That’s right. I’ll give you an example.

MR. REYNOLDS: No, this is only for discussion. I’m not asking you to design
anything.

DR. MARSHALL: That’s good. I’m not prepared here today.

MR. REYNOLDS: I wouldn’t understand it if you did.

DR. MARSHALL: Let me use by way of example. Let’s say that a person is
authenticated by their health plan, and they through their health plan are able
to gain access to a variety of data sources and even connect into the NHIN and
access the information that way. Let’s say within that environment they are
able to generate a unique token, but they then leave that health plan, they
wish to use a different type of system to gain ongoing access to their growing
longitudinal health record information.

We believe that being able to take that token elsewhere and use it within a
system of their choice should allow them to gain ongoing access. So I use that
by way of example on how a token could potentially be used.

DR. LANSKY: We are just coming to this issue in our work. We are just going
to launch a new work group this fall on authentication and identity management.
I think our purpose will be to try to answer your question, Harry, of how deep
do we need to go, since we are focused solely on network infrastructure
principles and want to maintain distance from the other components.

We are going to try to look at all the models that are now being developed
by a variety of parties for authentication services, and make a judgment,
collaborating with all of our usual colleagues, about the appropriate place to
be, as we see this as the most important issue to be addressed in the next year
or two.

DR. BLECHMAN: The HITSP CETC is involved in identifying standards rather
than addressing actual implementation. But that said, we now realize — and
this has been a process of discussion and debate within HITSP and within our TC
— that we do require standards for consumer control over their permissions
that are not in place unless we revisit and reinterpret the HIPAA privacy rule.

We do in our discussions about the packages of standards that are going to
be needed for interoperability conceive — and we have started to conceive of
the possibility that the authentication, audit, non-repudiation, all of these
services, could take place in two places.

Charles Carosel, who is my co-chair with me on the technical committee, put
together that figure that you saw. That envisions either that these services
would take place in the context of a RHIO, or that a PHR system, itself an edge
system operated by a third party vendor, would essentially operate what Charles
has called a RHIO in a box, meaning that all these services would be located on
the side of the PHR system.

MR. REYNOLDS: Thank you.

DR. COHN: I have a question, maybe. I’m trying to think if it is a question
or a comment. When we start talking about security, I never know exactly
whether we are talking about functional requirements or policy. Clearly our job
is not to solve policy issues, but I think if we come across them along the
way, probably it is useful to identify them and point them out.

There are a couple of things coming together that are causing me some
concern. David, I think you commented out this issue of authentication and
identify management being one of the big issues. It is a big issue in RHIOs, it
gets to be a bigger issue in NHIN. Then suddenly you start adding that personal
health dimension to this, and I won’t say it explodes, but it adds a whole
other dimension.

I am thinking of the document reproduced on personal health records
sometime ago, where we talked about, or at least recognized the fact that
security from a consumer directly into their records typically is not as
industrial as from a provider environment. There are location issues. It was
one of those things where the normal methods of authentication and security we
have that exist outside of a fixed environment are not as good as within a
fixed environment.

So I am sitting here in my own mind, trying to figure out ow we manage all
of this stuff, other than to observe that there is — it just seems to me that
we are dealing with a fairly risky area, is what I am trying to say,
recognizing of course that we can have wonderful standards and technology
solutions, but all of the security issues that we have seen over the last year
have to do with execution. It goes from newspaper article to newspaper article.

So I find myself being very much in support of everything, but also being
worried at the same time. I don’t know if our panelists want to make any
comments about this. I am be overreacting, but I am listening and thinking
about the various dimensions here, and I am trying to think of some reasonable
way to approach it.

DR. BLECHMAN: I would love an opportunity to comment on this. I am
responding now in my role as private citizen, okay?

DR. COHN: Go ahead.

DR. BLECHMAN: I will say that one of the greatest injuries to American
consumers has been created by lack of enforcement of the HIPAA privacy rule. So
if we don’t have adequate resources as we go forward with NHIN to enforce the
standards, the labeling, we are going to be having to talk about labeling of a
PHR. We are going to have to in the future talk about what kind of PHR can be
participating in an NHIN. We are going to have to talk about the standards that
are required for transmission of private secure information.

DR. COHN: Sure.

DR. BLECHMAN: If the plans stop with the promulgation of standards and
don’t go into adequate resources for enforcement, both at HHS and I would think
even at FDA, then I think there are going to be — it is going to be a sad
ending.

DR. COHN: I didn’t mean to open up a whole bunch of policy issues. I guess
maybe my question really is to Phil Marshall, and then I will ask John Houston
to comment also, about whether he feels that the token approach that he is
taking potentially provides adequate security, and that that is a useful frame
for us to be thinking about. I will try to calm down my general concerns as I
was thinking about the dimensions here.

DR. MARSHALL: That seemed pretty calm. I am happy to respond to the
question.

I think you are hitting on the critical issue, after all. You can dictate
CCR, you can dictate SSL encrypted transmission. You can put all the furniture
in the house that you like. But if you don’t put a front door, no people are
going to use it, and consumers are important users of this system.

So the question really is, how do you provide an appropriate door into this
for consumer involvement. At least that is what I think about, and that is what
we think about. The use of the word token and my description of it was used as
an example of something that as I have said can express the person’s identity
and their desire to exchange data, at least with the system that they do have
control over under the definition that we have provided.

So I think that the user validation, the context in which such a thing
might be created, derived, managed by the person, is really the issue. That is
why I stated that while the NHIN pilot projects currently seem to be
implementing under the general contractors ways for consumers to access their
information, but within a very closed and very tethered way. I suggested that
we should broaden out the notion of consumer validation to at least include
covered entities, health plans and plan sponsors, to be able to validate the
identity of those individuals.

But then I also added that if those individuals known within that
environment can generate something that represents them uniquely, and they
leave that environment, or they wish to access that information elsewhere, they
should be able to use what I call a token to be able to gain access.

Now, to me there weren’t necessarily any security — specific security
threats in the model I just described. Their initial validation, the generation
of such a token, their access to the information, we are doing a lot of these
things today, so there is a lot of experience in the industry for this.

But I use this as an example because I do think it is feasible. I do think
that it can help consumers to be involved. Yet I don’t necessarily perceive any
specific threat in having the consumers actually apply their own discretion in
being able to facilitate data exchange on their behalf.

I don’t know if that added any clarity.

DR. COHN: Thank you. I think this helps. John Paul, do you have a comment?

DR. HOUSTON: My comment, maybe you partially answered it, but it is more
nuts and bolts. In one sense when you are dealing with the NHIN and access by
providers, it is easier to administer that access and decide who is bona fide
and who should be accessing information. It is another thing when you have to
say, you now have information that is linked to the provider based record, and
you are going to have a PHR that is tethered to it.

How do you verify that the user is who he or she purports to be? It is very
tricky. One of the problems we have in our society today, we talk about
identity theft and credit card theft, things of that sort. Part of the reason
why that occurs is because the credit card companies have made it so easy for
somebody to vouch for their identity that many people are able to vouch for
their identity even though it is not them.

My point is that we have to hold the whole process to an even higher
standard. How do you verify to a reasonable level of comfort that that patient
is who he or she purports to be, so that you feel comfortable then linking it
to an EHR and not feeling that it is somebody masquerading as that patient?

Part of the solution almost has to involve that patient and the
relationship he or she has with the physician or other caregivers, who is able
to say I know that is who that person is, but it is a tricky issue.

DR. MARSHALL: If I could respond to that, it is interesting that you used
the tethered EHR model as one that generates these difficulties. In fact, with
the NHIN pilot projects, the models that are being pursued for the consumer
empowerment use case, the providers are generating the user name and password
in those models giving the consumer direct access.

But as I have stated in my testimony and in response to your comments, that
is not a model that would necessarily support the consumer’s full mobility
within the health care system. I think we recognize that, that if a person goes
in through that environment they are given a user name and password by the
provider to access, that locks them in to some extent.

The model that I was speaking about earlier at least would extend it out to
other covered entities to be able to serve that validating function. After all,
these same entities are responsible in the same way over that data as care
providers.

I would like to reiterate something. That is, the value of this information
is immense outside just the context of a clinical care encounter in supporting
decisions.

DR. HOUSTON: I absolutely agree with you. My point more so is that when a
patient decides he or she wants to develop their own PHR and it is not tethered
to anything, and they can decide what PHR they want to use, I think the patient
is able to separately look at the different systems and identify which PHR
suits their needs from a security and from a functionality perspective. But as
soon as you tether something to an EHR environment of some sort, whether as you
change providers you have changed the tethering, you still have to worry about
the fact that there is that direct tie into access to records that are inside
an EHR.

I think that raises the bar with regards to the scrutiny you have to apply
to individuals, consumers, being credentialed. I think that is a real sticky
issue.

DR. COHN: John Paul, I think you have said this well. I will just note,
once again it is not our job to solve policy issues. This gets to be
dangerously close, but it is something to raise as an issue to assist ONC.

Harry has a question, Mary Jo has a question. Thank you all for having
conversations with us about all this.

MR. REYNOLDS: Back again. As I am trying to think about our purview, which
is base functionality, and as you talk about a record locator service, that is
easy to get your hands around. As you talk about passing the records through
and securing it and so on, that is fine.

As we keep moving out further, it starts to get muddy. I know we are not
supposed to be over there, but if we don’t go over there, then we can’t know we
are okay where we are, as far as what our base functionality is.

If I am seeing three doctors, and then I have a personal health record that
is not connected to a health plan, there are a lot of vendors out there selling
them and doing lots of stuff with them, and a doctor wants to access my
records, I get sick here in Washington, my records are going to be accessed.

The discussion about the individual saying only this doctor can get it,
only that doctor can get it, it pushes the sophistication to the edge system as
far as being able to handle this. I don’t get it. I don’t get that the
sophistication is going to be that good.

Therefore, if you look at where the base is supposed to be going and you
look at the edge, I don’t see how the edge pulls it off. Does it have to be
more intrinsic in the base? Because that is a sophistication level both of the
data that you are going to parse out possibly, and the fact that you buy a $150
EHR system from a vendor, and oh, by the way, you are going to put in there
every doctor that they are allowed to see, and you are going to figure out how
that doctor is identified in NHIN core functionality?

I don’t get it. I am really struggling to understand how that all works
together, and what functionality has to be in that base. If we say nothing, it
is all edge, I will wait later for that discussion, because I will come back on
it then, whenever that comes up, because I still don’t get it.

DR. COHN: We will let the presenters respond.

DR. MARSHALL: I’m just curious, Harry. Prior to our discussion and the
elucidation of some of these other complexities, what was your perception for
how that doctor that sees you in Washington, D.C. was going to gain access to
your information?

MR. REYNOLDS: I am trying not to have perceptions yet.

DR. MARSHALL: I’m curious about it, because —

MR. REYNOLDS: I don’t want this to be you and me discussing what my
perception is. I am trying to talk about what is the base functionality,
because we have to deal with everybody’s perception.

DR. MARSHALL: I appreciate that. Let me pose the question differently. If
we think through the scenario of you — not you, anyone, getting sick here in
Washington, D.C. and their data being accessed, there is a process that the
provider has to go through that says somehow, I need access, here is the
person, give me their data. The system validates them as a user, they put in
certain identifying information, the record locator service works and their
data is retrieved.

I certainly didn’t want to represent anything different about that scenario
per se. I realize we are having a lot of discussion about how the consumer can
control that between doctor and doctor.

I don’t necessarily want to sit here and represent a point of view on that
from our perspective, however. What I wanted to represent, and I want to be
very clear about this, was the ability for the consumer using their system to
be able to facilitate data exchange so that they have a longitudinal health
record available, no matter where they may go.

Yet, I don’t want to express any opinion about a consumer getting in the
way of that emergency room physician being able to access the NHIN on their
behalf. So I’m not sure that additional complexities for that scenario are
necessarily raised, at least from my point of view, although I realize that
many folks have a point of view.

DR. LANSKY: I would say that our view at the moment which will evolve as we
do this work in the next six or 12 months is that the network itself is neutral
to the permissions and authorizations that are being transmitted across it.

One edge system, let’s say the emergency room in Washington, may talk to
another edge system which is your primary care doctor elsewhere. In an
imaginary world, every point to point relationship we have constructed a way to
talk to each other about authorizations, saying this is an office clerk, this
is a physician, this is the patient themselves, and they have certain
authorizations to access my data.

It seems likely that we will need to have some uniformity or standards
around the country as to how to denote or tag those authorizations, so that
every application can recognize the meaning of the permission that is being
transmitted. We don’t want to negotiate those between every pair of partners on
the network.

That is a policy agreement encapsulated in standards, but it is not an
attribute of the network or of all the users of the network.

MR. REYNOLDS: But the network has to have the information and/or the
functionality to identify.

DR. LANSKY: To transmit the identification. In our terminology, the SNO
bridge will transmit those permissions to each other, but the network itself
doesn’t manipulate them.

MR. BLAIR: I feel as if we have gotten into a semantic bind, and I am
trying to break free of it. The semantic bind is that our original mission here
was what is the minimal core function of the NHIN. Our testifiers have been
redefining that, and they have broken it apart, from what I could see, into a
small thin NHIN.

The problem is that the sub-network organization and the RHIOs in many
cases have the attributes of what we had originally thought might be in the
NHIN. So we can’t just lump all the SNOs and RHIOs as saying they are edge, and
saying that is not our scope.

For example, important issues like authorization and authentication and
translation and all of these issues are now in that area. So I am wondering if
we need to revisit the idea of just thinking of this as two buckets, core and
edge, or do we have to look at this as saying, are the SNOs and the RHIOs
really part of the NHIN scope, even if the NHIN is just a thin interoperable
network?

DR. COHN: Jeff, I am going to jump in. I am going to try to repeat
something that John Loonsk said right before lunch. He was saying — and John,
if I mess this up, please assist me, but John observed that it isn’t just core,
it is also edge that is critical to the functioning of the overall NHIN as a
central requirement.

So I think what we are describing are things that are critical. We maybe
need to observe them as being critical pieces of the edge to enable the
functioning of all of this.

MR. BLAIR: So you are saying the answer to my question is yes?

DR. COHN: I think so. John, am I misinterpreting what you said?

DR. LOONSK: I think that we have in the previous work recognized the
semantic bind here, and because of that identification we have been suggesting
that this effort, this requirements effort, talks about the totality of
requirements, soup to nuts, to carry out the functioning that people are
envisioning for this activity, and we don’t immediately now delineate services,
and this is the NHIN and this is a RHIO and this is a network exchange and this
is an SNO, because I think there is still work to be done in that regard.

From the standpoint of the requirements — and it is hard, because we have
this nomenclature of the NHIN overriding all this, but from the standpoint of
the requirements, we are trying to talk about the totality of requirements
necessary to carry out the function, recognizing that the NHIN services may be
a subset of that as they develop.

So because of that, we have started to talk about edge and everything else.
For edge systems, we are not talking about the requirements for their
functioning. If you talk about in the EHR, you are not talking about the
functional requirements for providing services aside from those related to
network services. You are talking about only the requirements related to their
connection to Internet working and services in that regard.

So we are not talking about the full set of requirements that have been
identified in the certification commission, or the criteria for a functioning
ambulatory care EHR or the HL7 functional model. There is clearly a lot of
material there that is not immediately relevant to the networking activities we
are discussing.

But on the other hand, we have to talk from the standpoint of understanding
the breadth of this activity from soup to nuts, from edge to — it is premature
in regard to the NHIN to talk about what is the line of an NHIN service, versus
a sub-network or versus a RHIO or versus just a freestanding EHR.

That too will come, but where we are with the NHIN from a prototyping
standpoint is that in fact, I think that in some respects when you look at the
prototypes, and we haven’t looked at them, they don’t exist, but I think that
they will in some respects look more like what some would consider to be a
regional interchange capability rather than the NHIN thin network.

So without trying to adjudicate those issues, we are trying to tease out
the substance of the networking requirements and put them all on the table
right now, but with the caveat that by doing that, we are not trying to
stipulate that all of those functions are part of the NHIN. We would anticipate
that some of those functions would be a part of an NHIN service that was
provided, some of them might be part of a regional network, some of them might
be part of another method of provisioning.

DR. COHN: Thank you.

MR. REYNOLDS: One comment further. Remember, most of the testifying — in
this particular case we talked about consumer empowerment, so most of the
discussion is going to be with that in mind.

One of the key things we took off the picture was who and entities. We took
entity names off purposely. We had RHIO on our first pictures we had drawn, and
we said RHIOs could maybe be part of this and part of that and everything else.

So I think we just need to drill down on what is being said, to make sure
that we can categorize the functionality, not the who, and not what entity it
would end up in, but make sure we understand the network functionality. Then
later on the industry may parse it many different ways, depending upon who is
who is what is what.

We heard some testimony earlier that said more of it should be in a RHIO
and less should be in a service. So I think we have asked the testifiers to
come talk about their area of expertise, which means they are going to use
their nomenclature in their expertise.

We have got to continue to filter it back into our picture. That is why we
simplified the picture, so that we didn’t add some things that everybody could
tag things to, and then we would have such a complicated discussion that it
would be, who wins. So that is what we have tried to do with this, and as we
have invited these people, we have invited them with certain expertise.

So I think we need to realize that they will present with that expertise
all day today and all day tomorrow, but we have got to pick it back out and say
what is the real functionality, where do the lines stop and start, and what
does that mean. Is that fair?

DR. LOONSK: We are really talking about a couple of different processes and
differentiating them. The functional requirements are more expansive then the
specific services that may emanate from them. That should be noted.

DR. COHN: So Jeff, I think the answer is yes.

MR. BLAIR: Thank you.

DR. COHN: Now, I think our next question is, Mary Jo, you are on next, and
then Judy.

DR. DEERING: I have been struggling to give voice to my rising angst, and
formulate it in a question that can be answered. It may be something that
emerges as a request for a homework assignment.

My angst is that first of all, we have heard ever since the start of the
day that there is so much that must be done in the policy sphere before we can
go forward. You are going to have to make de facto policy decisions about
patient consent levels, for example, because then you are going to either allow
it this way or you are going to allow it that way, or you are not even going to
allow it at all in the beginning, just because you don’t have time. You are
going to make what are de facto policy decisions.

Clearly the policy decisions, I think most people would agree, are raised
most acutely in this scenario, because everybody agrees that their definition
of this scenario is patient control. That is the sphere of policy and
technology that is the least robustly developed.

So my angst is, that means we are either never going to get there, and
Markel in a year will give us some guidance, because you have given us some
very good guidance in other areas.

So I think what I am trying to ask is, given the fact that the path forward
to pulling together the various strands of policy, practice, translating into
business trust agreements, reflected in technology, seems to be the furthest to
go in this area. Are there fixes or things in the standards area, are there
proxy things that can be implemented very quickly through established routines?
Is there something that HITSP could do? Is there something that if HL7 took it
on and we really paid them and said we really, really, really want you to focus
on this, that would at least get us partly down that path?

DR. LOONSK: I just would like to interject one thing, because it hasn’t
been mentioned before today. The American health information community through
its recommendations to the Secretary of Health and Human Services identified a
number of activities around the different breakthrough areas. One of the
followup recommendations that was common to each of the breakthroughs was that
there were certain issues, policy issues and approaches relative to
confidentiality and security particularly that cross cut the different
breakthrough areas, and should be teased out, and that a work group should be
established to make decisions about what the set point is for those activities
in the context of those breakthroughs.

That work group is being formed. We have talked about policy here a number
of times today. I think that there is absolutely a broad recognition in ONC and
elsewhere that there are complex interrelationships between technology and
policy. There are other activities that are going on. Part of the
incrementalism of the NHIN needs to be about teasing out policy implications
that are obvious from the technology, that need to be done. I have just given
an example of how some of that will be pursued. Then also taking policy results
and feeding them into next steps of the NHIN process.

That incrementalism is what we see as the path to tackle some of these,
because there are so many complexities in these areas. They are difficult to
completely separate, but on the other hand, we need to make progress in both
areas.

DR. WARREN: As I have sat here and listened to things, I guess it was
Jeff’s question that pulled it together for me. We are almost making an
assumption, and I am trying to clarify, are we making an assumption that RHIOs
have to exist for the NHIN to function.

We have been talking about these edge systems of being in RHIOs, so now I
am confused. There may be people who are not belonging to RHIOs. So when we
talk about these edge systems, we are talking about anybody that is not in the
core having to meet these functions, whether it is a patient identifier,
authentication, authorization. It may be a physician office that is having to
do these functions in order to participate within the NHIN.

Am I getting that right?

DR. COHN: I think we are getting into problems with what the definition of
a RHIO is. If you remember, we heard Utah saying that the VA was not a RHIO.
The VA described themselves as potentially a sub-national organization. So that
is what I mean.

I don’t think we are necessarily expecting every physician’s office to have
the sophistication to do all this, but there will be groups that are probably
not classically RHIOs, but that are part of the network.

DR. WARREN: To me, it goes back to this thick and thin discussion we had
before lunch. If I have got a lot of well functioning RHIOs, I could probably
have a very thin NHIN. If I don’t, then the NHIN has to become progressively
thicker in order to provide these services to less mature, less functioning
kinds of places that have records, whether it is a physician office, a medical
center that is out in whatever, in the middle of nowhere, that is a 20-bed
hospital.

So how do these people participate within an NHIN when they are not part of
a service that aggregates up? I guess I am trying to get to the scope or maybe
even the definition of what is an NHIN, where we can identify what these core
services are.

DR. COHN: Or maybe you are talking about the architecture in deep fashion.

DR. WARREN: I don’t know. I am getting real confused here.

DR. STEINDEL: Judy, can I paraphrase what you are saying? Your indication
was that if there isn’t a RHIO, then we need a thicker NHIN because these
services need to be someplace.

DR. WARREN: Right.

DR. STEINDEL: I would say it a little bit differently. I would just say
that there is a set of services that must be available to the NHIN. From John’s
statements that he has been making, where he wants to separate this from
entities, if we phrase it like that, then it leaves us — we are not stating an
architecture, we are not putting things in locations and putting brands on
them, but we are achieving what I understand the goal to be, enumerating the
essential functional requirements, and then not making a statement as to where
the central requirements sit or how they sit.

I think as Harry said, what we have to do is listen to all the presenters
and put on the hat that they are wearing, so that we can filter out the hat
that they are wearing when we sit down and discuss this, and get it down to the
essential functions.

DR. WARREN: So you are suggesting we look at a set of services, not
necessarily placing these wherever they might be.

DR. STEINDEL: I actually would phrase it that way. I don’t know if we
should use the word services in the final —

MR. BLAIR: Functions.

DR. STEINDEL: — because then it may imply a service oriented architecture,
and I don’t think we want to imply that. But I think for operational reasons
the word service functions fairly well right now. But I would be leery of using
that in the final report.

DR. WARREN: So I would suggest that maybe one of the things that we need to
keep in the back of our heads is, we need to be very careful what we call
things, and need to start looking at how we phrase it because of all the
meaning ladenness that most of these words have.

DR. STEINDEL: Let’s call it George.

DR. WARREN: We’ll call it George, all right.

DR. COHN: I was thinking that we maybe want to wrap this section up and
move to further discussion.

I want to thank our presenters. In some ways the consumer empowerment area
as we all commented may be the least developed of all of this, so there are
things that we see in greater relief here than we might see in others. I really
want to thank you.

David, as always you are typically a step ahead, so hearing about the work
on authentication and identity management seems like a very timely piece of
work. This is through Markel?

DR. LANSKY: Yes, Connecting for Health is staring a new work group on that
subject.

DR. COHN: So we will be interested to hear when you begin to work further
with that, because I think it will be a very valuable piece of information as
we all move forward. Thank you. I think you have done a really great job, so we
appreciate it.

Now, what we have left for the day is, first of all we want to open things
up for any public comment. I apologize; you have seen my back all day today, so
I have no idea whether people are rested and want to make public comments or
not. But this is certainly the occasion, if any of you would like to stand,
come to one of the microphones and present your thoughts or make any comments.
Please feel free to.

I guess I would also comment that we are very happy to take written
comments from people who are in the audience, any of the testifiers, as well as
those who are listening in on the Internet. So feel free to respond to Mary Jo
Deering.

Please come and introduce yourself.

MS. BOWER: I had to, I couldn’t pass up the chance. This is Cynthia Bower
from ODPHP.

I think one of the other complicating factors in separating these out is,
all the testifiers are talking about projects and deliverables they have, so it
is really coming from within that perspective of having to develop things, and
the committee’s task is quite different than having to develop a thing. It is
working at a conceptual level.

So just to reinforce what Harry was saying, the committee’s task is quite
different from what any of your testifiers’ tasks has been so far. So I think
it is staying at that higher level and leaving open the possibility that there
are many entities and organizations that are going to have a role in this, that
have not come before this committee yet.

I think about for example the role that schools might play, or social
service agencies. That is again outside the health care sphere, but could play
a very important role in an eventual NHIN. So just to reinforce what was said
before, that this is more of a conceptual task than a concrete product task.

DR. COHN: Thank you. Other comments? The other piece I think I should say
before I forget, I received a little note reminding everybody that we are not
going to be here tomorrow, we are going to be across the way in the big room,
with the good air conditioning, we hope. So people need to make sure they take
everything out whenever they are ready to leave.

Knowing that this is the occasion for work group discussion and you have
already had some just now, I am curious if there are any thoughts or any
comments that members of the work group or any of the staff want to make in
relationship to insights from the day.

Jeff, for some reason I thought that you were going to make a comment.

MR. BLAIR: At the end of a day like this, I have an appreciation for the
process of NCVHS. We wound up dealing with a lot of difficult issues, and we
pulled them together. So that is my only observation. It is just gratifying to
see the way we operate.

DR. DEERING: I wanted to pick up on something Linda said in her testimony,
where they found internally at VHA in preparing their testimony that taking an
explicit sequential perspective helped them, so that they could talk about what
they were doing now, what they might be doing in the near term, and what they
may be doing later.

I would just like to put on the table and to John, whether our work product
— you encouraged us to take that position, so I guess I am just going to pick
it up and say, is that something that given the complexities and some areas are
further along than others, do we think it would be feasible and useful to
approach our task in that sense, where our final report thoughtfully says, in
the next six years we can see this and this, and then that. So it is a question
rather than a statement.

DR. COHN: Are you looking for an answer?

DR. DEERING: Okay, well, it is open. I know we are focusing on the initial
rollout, so by definition it has got to be — but how soon is initial, after
all? I’ll leave it.

DR. COHN: John, you should feel free to comment.

DR. LOONSK: I think there is absolutely a recognition that in terms of the
work that the NHIN consortia have done, that the three use cases are much more
significantly detailed than any other activity. That needs to be recognized.

At the same time, there was good discussion at the forum. There has been a
lot of good work that has occurred elsewhere that has pointed to additional
functionality that one could consider, and base functionality for the NHIN. I
think we have to start thinking about that and including that, but recognizing
that even in September, that will just be an initial set, and that we can’t
anticipate having all the details necessary for subsequent activities.

The expectation is that the NHIN is going to grow organically to a certain
extent, and that there is a lot of work that has to be done that can’t be
completely anticipated in terms of what activities will produce the most
business value, what will be generated when the initial infrastructure is put
into place. So incrementalism and planning out a time frame is very important.

I think some of the priorities for what next steps are, we hope to also get
from the American Health Information Community. So both in terms of the
existing working groups and perhaps some additional working groups that will
come, they are going to talk about other areas. I think we are going to see
some new areas probably in the not-too-distant future that will also have
significant impact. So we have to recognize all that.

MR. REYNOLDS: I think we set this process up, and tomorrow may be less,
equally or more confusing than today. Our goal was to have two days to hear
from a very wide swath of the industry, and to take — remember, the work that
has gone on so far initially started with functional requirements. This is not
a little thing.

I think the key thing will be tomorrow at 3 o’clock, when we have our next
big discussion, what is our context of what we heard, what is our context on
our next move, as to how we start to synergize it, because it may become real
clear as everybody sleeps tonight, you get a little better sense. Tomorrow you
may hear testifiers that — I know I heard brand-new things today that pushed
the envelope.

So I guess my point is, we bought into this two-day thing to hear what we
hear. I don’t want any of us to start worrying about it yet because we haven’t
heard it all. We weren’t worried about it before. We were all worried that
there were 1200 requirements we were going to be looking at.

This is not an easy task. In the past we have been able to take complex
things and honorably discuss them and come out with something. That is what I
still hope that we do. But this one is not going to be as clear as some of the
others.

DR. COHN: I think we are making good progress.

DR. GREENBERG: I just wondered if I could make an observation, as Jeff will
often say, to see if I am on the right wavelength here.

Early on in the day, I think Cynthia asked a question about, we were just
talking about patients and medical data and clinical data, et cetera. Generally
there was agreement, no, we aren’t. But still, I think that is the principle
focus of most of the testimony we heard today and most of the discussion, until
we got to this last panel.

I think if this afternoon, the last panel had been the electronic health
record use case, we wouldn’t be feeling as untethered, to draw from that
language, or as complicated as we do. MR. BLAIR: But you are already
anticipating the synergies that we are going to wind up pulling together when
we hear the testimony from EHR systems. I think that is what I meant, by
watching to see the process of how we listen to things, how we pull things
together from each different perspective. I think you are already beginning to
anticipate that.

DR. GREENBERG: And I’m not saying we shouldn’t have done it that way. I’m
just saying that we have three use cases, and the one that is most aligned with
a lot of the thinking is related to the electronic health record. But two of
the use cases are interactive in electronic health record probably, but are not
that, they are the biosurveillance and public health — well, it is more
narrow, but potentially the whole public health arena, and then the personal
health record and the consumer empowerment.

So I think in a sense it is good that we did have the consumer empowerment
this afternoon rather than the electronic health record, because maybe we won’t
sleep as well as we would have.

So that is just my sense of the way things have developed. I think it does
open things up more for our discussion tomorrow.

DR. COHN: Before I go to Steve, I haven’t heard anything so far that causes
me to not sleep well. It really more opens up my mind wider and seeing new
things that I might not have otherwise perceived.

DR. STEINDEL: Simon, I was going to say the same thing. I was basically
very pleased with the presentation of the consumer empowerment one, because it
was the one that I expected perhaps to be most divergent from what our set
thinking would be. Yet, I saw a tremendous amount of synergy between it and all
the others. I think it fits in fairly nicely.

I think there are a lot of technical twists and turns in the consumer
empowerment one, but fortunately at this point in time that is not our charge.

DR. GREENBERG: It was only an observation, and if it resonates, fine.

MS. BOWER: I think there can be synergy, but at the same time it is
allowing for orphans or outliers or whatever terminology you want to use. I
think that you can see where these things come together, but to reinforce what
Marjorie was saying, you can see them coming together perhaps around health
care and then close off what some of these other possibilities are, because
that is where you see the synergy.

I think it is harder to say some of these new areas or new vistas that have
been opened up by the discussion here from the consumer empowerment
presentations, because they don’t as easily connect up with some of the health
care cases or some of the typical discussion around health care functionality
or data flows.

I think that is the point that I was trying to make earlier. You have got
to leave open that possibility of things that don’t hook up yet, may still end
up being part of the NHIN.

DR. STEINDEL: I think, Cynthia, that is a very good point, because that is
what I saw. I saw places in the consumer empowerment that we had to make some
statements in terms of maybe extending the functionality a little bit, so that
when these systems develop, there is a hook that they can come into.

MR. BLAIR: One of the things that I really felt very good about is, even
within the earlier testimony which we might have thought would have had
convergence to some degree, there were little surprises that come up, and they
were good surprises.

One of them was, don’t forget clinical research. Another one was, there is
an importance for — what was it that Blackford said? It starts with an R.

DR. STEINDEL: Non-repudiation?

MR. BLAIR: Non-repudiation. That was a surprise that came in there. When we
tested it, it was real. There is a bunch of these that are coming in, and they
don’t always necessarily come in because there is a different use case. They
come in because there is already diversity on the panels that we have that help
us.

So I really felt that this was a very productive day. And I was nervous
before we came in today, and I am going away feeling that this was —

MR. REYNOLDS: Wait until tomorrow, Jeff.

MR. BLAIR: It all comes apart tomorrow, right? No, this was a good day.

Let me make one last comment about that. I have expressed my anxieties to
Mary Jo, and Mary Jo, this agenda worked well.

DR. COHN: Are there other comments before I begin to close up for the day,
wrap up? I want to thank everyone for coming in the middle of summer for a
session like this. I especially want to thank Jeff and Harry for the work of
putting this together along with Mary Jo. It is great being Chair and going
away for three weeks and coming back and having this all work.

DR. GREENBERG: Don’t make that a pattern.

DR. COHN: Don’t make that a pattern, exactly. And Margaret A., thank you
very much for your involvement in all this.

Now we will adjourn. We reconvene tomorrow at 9 a.m., and we will be in the
room across the way. We will continue to be on the Internet. With that, the
meeting is adjourned.

(Whereupon, the meeting was recessed at 5:12 p.m., to reconvene Thursday,
July 27, 2006 at 9:00 a.m.)