[This Transcript is Unedited]

Department of Health and Human Services

National Committee on Vital and Health Statistics

Subcommittee on Standards and Security

September 21, 2005

National Center for Health Statistics
Auditorium A & B
3311 Toledo Road
Hyattsville, MD 20782

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 [8:55 a.m.]

Agenda Item: Call to Order – Welcome and Introductions – Mr. Reynolds and Mr. Blair

MR. REYNOLDS: Good morning, my name is Harry Reynolds, I am with Blue Cross
and Blue Shield of North Carolina and co-chair if the Subcommittee on Standards
and Security of the National Committee on Vital and Health Statistics. The
NCVHS is a federal advisory committee consisting of private citizens that makes
recommendations to the Secretary of HHS on health information policy. On behalf
of the subcommittee and staff I want to welcome you to today’s hearing which
has a plethora of topics that we’re going to deal with over this next two days.

We are being broadcast live over the internet and I want to welcome our
internet listeners as well. As is our custom we will begin with introductions
of members of the subcommittee, staff, and guests. I would invite subcommittee
members to disclose any conflicts of interest, staff, witnesses and guests need
not disclose conflicts. I will begin by noting I have no conflicts of interest.
Jeffrey?

MR. BLAIR: I’m Jeff Blair, vice president of the Medical Records Institute,
co-chair of the Subcommittee on Standards and Security and to the best of my
knowledge I have no conflicts of interest.

DR. FITZMAURICE: Michael Fitzmaurice, Agency for Healthcare Research and
Quality, I’m liaison to the full committee and staff to the Subcommittee on
Standards and Security.

DR. FERRER: Jorge Ferrer, staff to the subcommittee from the VA.

MS. AULD: Vivian Auld, National Library of Medicine, staff to the
subcommittee.

MS. PICKETT: Donna Pickett, National Center for Health Statistics, Centers
for Disease Control and Prevention, and staff to the subcommittee.

MS. GOVAN-JENKINS: Hi, Wanda Govan-Jenkins, NCHS, CDC, and staff to the
subcommittee.

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

MS. FRIEDMAN: Maria Friedman, Centers for Medicare and Medicaid Services,
lead staff to the subcommittee.

MS. WILLIE(?): Shelly Willie, RxHub.

MR. GINGRICH(?): Mark Gingrich, RxHub.

MS. BYRNE: Teri Byrne, RxHub.

MR. ROTHERMICH(?): Phil Rothermich, Express Scripts.

MS. FERNANDES: Lorraine Fernandes, Initiate Systems.

DR. SCHUMACHER: Scott Schumacher, Initiate Systems.

MR. SHEATH(?): Tony Sheath, Point of Care Partners.

MS. BOYD: Lynn Boyd, College of American Pathologists.

MS. INSLEY: Marcia Insley, VA.

MS. WILLIAMSON: Michelle Williamson, NCHS.

MR. REYNOLDS: Okay, before we get going on the actual first speaker who is
John Halamka and I don’t think, is John on yet? He hasn’t come on yet? First
thing I want to do is pass around to the subcommittee and staff a chart that
we’ve been working on on what our outstanding items are as far as our agenda
and so on, so if you’ll take a look at that, this is updated as of our last
session and if you will take a look at that and I’ll work with Jeff on it to
make sure that we had talked about what we had wanted to do for September
obviously, we have those covered, December, and we started talking about
February, and then we want to spend a little time, maybe five minutes probably
tomorrow just getting any updates you have or any new subjects that you think
we ought to cover so that we can keep this updated and Maria has got some
updates for us tomorrow also. So if you’ll please take a look at that between
now and then.

I’m also trying to get everybody a copy of the minutes so that we can
approve those. Is that the way we do it?

PARTICIPANT: [Off microphone.]

MR. REYNOLDS: Oh, okay, good, so we have none so Jeff and I will sign the
minutes.

Maria?

MS. FRIEDMAN: I’d just like to add that originally we were going to have a
briefing on our claims attachment reg which is scheduled to be published on
Friday and should be on display tomorrow which makes it legal for us to talk
about it. But because I couldn’t be sure that it was going to be on display
tomorrow, we had to pull the briefing and so we would like to offer a
teleconference briefing to the subcommittee for that.

MR. REYNOLDS: Because after we hear that briefing we need to consider
whether or not we want to submit any comments, is that correct?

MS. FRIEDMAN: Yes.

MR. REYNOLDS: So we’ll need to make sure we get in the pipeline as to any
comments that we’re going to want to have on that attachments legislation so
that’s the reason we’ve done it this way.

MS. FRIEDMAN: And I think it will be interesting for the subcommittee to see
how things came out since we did a lot of work on claims attachment a while
back so this is kind of the fruits of some of those efforts coming to the fore.

MR. REYNOLDS: Judy, while we’re waiting for Dr. Halamka why don’t you, Stan,
I’m sorry —

DR. HALAMKA: Hi, this is John Halamka —

MR. REYNOLDS: Judy, why don’t you introduce the topic on matching patients
to records and then we’ll turn it over to you, Dr. Halamka.

DR. WARREN: One of the things that has been before the committee in the past
has been the whole notion of a patient unique identifier and over the years
since that has come up it has come to consensus that that is probably not the
way we want to go in working with patient records and so we’ve been looking for
alternative ways to ensure that we get the right information about the right
patient to the clinicians that need to make those decisions about the patient
and for other decision making bodies. So with that we’ve started pulling
together a series of hearings that are starting today to help us understand
what those approaches are in matching patients to their records so that we can
then make some recommendations based on that. So this is the first go around of
those presentations and so with that I’d like to turn it over to Dr. Halamka
since he’s on a time limited timeframe here. So with that John we’ll turn it
over to you.

Agenda Item: Matching Patients to Their Records – Dr.
Halamka

DR. HALAMKA: Great, and how much time do I have for the discussion?

MR. REYNOLDS: About half an hour or so and then that will leave us about 15
minutes for questions, that’d be great.

DR. HALAMKA: That’s just perfect. So you framed this very, very well which
is we recognize that certainly in a world of nirvana if we could just start
from scratch and everyone would be given 128 bit cryptographic identifier at
birth that was private, secure and immutable and followed them for a lifetime
of health care, boy, that would be great, but in fact can we get there in the
next decade, what about the privacy implications of having a universal
identifier that might be linked to your employment records or to your bank
records, privacy advocates are quite concerned rightfully so about privacy
spills that might result. All you have to do is look at AmeriTrade and
MasterCard and recognize what would happen if you had a single universal
identifier linked to every one of your records.

And of course when we look at just the logistics of issuing new identifiers
and how do we deal with non-citizens who seek health care and of course the
issue that Social Security number is really quite a rotten identifier in that
transposition of digits of a Social Security number occurs in hospital
information systems about ten percent of the time and I trained in county
hospitals as an emergency physician and I can tell you we had the remarkable
circumstance of 90 year old women being reincarnated as 18 year old men with
the same Social Security number so certainly it is not a panacea either.

So given that in the interest of actually getting something done in the next
few years we are unlikely to use an existing identifier or issue a new
identifier and of course overwhelming privacy concerns even if we did that
might prevent that.

What do we do instead? Now do you have the slide stack that my assistant
sent you?

MR. REYNOLDS: Yes, we do.

DR. HALAMKA: Very good. Well our proposal is, and we’ve actually got this
running in Massachusetts and I’ve been running this kind of thing for several
years in the context of integrated delivery networks, associated hospitals and
doctor’s offices, is in the absence of a universal identifier you can create a
probabilistic statistical match of an individual based on demographics and use
that in a virtual way to link all the places of care that an individual has
been. And so let me just talk through that concept and I’ll go through, we’re
on just the agenda slide, I will talk about how one creates this index, how it
can be used in a federated and decentralized fashion, and a secure fashion to
exchange records, show you some of the working prototypes that we have and then
describe the algorithm in some detail and some of the caveats and privacy
concerns about it.

So on to slide number three, high level functional architecture. So the way
that such a system of having an index as a probabilistic match will function is
follows. We recognize that in this country heterogeneity of our hospital
information systems is the rule, the likelihood that we’re going to be able to
adjudicate that absolutely every hospital run the same system or that every
doctor’s office run a common electronic patient record is unlikely.

However, all these various vendor systems and home built systems typically
do have a standard transaction at the point of registration or admission,
discharge or transfer, the standard HL7 segment which describes who is the
patient. So this PID segment as its called, and whether that’s HL7 2.3, 2.4,
2.5 or 3.0, all flavors of HL7 do have the basic elements, first name, last
name, date of birth, gender, zip code, and of course there are many other
elements which include such things as your Social Security number, email
address, etc. But the core data elements of name, gender, date of birth and zip
are certainly stored in basically every system in this country. And so hence at
the point of registration in a doctor’s office or in an hospital that
registration information goes via an HL7 transaction today to many other
downstream systems, a pharmacy system, a radiology system, a laboratory system.
So from a technology standpoint it’s not a leap to say in addition to going to
all these other systems it will also go to a community maintained master
patient index.

And obviously from a security and privacy standpoint there are appropriate
business associate agreements which would be signed between that entity which
hosts the master patient index for the community and the participant because
clearly the notion of storing your name, gender, date of birth, and the fact
that you’ve visited an institution could be disclosing. Example, well if I
visit Beth Israel Deaconess that’s not particularly disclosing, but if I visit
the Betty Ford Clinic and the Gay Man’s Crisis Center clearly the notion that
my medical record number exists in such an institution in itself could be
disclosing.

So we have business associate agreements, that transaction is forwarded off
when a patient is registered for care. Now also recognize just because any
technology we discuss has to have a complementary policy, that it would
certainly be up to the policy of the individual institution in its disclosure
and privacy policy and its consenting policy to have an opt in or an opt out to
the index. And I’ll give you an example, Beth Israel Deaconess think it’s a
very good idea for exchange of medical records in the community in the
interests of promoting quality and safety so it will present to the patient we
as part of your care will simply share these five elements of demographic
information with the community index. However if you wish to opt out from that
you certainly may.

On the other hand McLean Hospital, which is our local psychiatric facility,
is likely to say you know we actually are going to opt out by default, you have
to opt in if you want a notion of your McLean medical record number forwarded
to the community index. So again, recognize we will absolutely ensure good
patient control, appropriate enforcement of HIPAA, and state laws which preempt
HIPAA, and really do engage the community in the decision making on how to run
the thing but the end result is records end up in an index and therefore that
index which itself doesn’t contain clinical information just contains name,
gender, date of birth, other demographic indicators that the community may
decide are important from a matching standpoint, medical record number, and the
institution that was visited.

Once you have that information that can be a record locator system, a
pointer system to where clinical data actually lives. So in the case of Care
Group for example, I oversee about nine million patient records, two and a half
million active patients, six hospitals, and I have a master patient index with
all the entities I interact with and that master patient index facilitates me
to go out and say oh, I see, you were at Mt. Auburn Hospital, you now can go
and do a query against the medical information systems at Mt. Auburn Hospital
because you know the medical record number there and you know that the medical
record number belongs to a patient with certain demographic identifiers.

So if we look at slide three really what it’s suggesting is is that the
system for medical record exchange that doesn’t pre-require a universal health
identifier has a feature by which at each registration that demographic
information with appropriate consent is forwarded to the record locator
service, the record locator services becomes the community wide index which
then can be a pointer system for medical record exchange.

Let me just move on to the next slide and describe an actual use case. So
what we see on slide four is that a patient goes to a clinician, that clinician
offers selected treatment, there are medical records about that particular
patient, and as part of that treatment yes in fact a registration transaction
has been generated, it goes off to the record locator service. The patient then
goes to seek care elsewhere, another physician’s office, a hospital, an
emergency department, and similarly name, gender, date of birth, other
demographic identifiers, are forwarded off to the record locator service, and
the clinician offering treatment at the second site says well, patient, I think
it’s really important that I retrieve your medical list from other places in
the community where you may have sought care. Do you consent for me to do that?
And of course then after the patient gives consent for that look up the doctor
initiates the search, the search then finds that yes, this patient has visited
other sites, and information is retrieved from those other sites.

In an architectural way, let me just go on to the next slide, this, and I
really hate to use this analogy but it fits, in effect you’re building Google
for health care, that is searching of an index, and Napster for health care,
peer to peer exchange of information when you’ve in fact located that
somebody’s information is at a particular site. Now obviously Google and
Napster are not secure and medical grade and all the rest but architecturally
really that’s what we’re doing, creating a registry and then creating a
mechanism by which data will be exchanged.

All of this is standards based, so that implies HL7, standard flavors of
HL7, for the case of medications NCPDP 4.2, very standard way of looking at
medication history, in the case if we needed to do interactions with payers,
for example eligibility information of an aid to figuring out who a patient
might be. Or in the case of Katrina it may very well be that the only way to
recover clinical data is to go to pharmacy benefit management databases which
are hanging off payer organizations. And payers typically speak ANSI X12, the
HIPAA transactions, to identify patients.

So as we architect these various components of both index and exchange we
recognize the underlying the standards exist, are well described, and are well
implemented throughout the country already, so in our state when we went to do
this we actually worked not only throughout Massachusetts with payers and
providers but worked through the Markle Foundation, Connecting for Health,
worked through the folks at Regenstrief and the Indiana Health Information
Exchange, and worked with the folks at Open HRE, a group in Mendocino County
who is doing an open source version of medical record exchange. And we came to
a common implementation guide for this record locator service and clinical data
exchange that utilized HL7 2.4 or HL7 3.0, NCPDP 4.2 and ANSI X12 4010A.

So with those standards and those implementation guides in effect what you
have is a railroad track that runs from New York to Los Angeles all with the
same gauge. And as long as individuals agree to those standards it provides the
basis for a network of national interoperability, so let me talk a little bit
about that.

Now these next couple of slides just give you a sense of when I really talk
about the software components that we’ve created, it’s a bit more complex then
just saying oh, here’s this wonderful index and here’s this clinical exchange
software. We recognize that of course if we’re going to build medical grade
software we need comprehensive auditing systems and comprehension security and
encryption, authentication of those individuals who are going to go and query
the index, making sure that messages go from place to place with integrity,
that they aren’t modified, that go only to rightful locations which have been
certified as participants in the network. And so we’ve done all of this by
creating a modular architecture, happens to be all SOAP transactions, XML
transactions, wrapping around standards based messages that I’ve described.

And we’ve completed this whole software stack that you see on the slide
called service oriented architecture and in January through the Markle
Foundation we’ll be giving all that software away for free and all the
implementation guides for free, and the hope is that the running example of
code will be analogous to the way that the internet itself developed which is
come up with an idea, develop a standard, put out some running code and then
let the world run with it.

The next slide, just to understand, and this is really a recapitulation of
everything that I’ve said, that these software components are in a sense like
fax machines, you don’t need one giant fax machine in Washington, no, in fact,
everybody can have a fax machine as long as they speak a standard way of
interchange of data you can have thousands of these things and they can
interact, publishing information indexes, there may be regional indexes, there
may be city wide indexes or state wide indexes. Queries to those indexes can be
made and medical information exchange can be done using a set of standards.

So let me just go to the communication between record locator services
concept, talk through a use case here. So imagine that Massachusetts has an
index of all of these patients, so I’ve got in the case of my records nine
million historical records and there are only six million people in the state
so some of my records are for deceased people. But let’s imagine that
Massachusetts ends up with this fairly large index of say nine to 15 million
individuals that we have comprising the Beth Israel Deaconess, the Brigham and
Women’s, the Mass General, and our 5,000 doctors. Well Indiana, through its
medical information exchange, has also put up a record locator service, how is
it that a doctor in Massachusetts can speak to the Indiana information exchange
and do so in a way that’s guaranteed to be secure?

Well, to build an architecture that requires that every single participant
in Massachusetts and every single participant in Indiana have business
associate agreements, have trust relationships and gee, the folks in Indiana
need to know the granular details of how our institutions function in
Massachusetts so they don’t know, hey, is Beth Israel Deaconess a good or a
reasonable hospital. It’s crazy, so what we’ve said is let’s recognize that we
will have a regional record locator services and that we will build a network
of trust across those record locator services, something to this fashion, so
that in the state of Massachusetts we have let’s say 50 acute care facilities,
those 50 acute care facilities we say are all trusted members of our record
locator service.

And those trusted facilities have the delegated authority to offer their
credentialed doctors access to the index, they take responsibility for the fact
that the doctor is on staff, credentialed, if they use the index
inappropriately they would be terminated. And so therefore if you are part of
the Massachusetts record locator service system and Massachusetts and Indiana
agree to trust each other, any doctor who’s appropriately trusted by
Massachusetts could go query the Indiana system using what we are calling an
IRP, or intra RHIO proxy.

Now I recognize that that’s jargonish, the idea basically is is that a
record locator service in one region can communicate to a record locator
service in another region so that you don’t have to have the nastiness of
trying to authorize every single doctor in the whole country to talk to every
single one of these record locator services, you authorize a doctor regionally,
they use one regionally, the regional one can query other record locator
services.

And architecturally, will there be 50 of these, will there be 100 of these?
How many RHIOs will there be? Questions that are a bit unknown but let’s just
suggest there will be a relatively finite number of record locator service
indexes so the technology problem of having them trust each other and afford
communication with each other isn’t that bad, it certainly would scale.

So just next slide which describes overlapping trust relationships, this is
really just the gist of what I described, which is if you have a series of
indexes of individuals spread across the country and maintained by individual
RHIOs or communities and there is this transitive trust concept where it’s a
federation of record locator services that each trust each other, it suddenly
now makes the problem of authenticating the doctor and ensuring trusted
participants participate in the network a much more straightforward issue. We
don’t need a nationwide certification program for the users or a nationwide
certificate authority, we can defer that in a decentralized but federated way
to the communities who actually know who these doctors are and once the
community trusts them and communities trust each other communication can occur.

The slide which described distributed authentication just notes that the way
technology wise that record locator services identify each other is using a
standard cryptographic certificate method, an X.509 method, which says I only
need a certificate for each record locator service participating in the
network. A doctor would use a strong user name and password, authenticate into
the system, once in the record locator service record locator services can then
justify themselves, identify themselves to each other using certificates and
their record locator service.

And so all of these things that I’ve described, building an index,
populating the index, ensuring security, doing clinical data exchange, do not
require any new standards whatsoever, just implementation guides on existing
standards. So that’s certainly important as we think about the standards
harmonization effort.

The other thing is this is not vendor specific in any way. One of the things
we have really tried to do is to say as long as you’re going to be sending HL7
messages from place to place whether you use Microsoft technologies or Sun
technologies or Python or Pearl, we just don’t care, so the slide that’s called
prototype components layers and platforms just illustrate that such an
architecture is truly vendor neutral and any vendor who wished to participate
in such a network of indexes could do so without requiring any proprietary
technology.

To show you how this actually looks, and then I’m going to talk through a
little bit of the actual algorithms that are matching in the minutes that I
have left, so we go to the record locator service, then as you see we have a
user name and password, we also have a security disclaimer. And underlying all
this remember are those business associate agreements so that from a HIPAA
perspective and a state perspective we ensure that trust relationships and
using this data appropriately are enforced. In the case of Beth Israel
Deaconess and my associated facilities if a clinician violates a business
associate agreement or this trust they are terminated, and I do have three or
four terminations a year, typically these are clinicians who look up their
neighbors or look up their spouses who they’re divorcing or other things that
are obviously unethical and inappropriate. We really rarely have people who are
just simply out there fishing for data.

So we log in, then you’re asked to enter the name, gender, date of birth,
and zip code. Once that is entered, and I’ve just given you the example of John
Clark, 4/1/1927, you get a zip code, the record locator service begins a search
of that index and recognize that there are many strategies that could be used
to search the index. The simplest of course is exact match, a John Clark, a
birth date, a gender and zip code. But wait a minute, what if John is J o n,
hmm, well, is that an exact match or not? Well, in the exact match strategy,
because it’s looking at spelling and case and spacing and dates and everything
exact match is a pretty blunt algorithm. If you have a nickname or a
misspelling, Johnny as opposed to John, a match would not occur.

So a more sophisticated way to do the match would be to say we will use an
algorithm, and there are many such algorithms, the Advanced Linking Technology
algorithm, Initiate Systems has an algorithm, the folks at Regenstrief have an
algorithm, typically these work by saying okay, I will actually allow a bit of
fuzziness, if a date is typed in but it’s a perfect transposition of the
month/month, day/day, year/year, so instead of 01/05/1920 it’s 05/01/1920, ah
ha, I do allow that because that is an understandable typo. There are nicknames
that are valid for an individual, there are soundex(?) or nicest
transformations of names such that my name, Halamka, I tell you, people
misspell this like you can’t believe, so maybe as long as the name sounds
identical but it may be spelled slightly differently then that’s okay.

Well such an algorithm obviously has a whole range of as you can see from
this slide labeled screen flow probabilistic match and score, of possible false
positives, the possible false negatives. In our case what we have said is the
algorithm needs to be tuned such that false positives are very, very bad and
false negatives are acceptable. So that means if I type in John Halamka and in
fact get Jane Halamka’s records that show I’ve had twins, that’s bad. If on the
other hand somebody registered me with completely the wrong birth date and
called me Jim instead of John and you missed that one, well, we’re willing to
tolerate a miss in the interest of delivering to the doctor that information
which is accurate. So allow some blop but don’t allow those false positives and
tolerate some degree of false negatives.

This particular algorithm is in use today by RxHub with 155 million covered
lives and to give you a sense of how that algorithm performs, and again
everything is tunable, but what they say is that they are currently just with
no editing of the data quality, and we know data quality coming in from most
hospitals is awful, without an army of people doing any manual clean-up they
are getting a 95 percent hit rate on just using name, gender, date of birth and
zip, and to date have tuned it so their false positives are vanishingly small,
so basically it just doesn’t happen.

You have flexibility as a country, as a community, as a RHIO, of figuring
out what the right threshold is and probably as part of a policy that we
adjudicate as a country we set such a threshold that allows us to find the
medical information of individuals appropriately through the index but
discourages random fishing, so that if I type in Ted Kennedy, no birth date,
it’s not going to list for me oh yes, there’s a four year old in Springfield
and there’s this guy in Hyannis Port, no, that’s not enough information to do a
valid search and I’m going to return any valuable information to you. In our
case we’ll set the threshold for the community in a way that balances the
doctor’s need to know with privacy and minimized incidental disclosure.

So just once you have used this record locator service, this index, to find
the patient, you then can go with the medical record numbers that have been
retrieved and fetch clinical information, and I just purely as a test bed show
you examples of how we’re pulling out clinical encounters from various
participants in our network.

We have populated our record locator service in the state of Massachusetts
with 500,000 patients and in the interest of using this for testing to make
sure all the software works and the algorithms work we have created, although
it’s the same names, genders, dates of birth, we have randomized assorted the
columns so that Ted Kennedy is now named Phil and he’s a four year old living
in the western part of the state. All the names, genders, dates of birth are
appropriate, they are distributed in a way that is truly non-disclosing for
testing.

And the administrative aspects of this are that we can set the threshold and
we can set the kind of search engine that we are using to match as an exact
match or probabilistic match, and that we do have features that allow us to
publish records or edit records that are in the record locator service if
that’s something that’s necessary to do and that’s just shown in the next two
slides.

So just a couple of comments on this matching algorithm, one of the things
we have to be very careful of is that we’re very transparent about how the
matching algorithm works, so I’ll give you an example. Early testing that we
did at a distributed use of the record locator service said that a doctor could
go type in name, gender, date of birth, and then we could go out and search, we
would do this probabilistic match and we would return date.

Well, it’s pretty important if you have actually returned a patient’s
information with a birth date that’s different, or with a gender that’s
different, or with a name that sounds the same but spelled different, that you
tell the doctor you did that because in fact it may very well be rare if you
tune the algorithm appropriately but it may be that in fact you have returned
that false positive and by saying to the doctor you typed in John Smith, I
return it John Smyth, so do note that this record is spelled differently and
it’s up to you whether you think that’s appropriate or not.

I will tell you because we have tuned our algorithm at this point to avoid
those false positives, we really just, if it’s a Smyth as opposed to a Smith,
it’s sounds different, we aren’t returning it, so but nonetheless, disclosure
of any information that’s substantially different from what the doctor queries
is important in a probabilistic match.

So just describing those thresholds, you can see if we put in a record John
Q. Public with a given Social Security number, date of birth, etc., and we
search on that individual, we could get a pretty high score, a pretty high
likelihood or probabilistic match. But as you change elements of the
demographics, John, J o h n, becomes J o n, well, that matches a little less
well, J., the first initial, that matches a little less well, change the last
name, that’s even much worse, and you can see just how such a algorithm based
on looking at names, nicknames, distributions of zip codes, etc., will
adjudicate how close or how far a match is and you search the threshold
appropriately.

So in conclusion I have been doing this kind of thing live in production
since 1999 and, so with nine million patients and it’s the way that the whole
Care Group system works today, to create a distributed index of retrieving
patient information. Going beyond the walls of Care Group and going to the
whole community is then an effort we have gone through the last six months as
part of our RHIO activities, and at the end of the month I have a board meeting
where we’re making final decisions on moving into production on a couple of
possible use cases, for example the Brigham and Women’s and Beth Israel
Deaconess sharing records using this common record locator service concept,
using this as a way to tie together our community health centers who all have
disparate medical records. So over the next year there will be some very good
publicly available information about how this worked in production and a huge
educational effort to ensure patients understand what we’re doing and how we’re
protecting their privacy is obviously part and parcel of all of this.

So let me now open it up to your questions and thoughts.

MR. REYNOLDS: Okay, John, thank you very much, that was excellent. I’d heard
a lot about what you were doing in Massachusetts but that’s pretty interesting.
Jeff has a question.

MR. BLAIR: Hello John Halamka, this is Jeff. How are you?

DR. HALAMKA: Doing very well, thanks.

MR. BLAIR: Good. Thank you for the presentation and thanks for the
achievement that you’ve been able to pull together in Massachusetts, as well as
the inter RHIO protocols that you’ve also initiated. Since you’ve been running
this system now since 1999 you’ve probably had one or more occasions when
you’ve been able to hear some legal opinion about what areas might be
vulnerable to challenge and which ones you feel reasonably safe on. Could you
give us some feedback on that?

DR. HALAMKA: Well, absolutely. So one of the great challenges is the
Massachusetts regulatory environment is much more severe then HIPAA and of
course you look at all the privacy rules throughout the country you’re going to
have a dizzying array of diversity where for example in California I’m told a
consent on an electronic screen is not perceived appropriate enough, in fact
you need a handwritten consent from the patient before you could even look up
their records. So typically what I find is that the issues all legally revolve
around how to do consent, opt in, opt out, what is the form of consent, can one
organization serve as the proxy, getting a consent for another organization.
What if information is inappropriately disclosed should in fact the person who
did the consent be liable or in fact should the releasing organization be
liable for that inappropriate release of information?

So I’ll tell you that in our communities we’ve seen two attitudes, and I
just find this very interesting, there are doctors that are part of our $50
million dollar Mass E-Health collaborative where they’re just getting
electronic medical records for the first time, and they’ve said you know I buy
into this idea of sharing medical records across the community but I really am
most comfortable with an opt in strategy. I will as the patient registers for
care for the first time in my new electronic medical records system ask for
their consent to share their demographic data with a record locator service.
And I don’t have any data anyway right now so there’s nothing for me to
pre-populate, so that opt in, go as you go, well that makes sense.

Larger organizations like Parkers and Care Group have said boy, we have
millions of records and we think there’s huge value to the community for
quality and cost reduction, of sharing data in a way that is opt out and gets
consent at the point of care, but boy, for us to hit everyone of the nine
million historical patients we have and ask for their specific permission to
opt in to data sharing, that will take such a long time that the system will
never be used by doctors because they’ll get so few hits.

So those organizations, which have the staff to do the consenting process
and are willing to take the burden of doing a proxy, that is I’m going to look
up partners information, I’m going to go ask the patient do you consent that
I’m going to go look at your Mass General records, I’m willing as Beth Israel
Deaconess and Care Group to take on that responsibility and effort.

The lawyers as you’ve said sort of argue both ways saying boy, this opt in
consent to a record locator service is your most risk averse conservative
approach, no one is going to be able to challenge that. Well, this idea that
you can do it at the point of care, well, no one has ever sued over that but if
they did the law is a little murky on that.

So those are the basic issues. I should also just say that one of the
strategies that we have adjudicated in our state is no centralization of
clinical data. You’ll see this record locator service is an index which has
nothing more then demographics and medical record numbers, but we don’t put all
the labs or all the meds in any central database, it’s all very much peer to
peer, the data lives at Beth Israel Deaconess and Brigham and other places. And
we call this the Karate Kid defense because in that movie, long time ago, said
the best block is not to be there. So in fact if you don’t have a database of
medications that can be hacked at a global community or RHIO level, that’s a
good protection, and that has actually as we think about the architecture and
selling it to the public, the idea that we’re only aggregating pointers and not
their data itself does in fact make the public feel more comfortable.

MR. REYNOLDS: Do you have another question?

MR. BLAIR: What kind of reactions have you had from patients when they’ve
been asked whether to opt in?

DR. HALAMKA: Well, so two reactions. When you think about the fact that
we’ve been using something called Care Web 1999 for all this data sharing
across Care Group, to my knowledge in the course of the last five years, six
years, there have only been one or two patients who’ve said gee, I’m actually,
I don’t want my data shared across the doctors that are caring for me, I mean
extremely rare that folks when they understand how this will be used by
credentialed doctors at the point of care for serving them, they feel fairly
positive about it. I think the worry is that as you create a RHIO, well, will
my employer have access to the RHIO? Will my insurance company have access to
the RHIO? That’s I think where the doubt is, it’s not clinician to clinician,
it’s the fear that governments, insurers, and employers will suddenly learn
things about you they shouldn’t.

MR. BLAIR: Let me ask, you had mentioned as you were describing some of the
scenarios where you might have a patient that is going to a psychiatrist and it
is possible that the psychiatrist may have prescribed either antidepressant or
other medications. And if they then go to someone else because maybe they have
sleep deprivation problems or other problems and that person winds up then
asking for permission, and if they do to a general practitioner, internalist,
family medicine, and will the records from the psychiatrist then show up in
terms of a drug to drug interaction problem and if not what about the patient
safety implications of that?

DR. HALAMKA: Right, a very good question and I have two answers, which is at
the record locator service level if the psychiatrist for example in discussing
with the patient the sharing of data had, the patient had opted out, well the
patient’s psychiatric pointers would not be included in the record locator
service. But let’s assume that the pointers are in the record locator service,
doctor to doctor exchange for treatment, payment and in operations with patient
consent is okay in our state but what’s funny is that there is actually a
regulatory restriction on getting data from payer based claim systems such as
PBMs that have mental health, substance abuse, of HIV implications. So this is
a true statement, I’m an emergency physician, if a patient comes to me and says
hey John, you have my permission to go search Express Scripts and RxHub for all
of my medications including psychiatric, HIV and substance abuse medications, I
can’t do it, we actually have to in front of RxHub maintain a restricted drug
list that strips out all those medications that might have a psychiatric
implication. And in fact we’re working at Beacon Hill right now to get that law
rescinded but doctor to doctor sharing fine, in the interest of protecting
privacy laws were put on the books years ago saying that claims and pharmacy
benefit management companies cannot be released unless the payer specifically
consents to the patient, not the doc.

MR. BLAIR: This is really significant then because effectively what you’re
saying is that despite the system that’s been created in large part to protect
patient safety if that patient has substance abuse medication or sexually
transmitted diseases or behavioral health medication they’re filtered out of
the system —

DR. HALAMKA: Right.

MR. BLAIR: Any of those could be a drug to drug interaction and so the
physician is left in a situation where he probably has to sit down and say you
need to tell me what medications you’re taking for any of these other areas.
Does that happen where they wind up saying you need to tell me what these
other, here you’re coming into an emergency room, I need to treat you, I need
to know these medications before I can proceed, or how does the physician get
protected from providing a medication that will have a drug to drug interaction
and have a severe adverse reaction, how do you deal with that?

DR. HALAMKA: Right, and so you’re exactly correct. The problem that Dr.
Brailer has today is that we’ve got HIPAA, which is a wonderful federal law,
but we got state preemption and so until we harmonize privacy and security laws
and practices across the country we’re going to run into these regional gotchas
like this one. Now ultimately because doctor to doctor exchange of data is okay
once we connect every EMR in the state to our network things will be fine but
for the moment, because I do want community wide medication information
exchange, the best way I can get it is by going through RxHub because the PBMs
do have a list of all the medications that were reimbursed and therefore it’s a
good way for me to at least give a proxy to the active medication list, and you
can see that it does have problems. And so what we obviously do is when we have
doctors using that query we say note, this medication list may be incomplete
and should be validated or verified with patients. But hey, I’ll tell you, it’s
bettering then nothing, instead of their 12 meds you get ten of them and that
actually does help quite a bit.

MR. REYNOLDS: Stan, you had a question?

DR. HUFF: Hi, John, Stan Huff. Thanks a lot for testifying. My question
takes a little different tack. I think you presented a convincing case that
this is what we need to do five years, ten years, just because it’s what we can
do in that timeframe. I wonder what your thoughts are if, should we start doing
things so that ten or 15 years from now in fact we’re doing something in a
better way or if in fact you would think that we can do now is in fact what we
should do basically forever.

DR. HALAMKA: Fabulous question.

DR. HUFF: Let me just throw out, posit some does the emperor have any
clothes kind of questions. At a grand Gestalt level you could say now how is my
privacy improved by the fact that the very information I’m trying to protect is
in fact what passes between these entities to identify me in terms of my name,
birth date, address, etc. Secondly you could argue even though again this is
the best we can do, in fact if we started planning now are there ways that this
could be done more efficiently so that people have cards and other things and
what cost reductions could occur in this process if we planned a process to
have this work as efficiently and effectively as it possibly could. So those
are just some of the issues that I would raise in that context about should we
start planning now for a better more efficient way, could such thing exist and
what would it look like if it did?

DR. HALAMKA: Sure, and so the beauty about the record locator service design
is a national health identifier if ever implemented in the future just becomes
another piece of data, another demographic indicator in the record locator
service. So in fact if you have one, great, we’ll query by it, if you don’t
have one, okay, we’ll use probabilistic matching. So there is absolutely no
reason why you couldn’t do this now in the next five years the way we do
business but hey a decade from now we do have a national health identifier but
it’s going to take five more years to roll out and that’s fine, it becomes a
gradual addition to the record locator service.

What Norway does that I think I just simple and instructive is that they
simply give every baby at birth a national identifier which is the day they
were born and their birth order, so okay, you’re the first baby born today,
okay so you are 01/01/1962 number 1, and then they just crank up for the number
of babies that are born that day and this is a very straightforward way to deal
with the identifier. The problem they have had of course is that what do you do
with immigrants? What do you do with non-citizens? And so it’s quite funny,
I’ve advised Norway on this, is that they have, many of the time when folks
immigrate they don’t have a birth certificate, they don’t know their birth
date, so they just give them 01/01 of the year they think they were born. The
probably that Norway is having is they’re running out of digits because so many
people are born on 01/01.

But the bottom line is I concur a parallel strategy just recognizing that
the issuance of a national identifier is a big, big project and it will take
many, many years and be very, very controversial and the short term strategy
I’ve outlined supports the eventual use of a national identifier should that
ever come to pass.

MR. REYNOLDS: Michael?

DR. FITZMAURICE: John, Mike Fitzmaurice, I have a question, you’ve probably
answered a good part of it and that is I see you’re using a subset of variables
about me to identify me that could just as easily invade my privacy as Social
Security number, and probably the same data are on all my credit cards, or the
databases behind my credit cards. So the real protection you’re offering is the
authentication access to the index and to the medical record data itself and so
to me to my mind it doesn’t matter whether Social Security number is used or a
national patient identifier is used, it’s not the number that should be
controversial, it’s how well the data are protected that it links. Your
comments.

DR. HALAMKA: Right, I think if you ask individuals how they feel about
specific demographic indicators, and this is just a focus groups we run, people
believe that it is, rightly or wrongly, that given name, gender, date of birth,
identity theft is unlikely. If you’re giving Social Security number, oh, that’s
the bad one, they can steal my identity with that. And so at least from the
public’s perception the idea that we are having a somewhat inexact match and
it’s based on commonly available information about you as opposed to something
that is secret, like your Social Security number, it’s more acceptable to them,
perception.

MR. REYNOLDS: Simon? This will be the last question.

DR. COHN: John, good morning. Listen, I had a question, obviously if one is
supportive of this particular approach, I think as you move from a localized
environment such as you have to sort of the national environment that you were
describing, it seems that one would want to have standards around the data
elements that one is using for all this stuff, and I guess I’m asking that
question knowing that obviously that one can tune up or down the probabilistic
matching algorithms. Now is that a reasonable assumption here? And if indeed
that’s the case how much variation is there in terms of all the data elements
that are used from one environment to another?

DR. HALAMKA: So a couple of examples there, in Massachusetts we believe that
name, gender, date of birth and zip are good matching criteria, in Indiana they
really, really want to use the Social Security number. And so that’s fine, what
we’ve said is the PID segment in the HL7 2.X standard affords you a lot of
possible demographic identifiers, we would simply mandate those that are
required versus optional and an individual community could use some of those
optional identifiers as a mechanism of refining the match, ensuring better
accuracy and fewer false positives. But you do at least have to start with the
basics and of course gender, well, I trained in San Francisco and our triage
sheet in the emergency department had five possibilities for the gender box,
male, female, unknown, other and in transition. So you better decide as a
vocabulary if you’re going to use name, gender, date of birth, well, what are
the possible genders in that vocabulary and that’s where the implementation
guide comes in. So common standards yes but then common implementation guides
for that standard that specifies issues like vocabulary and mandatory versus
optional fields.

And one of the things that I’m happy to provide the committee is that we do
have an implementation guide that’s quite detailed covering the HL7 2.4 and 3.0
standards and all vocabularies, it’s finished and certainly available for your
records.

MR. REYNOLDS: I’m going to let one more question come in, John, from Judy,
since she talked you into talking to us.

DR. WARREN: Hi, John, this is Judy Warren. I just had one question that your
answer to Simon stimulated. If we have these standards for the data what
relationship does the standards have to the algorithm that’s used? Can we have
different algorithms depending on companies or do we need to have some sort of
standards applied to these algorithms?

DR. HALAMKA: And that is a really great question because what we’ve said is,
in our prototype designs we are allowing different search engines, exact match,
Initiate algorithm, the Regenstrief algorithm, but the challenge to me is if
these algorithms have very different statistical performance you may very well
go to Indiana and do a query, allowed to get an incidental disclosure about
somebody’s home address that wouldn’t happen if you were in Massachusetts, so
that at least at the beginning we are mandating that certain fields we required
and certain thresholds be set and we attempt to minimize fishing. But you’re
right, in a long term if we’re going to achieve the same performance that every
participant then there may need to be some adjudication of the form of
algorithm for search. Could be done.

MR. REYNOLDS: John, this is Harry Reynolds, on behalf of the committee I’d
like to thank you for your testimony and we’ll all anxiously keep an eye on
what’s going on in Massachusetts and thanks for fitting us into your schedule
today.

DR. HALAMKA: Well absolutely, sorry I couldn’t be down there today, I have a
delegation of Japanese visitors that flew in and alas I couldn’t be with them
and with you but I live by email so if you guys need anything from me please
email me.

MR. REYNOLDS: Okay, thank you, John.

Our next presentation on the same subject will be from Lorraine Fernandes
and as Scott Schumacher is here today I think too, I don’t know whether he’s
going to participate or not.

Agenda Item: Matching Patients to Their Records –
Ms. Fernandes

MS. FERNANDES: Good morning everyone. I’m Lorraine Fernandes, senior vice
president of Initiate Systems Health care Practice. I am a health information
management professional by training, so I’ve spent about 25 years in my career
doing one of two things, either running large medical record health information
departments in provider organizations, or in the last ten years or so dealing
with the challenges and issues, providing products and services around patient
identification. So I thank Judy for inviting us here today to share with you
some detailed information and some common industry practices and experiences
around patient identification and patient matching.

I’ll let Scott introduce himself as I turn the program over to him about
midway here, but just briefly Scott is our chief scientist and responsible for
algorithm development and the integration of the Initiate algorithm that you’ve
heard John Halamka talk about. You also heard John talk about the Advanced
Linkage Technology algorithm which is an earlier algorithm we had out in the
industry. So we’ll give you a tour of the industry and what the health care
industry as well as a few others are doing around patient matching and patient
identification.

Here is an overview of what we’re going to discuss for the next half hour or
so, we will talk about patient identification technology and how it is widely
used in the industry, in the U.S., Canada, and other countries in the world
there, and we’ll give you some brief examples through some of our clients and
other components of the industry that actually have been using this technology
as a foundation for patient identification and the development of an electronic
health record.

So as you well know managing the patient identities across a health care
ecosystem is complex, there’s a lot of moving parts to the health care delivery
system. It’s not just hospitals, it’s not just physician groups, it’s almost an
endless stream of places we may interact for getting care, delivering care on a
day to day basis in regular. And it’s not only electronic records that are out
there today, you’ll hear a lot of things in the industry that talk about how
many manual records are still out there today and it’s very true, a lot of
statistics say that only 25 percent of physicians are really practicing
medicine using electronic health records but the technology can deal with the
fact you’ve got varying standards, you’ve got varying messaging structures, and
you have both a mixture of electronic as well as manual records out there.

We’ll talk briefly about a national health care identifier, why we do not
believe it’s the silver bullet or the magic bullet to actually doing the
linking and the matching of patient records that are out there today. Scott
will specifically discuss with you the algorithm that you’ve heard John talk
about, particularly the false positive and false negative issue, it does
generate a significant amount of interest out there, how do you manage that,
how do you set patient expectations, how do you set clinician and provider
expectations around the data that’s going to be presented using a probabilistic
algorithm.

We’ll talk a little bit about Canada and our friends a little bit north of
the border here. In some ways they’re a little bit ahead of us in this
discussion and we’ll fill you on things they’ve done over the last few years
and how they’re actually deploying this technology today in Canada to
facilitate electronic health records and the exchange of data within the
provinces and across the provinces.

And last and throughout our discussion we’ll talk about the federated
architecture that John has already given you an overview of and how that’s
available today, used in health care widely, as well as outside of health care.
So that’s the tour we’ll give you through patient identification and data
matching.

The person identification technology is widely used in the health care
industry today. As you can see here we cite some basic data points out there,
we have analyzed over two billion records from the health care industry, many
of them several times unfortunately, as they evaluate, deploy, clean up,
standardize, whatever, the patient identification data out there. There are
about 1400 health care facilities in fact using this technology today to
facilitate accurate and consistent patient identification and the
implementations that use this type of technology scale greatly, deployments of
500,000 records maybe to 500 million records, so the technology is there, it’s
very robust, it’s very scalable, and you don’t have to sacrifice accuracy for
scalability, privacy, or security.

On the right hand side here you see some examples of industries and specific
adopters of this. At the very top one you see Partners Health Care in Boston
that uses this technology to facilitate accurate patient identification at the
point of care. You’ll see RxHub is the second one there, and Teri is following
me today so I won’t go in great detail about that. But as John said they use
this technology in their PBM deployment to manage identification of their
patients and customers.

The third bullet here probably is what you’ve heard most about John, this is
the CSC prototype that John described for you that uses the Initiate algorithm
as one of the algorithms in their development of the prototype to facilitate
patient identification.

And the last one I would ask you to focus on for just a moment, I think it’s
quite interesting, and that’s the PAML one, where they use in a large reference
lab in Spokane, Washington, they use it for two very different reasons, they
use it to facilitate developing a single bill for a patient in order to only
have one bill go to perhaps Lorraine Fernandes, even though I’ve had three
different types of lab tests maybe from three different providers, maybe one
was Blue Cross, maybe one is my auto insurance, maybe one is an unemployment or
a worker’s comp claim, so they bring all of that together with this type of
technology to send a single bill to a patient. They also use the technology to
facilitate bringing all those results together in order to present a single
view of the lab data to the authorized clinician who wants to see historically
what’s happened with the lab data.

And last but certainly not least the Social Security Administration is using
this technology in a proof of concept today to facilitate physician matching
within the Social Security information and yesterday we got word that in fact
the Veterans Administration is licensing this technology to facilitate patient
identification across the various points of service in the VA. So it is
technology that’s widely used, scalable, and has been adopted for many years in
the health care industry as well as banking, finance, telecommunications, and
other types of industries.

In the U.S. as well as the rest of the world I think we have great
expectations for what’s going to come with the gradual development and
deployment of electronic health records. We expect that we’re going to have
improved patient care, we’re going to have a reduction in the redundancy of
testing today. You read many studies that say anywhere between 15 and 25
percent of the tests that are done in the health care system today are
redundant because the health care providers either can’t find the paper record
or don’t in fact have access to the electronic record because it’s at another
point of care that they’re not authorized to get today.

What we believe you’re going to see in this is a gradual deployment and
evolution of creating really a virtual electronic health record because you’re
going to have clinical data that’s going to reside primarily in the sources
where it was created, where it’s maintained, where it’s monitored for privacy
and security by the health care provider that in fact created that and has the
relationship with the patient. So this virtual health record or medical record
as it evolves over time is going to have great expectations, going to have
great benefit to the health care delivery system and ultimately we should have
perhaps along a parallel pathway a personal health record that you and I could
each develop with whatever vendor or process or product we choose so that we
have control of our records as well as the provider and the various places
where the data may have been created.

I alluded earlier to a complex health care ecosystem and this is obviously a
very busy and a very complex slide to really illustrate the point that the
evolution or the building of the electronic health record is going to be
gradual, we’re not going to have a big bang theory in the United States like
you might have in other countries, you’re going to have many components to the
building of the electronic health record, the RHIO that John has talked about,
the National Health Information Network in whatever form that actually takes
places.

As this is evolving you’re going to have a mixture of messaging standards
that are related here of timeframes when people can actually share data because
there is a lot of manual data around yet today. You’re going to have skill set
issues perhaps in the various components of the health care delivery system.
Large IDNs are going to have large IT shops so they’re going to have
sophistication, they’re going to have depth of talent there to deploy an
electronic health record and an electronic medical record on a timely basis.

Judy asked me if there were challenges we should address in this
presentation and there probably is one that’s noteworthy. In the business of
this slide here you see the different messaging, you also have a hint of the
different standards that exist out there, so as a vendor you have the challenge
of deciding do I develop my product to apply to HL7 2.3, 2.4, 2.5, 3.0, DICOM,
ANSI, and the list goes on and on. While patient identification technology can
address the plethora of standards we have out there it certainly is a challenge
as things evolve in the health care system.

And from a development of this ecosystem to sharing data obviously the
multitude of standards you have out there does make it challenging when you
start to talk about how you’re going to communicate RHIO to RHIO, what type of
standards might each RHIO have in place, and how are you going to build that
community network. As I said the patient identification technology can deal
with the multitude of standards, it just makes it a little bit more
challenging.

Let’s spend just a moment talking about the national unique health care
identifier, which we obviously do not have in the United States today. Should
we ever develop one it would just be another piece of data that a probabilistic
algorithm that Scott is going to talk about would utilize in facilitating
patient identification. A unique health care identifier wouldn’t be the silver
bullet, you’re still going to have some type of algorithm to facilitate patient
identification in addition to having a unique health care identifier because
let’s face it, human beings make human mistakes. You make typographical errors,
grandma brings the child in instead of mom or dad, you don’t have your card
with you, and the list goes on and on of why even with a national health care
identifier you’re going to have a challenges with patient identification.

Deploying a national health care identifier in the U.S. would be a long and
expensive process, it would probably take many years even after we had
consensus of what we needed to do and how you would do it. You would have
significant challenges with retrofitting the legacy systems that are out there
today. Many of them probably wouldn’t be able to have a field to accommodate a
national health care identifier and therefore would have to probably replace
systems at some point in the future.

Lastly you’ll note that Connecting for Health and specifically the white
paper on the back page there that talks about accurately linking health
information, Connecting for Health did discuss this in a fairly extensive way
in 2004 when the workgroup met and decided that while we might have one
someday, and might is a loose term there, it would just be another data element
to facilitate patient identification, it’s not a silver bullet.

So let’s take a look quickly at what it might look like to have a federated
approach to patient identification where the clinical data resides at the point
it was created and yet you have as John gave us an orientation a community type
index, a RHIO type index that facilitates patient identification. You’re going
to have many data sources that might contain that demographic information, that
basic information about a patient. There would be queries to some type of
identify hub that each RHIO would have, that query or search would be done
using some basic demographic information, name, address, zip code perhaps,
telephone number, perhaps Social Security number if some of the RHIOs might use
that. We would commonly see probably somewhere between four and eight data
elements used to facilitate that patient identification, yes, there are people
out there who use probabilistic algorithms today that will perhaps use ten or
even 12 data elements to facilitate patient identification, but it’s about a
handful that you see commonly used out there and it is the customer’s choice as
to what those data elements are that are used.

So we’ve done a query for Robert Johnson using these basic data elements of
name and date of birth. What you might get back from that type of query could
vary significantly from RHIO to RHIO as the networks evolve. This particular
example shows that you’re going to get back the facilities where Robert Johnson
in fact has data, the local medical record number for that facility, the last
date of service, the matching demographic information from the institution that
in fact has data for Robert Johnson as well as Robert’s date of birth.

Now whether you show the last date of service is obviously a business
decision that each local provider and each RHIO would make based upon whatever
their business model and their community model has been developed in that
organization. You might also have some basic clinical data that would be
represented there, perhaps you’re going to show the last ER visit, perhaps
you’re going to show allergies or medication reactions, things like that. So
the level of detail that would be presented back to a query as I said would
vary from RHIO to RHIO based upon their model of business and what the
community has supported in that particular area.

You have managed privacy and security, you’ve created a balance with this
type of federated approach, you’ve only maintained the clinical data at the
local level there, it’s authorized with appropriate queries after the patient
identification is made using a probabilistic algorithm. By doing this you have
safeguarded and kept just a very limited amount of data at that centralized
level, the few data elements that are in fact needed to facilitate patient
identification. You still have the ability to audit who had access to that
data, what data elements were presented to that particular person doing the
access, so it is important in the context of privacy and security to have
auditing mechanisms in place even at the basic level of patient identification
and the technology can accommodate that.

You can do this on a very large scale, as I said there are deployments with
this technology that approach 500 million records. You can do this quickly,
this is not a year long or years long process, deployments can be done in a
matter of six months depending upon the resources that a particular client can
bring to it, some even can do it quicker then that. So you can do it
accurately, consistently, in a minimal amount of time, and yet not disrupt the
work environment for the health care delivery system as it is today.

I’m going to turn things over to Scott who can talk to you specifically
about the technology.

Agenda Item: Matching Patients to Their Records –
Dr. Schumacher

DR. SCHUMACHER: Good morning, thank you for inviting me, I’m actually a
probablist by training and so it’s always exciting to me when there’s
widespread or at least some interest in the things that I find I spend most of
my time with.

A couple points before we start on going down into the algorithm and I want
to walk through the algorithm, what are the issues with it, the data that go
with it, how you develop it, what are the points to it, how well does it
perform. But really in terms of doing this there’s two components really to put
together an identity hub or an identity matching system and one is a database
component, a software component. It’s very key that you have a system which can
scale to large databases into high search rates and that’s as much algorithm as
it is software development. But the portion I’m going to talk about right now
would be the algorithm component.

There are really three things that go into doing matching of patient records
or any other types of decision process here, and the three are listed on this
one. The first one is theory, there’s some mathematical theory that tells you
what’s the best way to use the data that you have for making the decision you
have. This is a likelihood ratio comparison which is what anybody does for the
standard to hypothesis test. So there’s theory within there and theory is
important as it tells you how to extrapolate this from one million records to
ten million records.

The other is empirical knowledge, so that how do I look at data, what are
the types of errors that people make. The empirical knowledge that come from
looking at two billion records, getting feedback from the people who are going
out to the field and evaluating your match criteria, that’s also a key
component. We reflect that really in how we compare attributes together, so we
may have attributes comparison techniques which are very specific, name one is
very specific, and ones that are general that you would apply to an arbitrary
identifier. So the empirical knowledge which is the types of errors you see in
recording data is also a key component to the algorithm development.

And lastly is the data analysis component itself, so the theory, how you’re
going to do the comparison, and then the data analysis component that tells you
how to link it all together numerically, so to use your data in the optimal
way.

Within this you’re always, John introduced the topic quite well this
morning, you have two problems, whenever you’re making a decision you can do
two things wrong. You can link people that you shouldn’t link or you cannot
find people that you should be finding. Those are the false positives/false
negatives, type one, type two in the standard statistical sense, but in this
realm they use it as a false negative, something I missed, I should have
declared him and I didn’t, or false positive, I said these guys were the same
and they weren’t. And you’re always fighting those two things and each of these
three components go to address those problems individually.

So if we took a first one at false negatives, why doesn’t exact match work,
well exact match doesn’t work for a lot of reasons, one is primarily it’s how
people record data, I use nicknames, it’s manually done, there are
transpositions of first name and middle name, transpositions of first and last,
hyphenated last names, variation in recording data is the key reason that you
have to do this type of thing. Again, the empirical knowledge is what are the
types of mistakes that people make and how do you address them.

The other thing that typically causes you to miss things is missing data, so
you have a name but no date of birth, or you have a name and a date of birth
but no zip code. When can you, when is that enough to be confident in linking
and when is it not enough to be confident in linking? Deterministic rules
usually say I have to have a name and this and this and they’re very tight
along that way. Other times you can get enough certainty just using the
attributes themselves to be able to link even when there’s missing data.

On the first component of that, the variation, and let me use name for a
minute because within any patient record most of the information is from an
information theoretic sense is in the name. And so you have to be, it’s to your
advantage to work hard to understand the recording variations. So for example
three years ago when we were working with a set with a large Asian population
we had noticed that first name, last name, name reversals, the number of name
tokens you got in a particular record or their order was causing us to miss a
lot of records and that is in a lot of cultures the notion of first, middle,
last doesn’t make any sense but they’re recording it in an English system. So
we revamped our name comparison technique to in fact ignore blocking and just
take the tokens themselves and look for the best possible alignment of those
within those, of the tokens within two names. This allows us to catch these
places where people are using first name, last name reverses, etc., in the
Asian populations.

And within that you have to worry about not only do the tokens match, do the
name token pieces match, but how do they match, do they match exact, are they
nickname equivalents, are they phonetic equivalents, name to initials, are they
just type errors. All of those things go into the comparison function and
return a number that says this name is close to this by a certain amount.

For other attributes it’s not that hard, Social Security number for example,
the typical error you see are typographical errors, transpositions, digits
wrong, etc. For those the comparison functions are very straightforward.

In terms of addressing thin data the only way around making up for lack of
data is to use the data you have the best way you know how, and that is to
weight that according to the frequency and the types of errors that you see. So
within all of these it’s the theory, it’s the empirical knowledge in the names,
and it’s in using the data that fight this particular problem.

And if you go to false positives, that is linking things that you shouldn’t
link, what’s the typical cause of that, and the typical cause of that is
agreement on frequently occurring attribute values. Linda Smith is the most
common name so Linda Smith and a date of birth is not enough to find somebody
in the United States, too many of them. But if you run across Albert Einstein
and a date of birth, is that infrequent enough that you would be happy to
declare that on a particular dataset, so it’s using the values of the
attributes as well as the type of attribute in the matching that give you the
best use of the data going forward.

The other component to it is that you can in fact have local area variations
and this is where the algorithm serendipitously matches up with how RHIOs are
built so the frequency of names and the types of errors that you might see in
Minnesota looking for Schumacher are different then you will find in Los
Angeles looking for Schumacher, so a local instance of the weighting algorithm
can take advantage of that particular piece of information whereas a national
or overall set of weights naturally couldn’t, it has to use the components with
that one.

The other thing that bothers you a lot with matching are family members and
this is where you really go, at the beginning I said we use a binary detector,
same/not same, it’s really a trinary detector, basian(?) classifier if you
like, these are different people, this the same person, or these are family
related. And that’s really just a re-weighting of the attributes you have and
how you use it. So comparing two members where you think they might be in the
same family, the weight for a last name match is significantly less then in
overall.

The one thing with this that I think is a key thing is that if you’re using
theory in deciding how you’re doing matching statistics, and before I did
patient identification I did remote sensing applications, algorithms for remote
sensing applications for the Department of Defense, and it’s always the case
where you’re going to study a small area and then you’re going to try to
extrapolate performance over the entire world. Theory is a good thing that
allows you to be able to take that information and fold it forward so that you
know how to use it in the, you know how your matching system will react as you
change the size.

Basically all there really is to the probabilistic matching is looking at
ratios of probabilities, how many Smiths are out there, how many times do I see
a typo on a Social Security number, how many people are in this zip code. So
it’s all determined by ratios of probabilities and the weights that come out of
this realm just tell you in a likelihood sense how to combine the results of
different attributes.

So this weighting scheme is designed to take not only a fixed set of
attributes but then it tells you how to combine information contribution from
other attributes that you may have, so if in a particular environment you’re
getting birth place, and in the VA that’s a key attribute by the way, place of
birth, that gives you using this process knowing how many people live in that
birth place, the errors in recording that, allow you to fold this in naturally
so they all fall in using likelihood units and put that together in a
theoretically consistent and scalable way. So that’s the data analysis
component that goes with it.

One of the things that John had mentioned which is a key point is data
quality and its impact on performance. So kind of the question is is how well
does this thing really work, does this work on a large scale and if so how
well? So we’ve been doing this for a while, we have both theory and we have a
lot of data behind it in analysis, and we did RxHub three, four years ago their
matching problem was really what we thought was “on the edge”, that
they have the data to support the types of batching that they wanted to do.

So back at that time we built this simulation that would allow us to predict
performance based upon data quality and data attributes that are available,
that fed through our matching system or really any matching system that follows
the principles that I put up earlier which would be theoretically based,
understanding data variation, and based upon data analysis and true
frequencies, any process out there that meets that, so we put together a
simulation that we have used over the time and I thought I’d just bring some
results here primarily to illustrate the relative contributions of data quality
or data availability and matching accuracy.

So for this simulation what I’ve done is I’ve set it up for ten million
members, figuring that’s a typical RHIO size case. And I’ve set it for an
extremely low false positive rate, as you can hear from the conversations,
Halamka and later from RxHub, we all think an extremely low false positive rate
is the way to go with this, so I’ve done it that way. Taken four attributes and
their normal variations, normal errors you would see, within that I took some
client data and did these statistics. And then I take the simulation and I vary
how often I get that, how often are these data available, and indicate what’s
the results, what’s my false negative rate. Fix false positive rate and now
let’s see what are we going to miss for as we change attribute quality.

So the first line is you have name, date of birth, zip, 100 percent of the
time and no Social Security number, and it’s predicting a false negative rate
of six percent, small number, so you’re getting 95 percent of the results with
data like this, quite a good system you would say at that level, very
effective. Just dropping date of birth and zip down by ten percent has a
significant impact upon the performance here, that you see the false negative
rate within this has gone up to 22 percent, still a usable system but clearly
not what we would like to see in the low, you want to be above 90 percent would
be a good place to be within these numbers.

If you add in Social Security number, the full Social Security number, and
you say you only get it three quarters of the time or 70 percent, which is a
typical number you see in hospital data, you’re back where you want to be,
you’re back at, getting 90 plus percent of the matches out there.

And interesting enough if you go to four digits, so you’re a little bit,
your system is just going to work on the last four digits of the Social
Security number, not the full nine, so presumably you are protecting people
from privacy laws by only storing four. And you see within that realm the false
negative rate is still below ten percent so it’s still quite a usable system
within this taking account data quality.

Now in a lot of environments you’d like to say you have 100 percent but you
don’t, and as specifically as you start integrating in information from health
care facilities typically 90 is a good number, that’s an average over three or
four places that we have looked at. So within that realm to come up with a
reasonable system additional above the four, Social Security, the last four
digits of the Social Security, birth place, other information will be need to
folded into this algorithm.

I really just brought this though as an illustration that we can do
predictions on this, this is not a fly by night science, we have some theory
behind it, and we can do predictions on how these things will operate in the
real world.

And with that I think I’d like to turn it back to Lorraine to talk about
some applications.

MS. FERNANDES: I said briefly at the beginning that Canada has addressed
this issue over the last few years and in fact they made some health care and
business decisions across the provinces based upon blueprints that were
designed for how they’re going to deploy patient identification technology in
Canada. There are in fact six provinces that have already selected their
technology for patient identification and are in various stages of deploying
that to facilitate identification that a local, health authority, provincial,
and ultimately across all of Canada.

What this might look like at a national level is a varying degree of
adoption that takes advantage of the deployments that are already in the United
States today, as I said at the beginning a lot of large integrated delivery
networks already have this type of technology and use it to facilitate patient
identification, so it’s perhaps rolling those IDNs up that are using the
technology to provide the data at a RHIO level, communication on a RHIO to RHIO
level, so that you have a flexible deployment based upon how health care is
delivered, what the community wants for their structure, their environment,
their architecture at that regional or perhaps at a state level.

And just a pictorial of what it might look like across the United States, as
John said perhaps we have 50 regional or state hubs out there supporting
patient identification, perhaps it’s 100, perhaps it’s 200, we don’t know at
this point in time. But the technology is going to enable a gradual building of
that virtual electronic health record and a national health information
network, so you can invest and realize the benefits to this system gradually,
we don’t have to wait for a big bang of three years or five years or ten years
from now, you can adapt to the varying standards, the diversity of data
elements, and the fact that you do have data quality issues and you are going
to have thinness of data out there in the health care system today.

In summary I would just say that patient matching or identification
technology is proven, it’s accurate, it’s scalable, it addresses a lot of the
challenges that we’ve talked about with standards and messaging in the health
care ecosystem today. It does manage the fact that you want a federated
approach so that you can have the clinical data residing at that local level
and at that local you can manage the privacy, security, the opt in and the opt
out parameters that have to be put forward to you and I as a health care
consumer.

Thank you.

MR. REYNOLDS: Okay, thank you. I’ve got a question and Steve and Jeff. Thank
you very much. I think what’s been interesting to me, one of the exciting
things about being on this committee is that you’re on multiple subcommittees,
one of the tough parts is that you’re on multiple subcommittees, and coming
into this I was anxious to see the approach and as you hear RHIOs, and I’m all
for RHIOs, but as you hear RHIOs and you hear the fact that everybody is
getting away from identity theft by getting off of Social Security numbers but
now we’re talking about using what I would consider more accessible data to
find people, RHIOs are not mentioned in any legislation anywhere as covered
anythings, they’re funded by other then covered entities who put money into
them and want return from them, which if you think a RHIO talking to RHIO,
you’ve got lots of players in there that may not be covered on this thing.

So I’d just love a comment from you, it’s thrown me back into our privacy
discussions that we’ve had and it’s thrown me right, and as standards, going
away from Social Security philosophically was a bit of a standard, going now to
this other data just was a little different view then I thought, which is
exciting, I mean that’s why we’re having this, to understand what’s going on.
So any comment you can make —

MS. FERNANDES: I’d offer first a comment that I think a lot of the RHIOs at
whatever stage they are in in development are probably the two primary issues
are financial sustainability and the privacy issue of how do we manage and
secure the data, how do we ensure our community that we have taken care of
privacy and security. So what I commonly hear is very early on there are
agreements and in fact Connecting for Health is developing a model agreement
for the RHIOs to use and my understanding is that’s going to be ready by the
end of the year or very early next year, so that there’s a model that these
RHIOs in whatever stage of deployment they are can use as the baseline and that
this model is in fact kind of the standard of practice that while I may live in
the San Francisco area if a query is done for my data in South Dakota where I
happened to grow up I can be assured that in each of these communities so to
speak they are adhering to the same privacy and security standards so that I
know my data is maintained, there’s some responsibility and some liability also
around that. So that’s what I commonly hear out there.

DR. STEINDEL: Yes, thank you, actually my question is going to be addressed
to Scott, what I really appreciated about this particular talk and putting on
my gear head hat was getting down into the meat of how these probabilistic
matching systems work and what’s going on with them. I think we’ve had a lot of
discussion on the policy side of this earlier and also in many other previous
hearings. What interested me on the table that you put up about your misses on
the probabilistic match was what you didn’t change in that was the name. And I
would imagine that a lot of errors will occur in the taking of the name and the
way the name is transferred between sites.

The other question with regard to that as well is something that Harry just
alluded to and that’s the movement away from Social Security number to other
forms of identification numbers that may vary between regions. And can we just
look at the Social Security number as a number and sort of transpose in our
minds the type of success we would have with any number, or is that unique to
the Social Security number?

DR. SCHUMACHER: Okay, to the first one, I had name there 100 percent of the
time because usually the name is filled out in a record 100 percent of the
time, but the simulation takes into account the types of errors that you’re
talking about in terms of doing the recording, so there’s a distribution in
matching and that’s why you really, unless you’re very lucky you never really
get that number to 100 percent in terms of what you’re catching out there
because names are recorded in error, so the simulation takes that into account.
And it did so for all of the other attributes, it takes into the account the
normal distribution of errors in matching that but here what I do is I just say
is that population there or not, so there’s a lot underneath the hood that come
from looking at the data so that’s in there, and you’re correct, name is by far
the biggest mess in terms of doing matching, numbers are straightforward.

In terms of other identification numbers, say a regional number as well,
yes, you could feed those in and you would get a very similar response as you
would with that one. Now where it wouldn’t do you any good would be going from
one region to another, but within a region identifying and linking records
within a region, a local number would work quite well. And in fact one of the
things that I think is an important thing to keep around is that if you look at
the number of medical records there’s billions of them, but in terms of, and
you cannot link those at a national level. You can link those records together
at a local level and then produce identities, individuals, single individuals,
out to a national identifier, and that will work because you’re only talking
about 300 million or so. So that number would have value at the local, even
though it does not give you anything —

DR. STEINDEL: Thank you for clarifying the way this table was derived, I
assume that 100 percent meant the name was 100 percent accurate in what you fed
in, that was a very good clarification, thank you.

MR. BLAIR: One question. There’s three concepts that I hear referenced,
master person index is one, record locator services are the second, and
matching or linking patients to their records is the third. Could you just
clarify to me what differences, if any, you consider between those three
concepts?

MS. FERNANDES: I think all three of those concepts have to have the patient
identification, the patient matching technology as a component because the
correct identification of that patient across the disparate systems is the
foundational element to actually determining where the record is and then the
third leg of the journey so to speak of actually getting that record. So in the
record locator service the first thing they do is patient identification using
either a probabilistic algorithm, like John said it is our algorithm that’s
being used in the prototype for RLS, they’re also using the Regenstrief
algorithm, they’ve done some exact match work in the record locator service. So
every approach is going to have some type of patient identification.

MR. BLAIR: What is the difference? Could you clarify why somebody would use
one term rather then another?

MS. FERNANDES: I think it’s just a matter of geography, of perhaps what we
might talk in California where I live versus Massachusetts, perhaps it’s the
various people that are making up the components of the workgroup. The record
locator service itself does have those three components but because you can
swap in and swap out the various types of algorithm, I think that’s why their
core function or purpose is to be able to locate a record and why they’ve used
that terminology.

MR. BLAIR: So they’re synonyms.

MS. FERNANDES: Right.

DR. SCHUMACHER: Usually you see an EMPI(?) applied to an enterprise,
hospital IDN, large issues, whereas the record locator service say it’s been
coined recently, is the same concept but applied across enterprises. And each
one of those has a matching or identification component as part of what it
does, they do other things, auditing, other data to go with it, but they have
that component of them.

MR. REYNOLDS: Lorraine and Scott, thank you, appreciate your information.
Well get back together at 10:55, take a break.

[Brief break.]

MR. REYNOLDS: Our next speaker needs no introduction to this committee,
it’s nice to see you’re versatile enough to talk about multiple subjects,
that’s an exciting thing for us —

MS. BYRNE: That’s what Jeff said, what don’t you know Teri, well nothing,
everything —

MR. REYNOLDS: The legend continues. So Teri, you have the floor.

Agenda Item: Matching Patients to Their Records – Ms.
Byrne

MS. BYRNE: Hi, I’m Teri Byrne, I’m the vice president of standards and
product management at RxHub, and I want to thank the committee for inviting us
back to talk about our experience with patient matching and that’s exactly what
we’re going to talk about, we’re not going to talk about the theories and the
probabilistic stuff, and that’s great that Scott is here to do that because I
don’t like talking about that stuff. But we’re going to talk about our
application of the Initiate MPI and some of the other things we do around the
data.

One thing I do want you to note is the spelling of my name, it’s Teri Byrne,
it’s one of the perfect names to use as an example when you’re talking about
patient matching and also I’d like you to note my nametag, which says Theresa
Marie, which is my real name, so we’re going to talk a little bit about
nicknames and that type of thing. And I’m one of those terrible people that
sometimes I register myself as Theresa and sometimes I register myself as Teri,
and stuff like that.

We are going to talk about, first give you an overview of how we use, what
we do with our MPI, or master patient index, we’re going to talk about the data
and patient matching and what we do, what parts of the algorithm we use and
what parts we don’t. And how we apply it in our clinic and hospital settings. A
little bit about the development that we did and the steps we went through and
the pilot we did, industry utilization, and then some of the conclusions that
we’ve come to.

So what is the master patient index at RxHub, well basically the MPI is the
cornerstone of all of our transaction processing. We call it our lynchpin, the
eligibility, our lynchpin transaction, but basically when we, the original
query that we take in from a technology vendor or a hospital identifies where
the patient has coverage, and that’s a key thing to understand because we don’t
ask for card holder information, or the physicians or the people who register
the patients don’t have to ask for their card holder information because we
find the patient and we find the coverage for the patient. So in essence we’re
locating the record of insurance for the patient.

We currently have 140 million active member records from three PBMs. We use
limited demographics to match the patient, you’ve heard about these already,
name, first name, middle name, suffix, date of birth, zip code and gender, and
that’s the information that we receive from the requester and we’re going to
talk about the difference between the information that we store and the
information that we receive on a request. We have a robust matching algorithm,
we do use Initiate Systems, which we implemented back in 2001. It’s
statistically sound, it’s tuned for performance, as a matter of fact an
eligibility request which originally took about three seconds is now taking
under two seconds because we reduced a lot of the time it took for us to locate
the patient which is actually under a half a second now. Is that correct, Mark?
The actual match is under a quarter second, sorry, I’m referring to Mark
Gingrich who’s also here with me today from RxHub.

We’ve tuned it for minimal false positives as Scott alluded to and we’ll
talk a little bit about that. A chance of a false positive is extremely remote,
we have processed over 28 million requests with no report of a false positive
to date, so that’s pretty significant.

Again what we’re doing is unprecedented in the health care industry, we do
have nationwide access to patient information and we have received transactions
from all 50 states to date.

So let’s talk a little bit about the data, first of all we’re going to talk
about the data that we actually receive from the source, or the health plan or
PBM. We do receive the full name, typically first name, last name, middle
initial, suffix, sometimes we get prefix. We most of the time receive date of
birth, we take in the full address, however we only use the zip code in
matching but we do take in the full address because it helps in problem
resolution, etc. We receive gender, and then we also receive what we term a
payer unique ID, and that is an ID that the source of the information ties to
that specific coverage for a patient. And it’s important to understand that we
may have multiple instances of a patient in our MPI because they have multiple
coverage, and each coverage is identified separately. So the payer links a
particular ID to a coverage for a patient so if one payer has Teri Byrne
covered under my own plan and also under my husband’s plan I would have two
records in the MPI and they would have two different IDs linked to them.

RxHub does not create a patient ID that identifies Teri Byrne as a single
entity in their MPI. When we do a query we dynamically link those records, and
Scott really talked about how that’s done with the algorithm, with a single
pass through our MPI. So again, we’re doing that in under a half a second, a
quarter second, very fast with 140 million records.

And I want to talk a bit about the data loads process and trying to give you
more information about how we’ve applied this, what was really important early
on was that we did analyze the data that we had and we went through an analysis
process with Initiate and we also go through a process when we load data from
each PBM to help them understand how many occurrences of dates of birth are
missing, how good or bad are their dates of birth, how many of them are
defaulted, how many records have zip code or have missing zip code or missing
address, things like that. And one of the things I wanted to address your
question Judy earlier that you asked John where you said would it be important
someday to have standards around the algorithm.

And I think it’s really important to understand that it depends on the data,
what components of the algorithm you want to use, and it also I think depends
on whether you’re coming back with a patient or you’re coming back with a list
of patients, etc., RxHub does a patient match, we find Teri Byrne and all
occurrences of Teri Byrne are me, we don’t’ come back with a list of here are
the Teri Byrnes that you might have. So I’m not sure if you can say you should
have an algorithm, a standard for the algorithm, or if it depends on how you’re
applying it and what your data looks like that you’re using.

So when we do what we call our bulk loads we initially load all of the PBM’s
data into our database and we go through it and we look for bad data. And if we
find bad data, which we typically do, then we ask the PBMs to help clean it up
and they will go back to the health plans and ask them to kind of clean up
their data because the cleaner data they have the better occurrence of matching
they’re going to get.

We also allow them to do periodic refreshes of the data if they, let’s say
if a PBM decides to go back and renumber everybody in a certain health plan or
across their entire business then they can reload the data. And as soon as they
reload the data we can apply that information, there’s saying oh, I have to
change Teri Byrne’s number everywhere else, it’s because we find the number on
the fly, we do dynamic linking, as soon as we bring that new data in we can
find that new number.

We do nightly updates, nightly refreshes, or nightly updates of demographic
data changes only from our PBMs, the data that we have is not eligibility data,
it’s not medication history data, it’s just demographic information for the
purpose of finding a patient.

We also recommend audits to the PBMs, we typically do an audit after 90 days
of initially loading the data so that we can determine that we’re in sync, our
data and their data so that when we find a patient and we send them a request
they find the patient as well and it’s the same information. So we go through a
comparison process, if we find issues we determine and resolve the issues and
then we reload the data if necessary, otherwise the PBM could just do updates
on the data that’s bad.

So basically we’ve been looking over the past four years to continuously
improve the quality of this data, which is really important because it raises
our chance for finding a patient.

So as I talked about clean data, it is better data, the PBMs want, the
payers want to find a match because that’s their way of being able to reduce
their administrative costs and increase patient safety. So the more often we
find a patient the better.

So that’s basically how we store and load the data, I’m going to talk a
little bit about now which parts of the algorithm we use in matching and I’m
really not going to talk much about this slide which just talks more about
false negatives and false positives which Scott already explained, but to let
you know that RxHub does err on the side of false negatives and we’d rather not
send back a record if we weren’t sure that this is the correct patient.

So the parts of the logic that we use, and I want to explain some of this a
little bit by giving some examples using my name, the first one in the name,
when we’re matching on the name, we do use phonetic comparisons, however we
don’t use nicknames. And all of this was determined based on the analysis of
the data that we had early on. So for example T e r i, if somebody submitted T
e r r y, which I actually used to spell my name that way and then I changed it
to T e r i, it’s my nickname, so I just spell it any way I want. So if they
submit a T e r r y we would find a match because it sounds like Teri. Byrne, a
lot of, most people spell my name B u r n and it’s spelled B y r n e, we would
match if somebody typed in Burn, however, a lot of people type my name B r y n
e, sounds like brine, probably wouldn’t match. Just to kind of give you an
idea, and also if somebody typed in Theresa we would not find Teri Byrne
because we don’t use nickname matches. Some people do, we don’t, we just found
it for good reason not to use it.

We also use name component matches, or Scott referred to them as tokens, so
we take Teri, we take Byrne, we take the suffix and we match all of those
components together so if somebody puts my last name in the first name or
whatever, transposes those, we can help find those issues. And then as Scott
also alluded to more common names are weighted differently.

Date of birth, first of all if we don’t get a date of birth on the incoming
request or we don’t have a date of birth on file we won’t match a patient. Date
of birth is required on both sides to match.

We use what we term the two changes function, that actually might be an
Initiate term, I’m not sure, but where if you can change a number add two,
subtract two, in any one of the components of the dates of birth we may match
to just kind of allow for transposed, allow for mistyping of the information.
And then we have a birth year weight table that we use so commonly dates of
birth, 1/1/1990 or the first of the year are weighted probably lower then a
less common date of birth.

For zip code we do use the, we first try to match on the five digits and we
do have a five digit weight table that we use, and then if we don’t match on
the five digits we’ll use the first three digits, and we have a weight table
that applies to that too.

So those are basically the main components that we use in matching that are
ally important and again, we don’t, we do a positive ID, we don’t pass back a
list of patients.

So how did we apply this in our model? We are a patient information locator,
again we don’t store medication history, we don’t store clinical data, we find
where the data is located. So we route the request to the appropriate source
that we find in our MPI and it may include more then one instance of a patient
but again that’s in the case where I may have dual coverage or the patient has
dual coverage. So there’s one record, one response record per benefit coverage
and again we don’t have a patient identifier key that we use but we will pass
back the identifier that the source of the information uses. So two occurrences
of Teri Byrne will have two occurrences of an identifier, one for each source.

And today we’re actually have about a ten percent dual coverage rate, it’s
been up to 15. in the pilot that I’ll talk about later you’ll see it was a lot
less. But right now we’re running about ten percent dual coverage.

Okay, we’ve actually presented this slide before but I wanted to talk to you
again about the model and there’s two different models that we use and kind of
the standards that we use and how we do this. The first one is the technology
vendor model where we do an eligibility and then a medication history. So what
happens is on the left side the point of care application sends in a request or
sends in a 270 in this case request with the patient demographics that we
talked about, name, date of birth, gender, zip code, that they’ve extracted out
of their system or somebody has typed in when they’re registering. And we do a
match of that patient in our MPI just based on the demographics, and then we
send that 270 request out to the source of the data or the payer today. That
payer responds back with, and we also add the payer’s identifier, so that they
know what patient we’re talking about, that identifier goes back to the
technology vendor, they know what patient, they use that identifier on future
requests.

And also in this model is where we return the formulary information or links
to formulary and things like that as well but I don’t know if that’s as
important today.

It’s important that you know that when we are implementing technology
vendors or hospitals we help them understand that it’s very important to verify
the data that you get back. We’ve moved towards encouraging the PBMs to respond
back with information that they have on file for the patient so that if
somebody sends in Teri Burn, B u r n, and they have on file B y r n e we want
them to return back B y r n e so that somebody can look at that data and say
okay, well I see if misspelled the name, is this really the Teri Byrne I was
looking for.

And we also ask that they put disclaimers on the data for medication history
to say please validate that this is the right patient, this is the right
information for the patient. Because there’s no way to eliminate a false
positive, although we err on the side of false negative there’s no way to
eliminate the chance for a false positive. And again, this is also a precursor
to the medication history and formulary information so consent issues apply,
etc.

So then in a hospital model we use the MPI a little bit differently and we
use different standards for that request. From a hospital system we actually
receive an admit request, same information on the request, same demographic
information, just a different standards, and we look up the patient in our MPI,
we find coverages for that patient and instead of sending an eligibility
request we actually send a medication history request. And the medication
history standard I might add is the new NCPDP ANSI accredited standard as of
last week, we’re very excited about that, sorry, I had to get that in, and they
send back the response and then we aggregate the data into an HL7 response back
to the hospital system. So again, we pass back on the information and we
encourage the hospital system to look at the demographic information, to look
at the medication history information, make sure that we found the correct
patient and look at the drugs that are for that patient and validate that list.
We ask them to sign a consent on these transactions, we ask them to display
disclaimers as well in the hospital systems.

I was trying to figure out where was the best way to bring this in and I
think this is the place but I wanted to bring up an issue that we’ve found and
have had to address based on the work that’s going on to get medication history
out to the Katrina evacuees. And the question was asked earlier and I don’t
remember who asked it, Harry, maybe it was you, about the different state
regulations around, Jeff, it might have been you, I’m sorry, but around what
drugs can be displayed, etc.

And it really doesn’t have anything to do with locating a patient or the MPI
but it is a huge issue and we found out over the past few weeks we’ve been
trying to get medication history information out to the victims of Katrina and
there’s been first of all a lot of confusion around what do the state regs
apply to, do they apply to where the data resides, do they apply to where
you’re looking at the data, do they apply to where you extracted the data, it’s
just really confusing and so basically the bottom line is it delayed the RxHub
implementation of getting the data out through gold standard to the shelters by
four days, which is I mean four days in a just normal implementation of 90 days
is no big deal but when you’re trying to get information out to people who
can’t get their dugs that’s, and it is filtered now, but that was huge, four
days was a long time.

And the thing is we didn’t know did all the data have to be filtered, what
states does it have to be filtered in, I think we knew that the state regs in
Louisiana and Alabama and Mississippi were okay, we could have not filtered the
data but what about when a physician in Boston tries to use this application or
a physician in California. And so ultimately we ended up filtering all of the
data which, and then you bring up those other issues that were talked about,
now we have patients who are taking medications for really important things and
they don’t know what the medication was and there’s no way for the physician to
understand what that medication was because we’ve just filtered out sensitive
drugs.

So I think, I wanted to bring that up because that is an important issue,
and whether you’re locating a patient or storing all the data locally it’s a
really important issue. And I’m hoping that in our review of lessons learned
for this Katrina effort that will come up and we’ll come up with an action plan
around it but I did want to bring it up.

Okay, so I want to talk a little bit about the development timeline, how we
developed our MPI and our pilot. First of all we started this effort in July of
2001, which is when the company was formed, this is really the first thing that
we, we knew we needed to solve this issue to be successful, especially with PBM
data patient’s don’t carry around PBM cards, they don’t even know what a PBM
is, I didn’t know what a PBM was before I got into health care.

The first thing we did is we looked at all the candidates who had MPI
algorithms and processes, etc. We looked at matching accuracy performance and
software integration, and in November was when we eliminated the others and
chose Initiate, and we started actually the design and the implementation of
that system in January of 2002. And again what we looked at really was the
population of data in the PBM data, the characteristics of the data, the
frequency of the data. We looked at 50 million records initially and then
developed our matching strategies and our value and weight assignments. So
again, we chose to do some of the things that we do in our algorithm based on
the data that we had, if the data was different, if the occurrences of some of
the data was different we may choose to do things differently, so that’s really
an important factor I think.

And then we started our pilot in June of 2002 and that’s actually when we
piloted the eligibility transaction as well, and we looked at matching
accuracy, we looked at tech vendor data statistics, we processed 104,000 plus
transactions, we had 379 participating physicians, three participating PBMs and
three participating tech vendors.

And what we concluded as a result of this pilot was as far as MPI
functionality there were actually a higher number of unique members then we
expected found. We found no occurrences of false positives, which is what we
were shooting for, and in this case all of the patients returned were analyzed
to make sure that they were the correct patient. There was a higher rate of
dual coverage then expected and at that time it was 5.2 percent and that
surprised us, and like I said now we’re actually up to ten percent of finding
dual coverage.

We validated the key fields, name, date of birth, and zip code were critical
in finding a match. We’ll still find a match without zip code but it’s not
extremely common, it just depends on the commonality of the name as Scott
talked about.

And I think this is really important, we found that Social Security number
was not helpful, not only was it not helpful, it was kind of detrimental in the
match. And the reason for that was the Social Security numbers were just wrong,
they didn’t match, the Social Security number that came in didn’t match the
Social Security number that we had on file. And I think there are a lot of
reasons for that especially in the health care business because a lot of times
you’ll use your own Soc for your children, I don’t know my children’s Social
Security numbers so if they ask me for their Social Security number when I
walked into a clinic I would either give them mine thinking okay they want mine
because they’re trying to find my card ID which is typically my Social Security
number so if I give them that they’ll probably find my coverage, that’s logical
to me. Or you use your husband’s Social Security number, etc., so we found by
removing that and not using Social Security number as part of our matching
algorithm we had a higher hit rate.

And I think the other thing to understand around that is that you could add
in address, you could add in health plan, you could add in health plan ID, you
could add in a lot of information to try to use in the match but more data is
not necessarily better because it can reduce the effect that it has on the
algorithm and reduce your chance for finding a match. So I think that’s also a
good thing to understand and we did look at other data too, we looked at, we
had health plans and health plan ID and stuff on file and you can only get, a
patient only knows certain information almost all the time. I typically know my
name, my date of birth and where I live, other then that if I don’t memorize
numbers I may not even able to know my Soc. I do but a lot of people don’t.

So we also validate our MPI load functions and our updates and made sure we
had the correct data, etc., we validate our switch functionality, we validated
the eligibility transaction format and the information that was coming back and
was it useful, etc., so we evaluated that model. We validate our certification
process which is just as important, how do you certify the people who are
feeding you the sources of the data and is it good data and are they extracting
the right data from their system. And then we identified operational reports
around patient matching and statistics around transactions, etc. So we learned
a lot from that pilot about what we needed to do.

So just a little bit about industry utilization and we’ve talked before
about how many participants, we probably have a lot more participants then we
did last time that we justified. We currently have 42 different participants in
production, seven of those are hospitals, we have three PBMs, we also have more
PBMs signed and some others in the works. We have six health plans with
formulary only in production, we have 23 technology vendors in production, one
pharmacy network and two mail service pharmacies. So between all of those
entities we’re doing patient matching.

The other thing that we wanted to show you is that e-prescribing adoption is
happening, this is our volume of medication history, we’re at 5,222,000
transactions so far to date, up from 59 in the first quarter of ’03, or fourth
quarter of ’03, as well as eligibility. And one of the things that we wanted to
show you from an eligibility perspective is what we talked about is really have
been working on reducing the time it takes to send a request and we’re
processing more transactions in a lot less time, so we’ve reduced the time that
it takes to process a transaction so the MPI is scalable and that’s an
important thing to understand, 140 million records we still can process in a
quarter of a second.

So in conclusion we believe that a national patient identifier is not needed
and again, would we use it if it was provided? Probably, I guess it depends on
the accuracy of the data that we have in our MPI from the sources of data, and
the accuracy of the data received, are patients going to remember that number
and is it going to get typed accurately. So again, it could act just like a
Soc, it could be a detriment to the match.

Real time matching in clinical data query is proven, we do it, we don’t
store clinical data, we do it every day, we retrieve medication history
information based on finding a patient, and it’s the most accurate and up to
date information because it’s coming directly from the source. And again, that
an MPI can be tuned for excellent performance, we’ve proven it over the last
four years.

So thank you very much.

MR. REYNOLDS: Thank you. You’re the first person I’ve met that’s created
their own witness protection program with the way you use your name, it’s kind
of neat —

MS. BYRNE: By the way, I’ve been married twice too Harry.

MR. REYNOLDS: You’ve given everybody a lot to think about. Simon and then
Jeff and then Mike.

DR. COHN: Teri, first of all thank you very much for your presentation. I
actually had two questions and one was clarification to make sure I understood.
You obviously have been talking about a lot of data that you use for your MPI
matching and I heard a lot about name, I heard a lot about date of birth, I
heard a lot about zip code. Now the part that I was a little confused about was
the role of the payer unique ID, which I understand is the number that the
payer gives you for your plan, not the unique identifier of the payer —

MS. BYRNE: Right, it’s for the patient.

DR. COHN: — in terms of assuring all this stuff, I mean do you use it? Does
that contribute to the improvement that you’re describing and could you survive
without it? So that’s question number one.

MS. BYRNE: Right. Yes, we do use it and how we use it is we store it along
with that patient record in our MPI, we don’t use it on the match, what we do
is we supply that back to the payer so that they understand that we’ve matched
the record that they’ve given us, that’s identified by this unique ID, and as
well we give it to the requestor of the information so that they can use it in
future queries like medication history queries. So on an eligibility response
we give them, we found this coverage at Express Scripts and here’s their ID for
Teri Byrne, use that when you’re querying medication history. So it’s used by
them to talk back to the payer again saying here’s the key to the clinical
information that I’m looking for, so it’s kind of a record locator ID I guess.
Does that make sense?

DR. COHN: Okay, so basically you have it but you really don’t use it for
your algorithm —

MS. BYRNE: Not in matching.

DR. COHN: Okay, great —

MR. GINGRICH: Also consider that a temporary key because again I think we
get updates nightly, that key could change to the patient, we expect that every
time a technology vendor makes a query or has a patient visit they will once
again do an eligibility check to make sure they have that primary key.

MS. BYRNE: That’s a good point, by the way that was Mark Gingrich from
RxHub, that’s a good point because we have had, and that’s what I was talking
to earlier, we’ve had PBMs actually re-enumerate everybody and give us new
identifiers and reload everything, and that’s why we do real time queries to
find the patient and find that identifier because if they try to use an
identifier that they found last month it may not be the same.

DR. COHN: That’s helpful. Second question and this is just a question since
you were talking about the hurricane and your response and all of this stuff
and I don’t mean to, it’s really a question of clarification and somewhat
surprise and I don’t mean to embarrass you, but I guess I was surprised, was
this the first time that you’ve had to do cross state transfer of information,
or is this just the first time that this issue really came forward around all
of that?

MS. BYRNE: I should clarify that, we were actually, we implemented with a
vendor that we hadn’t yet implemented with and so with all of the vendors that
we’re currently implemented with they understand that they liable for what
information they display. So if they’re displaying information in the state of
Massachusetts they need to understand those laws, but this was with a vendor
who hadn’t come across that issue yet because for whatever reason, so that we
had to address it with them. And it’s something we do address with every vendor
and it isn’t an easy thing to address but they have time to go through every
state and understand the laws whereas we didn’t in this emergency.

DR. COHN: Okay, well thank you for that clarification because I had been
presuming that you had been dealing with this sort of all along. Thank you.

MR. BLAIR: Your response to Simon’s question kind of got close to the area
where I’m looking for clarification, you said every vendor, are you talking
about vendors of the algorithms that other people are using? Are there other
vendors of the algorithms, because all three testifiers today have all used
Initiate, is that what you’re saying when you say other vendors?

MS. BYRNE: Usually when I say vendor I’m talking about a technology vendor
or a point of care vendor, in what reference?

MR. BLAIR: Like electronic health record system vendors?

MS. BYRNE: Right, right, e-prescribing vendors or EHR vendors.

MR. BLAIR: Okay, good, that clarifies one part of it, the other part is all
three of our testifiers apparently have selected Initiate as the vendor that
has provided the algorithms and I’m assuming the software that use those
algorithms, and are there other providers of these algorithms? Is Initiate the
only one? If there are other providers should we be getting testimony from
other providers of these algorithms? Should we hear testimonies from others?
What guidance can you give us?

MS. BYRNE: Well, I know there are others because we analyzed others, I don’t
know, I guess I don’t know if I have an opinion about whether you need to hear
from them as well, I don’t know how different their algorithms are or whatever,
I don’t know if Initiate has an opinion on that, I’m not really sure, Jeff.

MR. BLAIR: Okay, so you’ve partially answered my question, there are other
vendors of these systems.

MS. BYRNE: There are other vendors, I don’t even know that I could name them
right off the top of my head.

MR. BLAIR: That’s fine, that’s fine. Thank you.

DR. FITZMAURICE: Thank you for very interesting testimony, this has been a
good morning. I want to understand kind of how things work, so it’s my
understanding that RxHub acts as a switch, somebody makes a query for purposes
of determining eligibility of a patient for the drug, RxHub links it, searches
all of the health plans and PBMs and says there’s a match here and here, we’re
going to send it out there to find out what they’re eligible for. And then do
they send the information back through you to the requester or do they send it
directly to the requester?

MS. BYRNE: They send it back through us.

DR. FITZMAURICE: The second question would be do you retain any of that
data? I think you retain the patient, the patient ID that’s assigned by the
payer, right?

MS. BYRNE: Right, that’s actually in our MPI as one of the keys in our MPI.

DR. FITZMAURICE: But you don’t store any of the drug information or —

MS. BYRNE: Nope, nope, we have an audit trail of the transaction, we don’t,
we store personal health information for a period of time based on HIPAA regs,
etc., etc. —

DR. FITZMAURICE: And it works for eligibility, it also works for medication
history —

MS. BYRNE: Right.

DR. FITZMAURICE: It’s going to begin to work for formulary, and would it
also work for prior authorization guidelines when that standard becomes
available, that some can come up to you and say I’m ordering this drug, if the
patient is eligible what conditions do you have on my prescribing of this drug?

MS. BYRNE: Good question. I anticipate it well and I think it depends on the
model, because we pass back that information on the eligibility transaction and
actually it is working for formulary today as well, Michael, it was the RxHub
proprietary formulary which is now becoming a standard. But we pass back
information on that eligibility response that links to formulary information,
benefit coverage information, prior authorization information, etc. So once
we’ve identified the patient we give back a lot of information about that
patient to the requester of the information so they know where to link the data
and that’s the key thing.

DR. FITZMAURICE: I had one more question but I forgot what it was.

MS. GOVAN-JENKINS: What are your thoughts on turning the date of service or
the date of encounter into an ID in order to match to the patient record? And I
ask that because when I was practicing as a telephone triage nurse we had
patients that called in and they had two records and the only way I was able to
find their file was through that date of encounter because either their name
was incorrect on one of the files or the Social Security was incorrect on
another, and I couldn’t find like I wanted to follow-up on a particular
situation and the only way for me to find that particular record was to get the
date of service or a round about date of service. So what are your thoughts on
turning that into an ID?

MS. BYRNE: We really don’t have any experience with that, we didn’t analyze
dates of service when we looked at doing this, we don’t even use effective
dates for eligibility in our search. The PBM will use effective dates to send
us the information and they’ll use effective dates to determine that a patient
is still effective but we haven’t really analyzed that. I don’t know if
Initiate has, Scott, have you looked at that?

DR. SCHUMACHER: Not within health care but in law enforcement, the date of
the event is something that you would use in the algorithm. That’s the first
time I’ve heard that, it would be an interesting thing to try in certain areas.
So yes, you can use it in the same process that I described earlier, you would
add that into the algorithm.

MR. REYNOLDS: Michael has come to again.

DR. FITZMAURICE: I remember my question. Earlier today we heard from John
Halamka and others about the quality of the data is very important and if
you’re doing the clinician to clinician you want to get a match, but it seems
to me that what you have is something unique, you can push the enforcement of
the quality of that data back to the requesters and the PBMs because they don’t
get paid if the data they supply you is inaccurate so all you have to do is say
this data isn’t good, fix it, and they’ve got a strong incentive to fix it.

MS. BYRNE: Right, they do, it’s a huge incentive, and I think that’s an
important point that I was trying to make, Michael, because the match is only
as good as the data right, and we’ve used it as a way to go back to the PBMs,
to go back to the health plans and say look, you’ll reduce your administrative
costs, you’ll increase safety in these patients if you clean up your date, so
it’s a good point.

DR. FITZMAURICE: I’d like to ask if I may a corollary question and that is
as we get into electronic prescribing I go into my physician and I say doc, you
want to prescribe this for me, what are the choices I have, what are the prices
for that drug depending upon the pharmacy I go, so then do you anticipate maybe
linking down to the physician to say all right, link up with the PBM, get the
formulary information, get the prior authorization information, and then
linking up to the pharmacies to get the price data? I mean I’m putting a lot of
burden on the physician and maybe it’s not going to work that way but could it
work that way?

MS. BYRNE: It doesn’t today and typically you’re not going to probably see
the PBM/pharmacy data pricing relationship being disclosed to the physician. So
what we’ve settled on is we’ll present co-pay tiering information, flat dollar
co-pay information, percent co-pay information, we even recommend to the
technology vendors that they don’t use AWP because that’s not going to be what
the patient is going to pay at the pharmacy, it’s whatever has been negotiated.
And it will probably be a long time before you see that —

DR. FITZMAURICE: That would be great because what I really want to know is
what do I pay out of my pocket and so you anticipate that that information
might flow to the physician if I give them a choice of three pharmacies, that’s
something we could talk about?

MS. BYRNE: I think when the industry is ready, once we get beyond what we’re
doing, we may go to real time, what they call pre-adjudication. However that’s
not ever going to be completely accurate because if I receive a prescription
from my physician today and I have a deductible or an out of pocket plan, and
then I don’t get that prescription filled for two weeks but in the meantime I
refill some of my other meds, that price may no longer apply. So that’s kind of
one of the reasons we haven’t moved to a real time pre-adjudication yet, it’s
difficult to tell the physician and the patient exactly what they’re going to
pay until the pharmacy dispenses the med. They may dispense a generic.

DR. FITZMAURICE: Thank you very much.

MR. REYNOLDS: I have one other question and then I’ll turn the program over
to Judy again. HIPAA doesn’t like data to be changed, the HIPAA transactions
don’t like that. If I look at your chart you’ll receive one set of information
and change it based on the match, the name might be spelled wrong, other things
might be spelled, you change it based on the match, give it to a payer, and
then it comes back. Is that what I heard?

MS. BYRNE: Actually we don’t change it, we send to the payer exactly what we
got from the requester and believe me, we have had lengthy conversations with
the X12 organization around what needs to be done and what should be done. You
should never change the data that you’ve used in a match, that clearly states
that.

MR. REYNOLDS: But I thought you said that you asked whoever you send it to
to send it back different then it was received —

MS. BYRNE: Right, the payer —

MR. REYNOLDS: So that is changing the data.

MS. BYRNE: That’s exactly the direction that we got from the X12
organization as defined in their HIPAA guide. For the payer should send back
the information they have on file so that the requester can compare the request
and the response to determine if there was a difference.

MR. REYNOLDS: So you’re putting that under the correction capability, you
are allowed to change data if it’s incorrect.

MS. BYRNE: We actually ask the payers to check the box that they have
provided different information then was in the request.

MR. REYNOLDS: Okay, good. Thank you, Teri very much with an i and a y and
every other thing, I appreciate it. And Judy, turn it back over to you to lead
the discussion please.

Agenda Item: Discussion and Commentary on Matching
Patients to Their Records – Dr. Warren

DR. WARREN: What I had planned at this point is really for us to have an
open discussion including members of the audience, not only about the testimony
that was heard today but ideas for testimony that we need to hear about in the
future so that we can come to some conclusion and possible recommendations
about the whole idea of matching patient records or patients to their records.
So with that I’d like to open it up to anyone from the audience, if they have
comments that they want to make or questions or suggestions for the future.
Okay, I can’t believe the audience is quiet, but that’s okay. Stan?

DR. HUFF: Just a few thoughts. One question I think is as pointed out by the
testifiers that the quality of the match is related to the quality of the data
that’s used in the match. And I wonder, given our purview, whether there’s a
need to hear basically what, would it be useful to have some national standard
for the data elements that are used to say we think we want name, birth date,
suffix, sex, and those to encourage people to uniformly collect those pieces of
data so that matching can happen more accurately and efficient. So that’s a
question, not necessarily an assertion, I don’t know if that’s good or bad but
should we try and seek some testimony that would say what are the most
effective things to use in a match and is there value in some standard that we
could state or a guideline, maybe a standard is too strong a word but are there
guidelines that we could use that would make it more efficient to match.

The second thing is, I’m starting to sort of summarize what some things that
we heard, again, I’m convinced that in the short term we need to do the kind of
matching that everybody has described and there multiple vendors and we could
talk about the other vendors that are available. But I don’t want to have that
get in the way of us looking at other things that in fact, that I don’t think
can be addressed and by that I mean probabilistic matching doesn’t help you in
cases of fraud detection, if there’s a person who’s intentionally trying to
defraud the system they just give a different name, they match up, and so in
the case and we’ve seen that within our own organization, people who are drug
abusers who go facility to facility and intentionally give different IDs and
different names, and so probabilistic matching doesn’t help you there because
that’s not, there you’re trying to find out who the real person is and if
they’re intentionally providing false information then there’s nothing that the
algorithm can do to help you there.

The other things that come into play are just the efficiency of the whole
process, if in fact I’m a good citizen and you give me a card with my number, I
can change and improve the visit environment, I can come, I can swipe my card,
and they say yes, please proceed to clinic A versus saying what’s your name,
what’s your ID, what’s your phone, asking me all of those questions when I
register for a visit. So I think there are efficiencies in the process in fact
that could be augmented again.

That’s not saying that we wouldn’t use the probabilistic matching but in
fact that there are efficiencies that I think can be obtained by the use of an
ID, that we ought to ask people what those are and how those could be used. So
I think the fact that it’s a given that we’re going to use these kind of
matching algorithms shouldn’t prevent us from thinking about what the value of
an identifier would be and whether in fact at some point whether that might be
justified and the benefits that you get from that might actually pay for the
cost of it in the long run.

I guess the final thing that was interesting, this is just one other point
of data, within our database the single most discriminating piece of data we
use, and we do this exact kind of probabilistic matching within our
organization as well, within Intermountain Health Care, the single most
discriminating piece of data is a Social Security number, and so it would be
interesting to figure out why that’s true in our case and so different from
Teri’s experience. It’s the single most discriminating piece of data that we
obtain from people and so it probably has to do with, maybe it has to do with
confusion about when they provide the number for paying purposes whether it’s
the payer or the beneficiary versus when we see them it’s the patient showing
up and we know, and we ask, because it’s the single most discriminating piece
of data and again I think a national identifier properly done in fact might
also serve that purpose, that taken as a part of other characteristics it could
in fact be a very discriminating and very helpful piece in the probabilistic
matching process.

Just some comments.

DR. WARREN: Steve then Simon then Jeff.

DR. STEINDEL: Actually Stan took a lot of my thunder and I thank him
especially for the last two comments, one I was going to bring up the issue
that we should be looking at a unique patient identifier and what are the pros
and cons. I believe it was mentioned in one talk that even if we did have a
unique patient ID we would still have to provide supporting information for it,
so I think we need to investigate that a bit further.

And picking up on Stan’s other point we need to hear from other people who
are doing probabilistic matching as to their success rates and what they’re
using. I think Stan just brought up a very good point, that he finds a great
success in using the Social Security number in his system whereas we heard from
other systems where it’s not so I think we need to find out a little bit more
about what are the attributes of these probabilistic matching systems and how
they operate in different environments and therefore we need to hear from other
people who are using it, be they vendors or just initiators, I mean we heard
Regenstrief, they’re probably not a vendor of it but they’re probably a user
and can have some experience. I just gave you a couple of names of some people
that I passed on.

The other item that I think that we need to investigate, and this struck me
very much in John Halamka’s very nice talk, however his whole talk about the
system, it seemed to be a very physician centric system with regard to
authentication and trust relationships. And one of the keys to identifying a
patient to their records, especially out of their immediate facility, is this
trust relationship that he brought up and can we trust the exchange of
information between record locator services. And I think we need to investigate
that further, the only way we heard from it today really is in John Halamka’s
case where he was just strictly talking about physicians and he used that term
repeatedly. And I think we’re all aware that that trust relationship has to
extend down to other providers and other users of the system.

And the other place that we heard about it was in the RxHub system, which is
basically a closed system where they have established their trust relationships
and we heard about that during our e-prescribing hearings. So I think we need
to investigate it in a little bit more general sense as well.

DR. WARREN: Simon?

DR. COHN: After both of them talking there’s very little more that I have to
say. I don’t want to embarrass myself by saying nothing. I guess I’d make the
following comments, I sort of basically agree with I think at the questions, I
think I may differ in some of the answers with what Stan was describing but I
do think generally what we’re trying to do obviously is to help transform the
health care system, make it more efficient as well as provide better care to
patients and the citizens. And I think we’ve heard some now about matching and
how that contributes to it, I think maybe we need to get reacquainted with some
of the arguments that some people have brought forward about why a unique
identifier may be of value and it’s just been so long since I think we’ve
talked about it it might just be useful to hear about that a little bit.

Now I will sort of maybe just a slightly different take on what I was
hearing about the matching algorithms, which I thought were very interesting
and I think we do certainly need to hear more about them. But one of the things
that comes to mind is does one need actual standards for data elements or do
there need to be performance standards, where you sort of say you can use
whatever data elements within your environment you want to but it has to have,
get to sort of this level of confidence, and would that work in a national
environment. And as I say that I don’t really think I know of any environment
where one RHIO or one organization is actually transferring data to another so
most of this is still theoretic, but it’s a question of in that context how it
might play out. And I don’t have the answer to that one, I just bring up the
question.

DR. WARREN: Simon, when you’re talking about performance standards are you
talking about them in the same way we are looking at the CCHI? Do I have the
letters wrong? The certification of health records?

DR. STEINDEL: Judy, can I comment and see if Simon will agree? Because
actually I forgot to mention, that was one thing that I wanted to bring up, and
basically we heard from everybody that said they were doing because they’re
basically using all the same system, that they were getting a match at 95
percent. And I think Simon, am I correct, is 95 percent good enough?

DR. HUFF: It’s certainly not what we want.

DR. COHN: And there’s false positives and false negatives, so it’s on both
sides.

DR. WARREN: Is that what you were trying to get at?

DR. STEINDEL: Yes.

DR. WARREN: Okay, Jeff first and then Stan.

MR. BLAIR: As we’ve had discussions in New Mexico with respect to the
development of the RHIO that we have there and we begin to look at master
person indexes we received a little bit of education on an aspect of this that
just wasn’t on my radar screen before and when he first started to talk about
it my first statement was well this isn’t a big thing, and then as I listened
some more it became bigger and bigger and bigger.

The department of health in New Mexico for example is trying to make sure
that they could respond to infectious diseases from a variety of sources and
that also expands to responding to bioterrorism. And one of the things that I
just had never thought about was the fact that, and I better not mention the
number because I may not be accurate, but many millions of undocumented and
migrant workers. And they flow through one state and then another state and
then another state and they move and they move and they move, and so we figured
well, that’s outside of the system, they don’t have a PBM number or a health
plan number, they may not have a Social Security number and all this stuff, but
then they began to explain to me that as we look at infectious diseases they go
across borders, country borders, state borders, and as we begin to try to
respond to those we need to have some way of identifying those folks and
there’s programs and plans with identifiers for migrant workers, which was new
to me.

So I’m mentioning that from the standpoint that on the one hand the
testimony I heard today made me feel very comfortable, I found the rationale
for probabilistic statistical approach compelling because there seemed to be
convergence, all of our testifiers seemed to have focused in on this as the way
they’ve approached things but with Stan’s comments about the fact that we also
need to consider Social Security number, why it works in his area, reactions of
fraudulent situations, and in the point I’m adding to this is undocumented
workers with infectious diseases flowing through the country in increasingly
large numbers, I think we need to hear from other entities that either have
different approaches or even if they still use probabilistic and statistical
approaches maybe they use it in a different way. So I think we have to expand
the breadth of the testimony we receive for us to get a complete picture.

DR. WARREN: Stan then Mike then Harry.

DR. HUFF: Again, a slightly different aspect to this, sort of the argument
started off, or a lot of the arguments came that we don’t want, there’s the
fear that a national patient identifier would lead to a national database which
would make all of my data available to somebody and increases my risk of
privacy or security invasion.

Now what we actually hear then in the testimony is because these things work
so well in fact I can link all of my data everywhere, even though it’s not in
one database I’m linking all of my data everywhere so in effect we’ve created
the environment using this capability that people were trying to avoid by not
having a national identifier. And that the justification for the national
identifier, or for doing the probabilistic matching, is because it works and we
need it today, which I’m fully convinced of, but the underlying argument
actually is exactly the same. Once people understand this they’re going to feel
the same threat from this technology that they felt from a national patient
identifier if they truly understand it because they’re at the same risk.

And that comes back to what Michael said before, then my real security is
in, is sort of at the database level and has to do with strong authentication
of the people who are accessing data and tying that strong authentication to
their permissions and consent of the patient to access that information. That’s
where the real security comes in this and I think we, simply talking about the
fact that we’re going to do probabilistic matching instead of a national
patient identifier, because we’re so, I mean it’s, you’ve created the same
concern that you were trying to alleviate by not having the national patient
identifier.

And so I think we have, it comes back to those old issues of privacy and
security that we talked about on other committee days, I think those areas are
ultimately the things that are going to provide real security and privacy and
it’s actually sort of a red herring that we talk, that this national patient
identifier is not done and in fact by the, it’s not done because of privacy
concerns, in fact by applying the technology so effectively we’ve created the
same concern that people had initially.

DR. WARREN: Mike?

DR. FITZMAURICE: That was so well said that if I ever go into a court of
statistics I think I want to hire Stan as my lawyer for that.

I wanted to raise the issue of public perception and Stan covered it very
well, I think part of our job is to sort out the issues that are important,
public perception is important, and we can help the public by saying here’s
what the fears are, here’s what the protections are, and you don’t have to be
afraid of the Social Security number any more then a unique health identifier
or then you are of the probabilistic matching, are the laws protecting the data
and the potential harms to people strong enough, I would be less inclined to
regulate, maybe certify linking and algorithms if an algorithm is efficient
somebody is going to have a better product and get out there in the market and
sell that then somebody else.

But I would suggest a focus on what is the cost of efficient linking,
getting the data, having a good algorithm, versus the benefits of linking. I
think the benefits of linking are substantial, I can remember Clem McDonald
going years back saying the one thing we ought to do is accurately identify the
patient and I’d be happy with add three or four more digits to my Social
Security number, make one or two of them a check digit, and use that as long as
there were protections against using my other data in ways that I didn’t want.
Right now people can steal my identify and go out and use a credit card and get
all kinds of, make all kinds of charges, I may not have such a financial
penalty to pay but over the course of years that may come back to haunt me
again and again when I try to get credit and that’s not wiped out.

So cost of efficient linking and the benefits derived from efficient linking
that I would suggest as well as what Stan said.

MR. REYNOLDS: Listening to the testimony today I initially felt everybody
started off with no national ID but yet, and I’m going to try to attribute
these to the right people, Scott mentioned that maybe there could be a local
identifier, John Halamka stated maybe the last four digits of the Social
Security number, we’ve talked about a standard dataset which I think is a good
idea. RHIOs we’ve talked about which are still developing and I think Stan hit
it right on the head, this whole idea of trying to come up with a trusted
environment because as you listened to Teri give hers, and somebody mentioned
it in one of their questions, it’s a closed system. And this whole idea of
NHIN, this whole idea of everything that we’re talking about doing as an
industry and all of us are sitting in hearing after hearing talking about is
not a closed system, it’s a very open perverse environment that passes things
around.

So I’m troubled that I heard local identifier and last four digits of the
Social Security because if it worked like we heard I’m not sure why they came
up and I’m not sure why those tags were discussed. Now it may have been my
misunderstanding, it may be that I don’t understand the subject that much, but
if you have to add those things then what’s missing? And if you have to add
them then if we go, if we say the words, I know in our industry if we say the
word Social Security number right now people become aghast that you would dare
use that number and so it started bouncing around a little bit and so I think
we need to hear more to really drill down.

But I really want to zero in on this whole idea, we’re bringing this new
entity in, this is RHIOs, and if it has to do with matching patient data and
you’re going to turn it over to a RHIO then I just think there’s lots of issues
or questions that we could at least review. And I hope that if we have a
question on a unique identifier that we call it a unique identifier, not a
national unique identifier quite yet, under matching patient records because
that is a term of art that has very far reaching issues related to it.

So as a co-chair I would recommend that we discuss this as a subject of
matching patients to data, one opportunity for that is a unique identifier,
whether it will be local, whether it will be some tag that has nothing to do
with who you are or what you are, or something else, but I would recommend that
we stay away from the term. At least for now until we understand the subject
better and then would be in a position that if there were to be any
consideration of our direction that we would then make it such a subject. So
unless I have any negatives from the committee I hope that we can consider
that.

DR. WARREN: I still have Wanda, Jeff, and Mike, so Wanda?

MS. GOVAN-JENKINS: This is just a comment, in looking at the unique
identifier I started to thinking about in the correctional system when a person
commits a crime, and this is coming from a slightly different perspective, when
a person commits a crime at any age they are assigned a federal ID number and
that federal ID number follows them throughout their criminal career, whether
it’s 20 years, it’s true, whether it’s 20 years later. And I used to work in a
correctional facility, in a prison, and we used that number to identify that
particular person and we can see the history upon all their criminal activity
as far as their health care when they were in the prison. So I want us maybe to
investigate what challenges have they had with using that same number
throughout the years on that individual as far as with their criminal record,
with their health care background, I mean what challenges are there. And I
guess that would kind of help us with what kind of challenges it would be if we
were using a local identifier or a unique identifier in health care now.

DR. WARREN: Jeff.

MR. BLAIR: One of the things that pulls us together, I’m going to give us
the things that pull us together and the things that may make it more difficult
for us to reach that last mile of consensus. The thing that tends to pull us
together is when we look at the record locator solutions that have come up in
the same environment, a la where we have patients that have been identified
through insurance companies or PBMs, or other payers. In that case the
solutions for matching patients tends to gravitate towards the same type of
solution.

Similarly when we have health plans around the country or providers in a
local area or a state we could get convergence, and it makes sense, we wind up
doing that because it’s the least expensive way for us to get to an effective
solution. And we’re able to either ignore the issue of fraud, or we’re able to
ignore the issue of people coming over the borders for right or wrong reasons,
whatever it may be, and we’re also able to ignore the fact that very often we
don’t have identification for migrant workers that go from state to state to
state.

And so my thinking is that as we begin to explore this I think we should
keep a couple of things in mind, it is very desirable for us to come up with a
single solution nationwide. And I think in our efforts to do so we just need to
keep in mind that we may get to the stage where we can no longer ignore the
two, three, four, five parts of our health care delivery system that are not
“in our regular system anymore”, and the reason we may not be able to
ignore them, and I’m mentioning again the infectious diseases piece, is because
that does flow across states and because that does become major pieces.

And I know that different department of healths in different states are
beginning to work together completely independently to come up with a way to
track these people so that they could not only provide health care to the folks
that are infected but also be able to track to protect those folks that are not
infected yet and come up with ways to respond to it, so it becomes both a
public health problem as well as a patient care issue.

So in summary I think that it is still a good idea for us to pursue some
type of a procedure for matching patients to the records that would be one size
fits all but I don’t think we should do it to the exclusion of recognition that
large portions of our populations may not fit into certain assumptions we make,
that have some degree of consensus at the moment.

DR. WARREN: We’re beginning to run short of time so we’re going to limit it
to Mike and then Simon. Mike?

DR. FITZMAURICE: Two points that I’d like to suggest, one of them is even if
we had a unique health identifier national or not you would still want
probabilistic matching because there can still be errors in putting that number
down and you still want to check it against other information that you know
about the patient.

Secondly, if you had a unique health identifier and you built a firewall
around it and you could use it only for health reasons, if it were efficient it
would be used by others. The federal government said Social Security number
only for Social Security but then you had Medicaid program and they passed a
law saying you can use the Social Security number to avert fraud and abuse
maybe saving two billion dollars a year back when it was introduced. Now you
can use the Social Security number for virtually everything without federal
penalty.

So I would suggest that the protections afforded by a unique national
identifier, putting a firewall around it, aren’t really the protections, the
protections are how you guard the data and the authentication of people who get
access to the data.

DR. WARREN: Simon? Okay, go ahead Steve and then we’re done.

DR. STEINDEL: Actually I just want to go on record from a CDC point of view
because Jeff brought up twice infectious disease with migrant farm workers and
public health and this is not a new issue with respect to public health and
that CDC with our public health partners have been investigating ways to track,
treat, control, not just infectious disease issues but other health issues with
regard to migrant farm workers.

DR. WARREN: Okay and with that at close. I would encourage anybody though if
there’s any more information that you think of or people that you think that we
need to hear of please contact me or Maria because we will be having more
testimony obviously on this session. And I want to thank our speakers this
morning and also the committee and staff for a really good beginning to this
set of hearings on the data, thank you.

MR. REYNOLDS: Due to the fact that everybody kind of has to go across the
street to get lunch we’ll resume at 1:15. Thank you.

[Whereupon at 12:15 p.m. the meeting was recessed, to reconvene at 1:15
p.m., the same afternoon, September 21, 2005.]

A F T E R N
O O N S E S S I
O N [1:15 p.m.]

MR. REYNOLDS: Okay, after an exciting morning it looks like we’ve got an
exciting afternoon of about four different subjects that we’re going to be
dealing with, so the first one is under the auspices of update on key issues is
the CORE project and I’d like to welcome Robin Thomashauer from CAQH.

Agenda Item: Update on Key Issues: CORE Project –
Ms. Thomashauer

MS. THOMASHAUER: Thank you for inviting us today, we have been working on
this project now for about, well, including on the research about three years,
we’ve been working on it actively in terms of implementation since January of
this year so we’re excited to be able to share with you the progress we’re
making.

CAQH, I’ve been here before but for those of you who were not involved at
that time is an alliance of health plans and networks and we’re working
together across the industry to see where we can standardize business
processes, particularly to make it easier for physicians to work with the
health plans, and so that’s really our focus, our administrative simplification
opportunities in the interaction between the physicians and the health plans.

We had been working over four on five years on a number of initiatives
including a credentialing, standardization initiative, we worked on some
e-prescribing work which is what I came to speak to you about about a year and
a half ago. And as we looked down the road at where we were headed we stepped
back to take an overall perspective on all of the administrative activities in
the physician’s office and all of the places where the health plans interact
with those offices. And what dropped out of that were about 11 opportunities
for us to look at and to see how we could simply life in the provider’s office.
And the thing that kept rising to the top in those discussions was eligibility
and benefits and access to eligibility and benefits information.

Certainly HIPAA helps that, it’s a significant start, but it doesn’t go far
enough for the physicians, it doesn’t guarantee them enough information to make
decisions and to understand how to work with a patient. And so what we looked
at was how we could facilitate that interaction to enhance the amount and the
quality of the information that the plans were making available to the
physician particularly, or to any provide really at the point of health care
delivery.

What the physicians want was electronic access to accurate and timely data
and they want it in a very timely manner. Obviously what they’re looking for
are significant reductions in their costs and quicker access to the information
they need to make decisions. And in looking at how we could help that we looked
at a number of industries to see how they facilitated transactions and as so
often as we look at transactions we looked at the banking industry and the
financial transactions to see how they facilitated the connectivity between the
different parties and learned that one of the important things that they’ve
developed to facilitate that were operating rules.

So what are operating rules? As we look at operating rules they are business
rules for utilizing and processing transactions and they are the rules that
tell people how quickly information is going to move, what the information is
going to be, what we mean by the information that goes back and forth, the
exceptions that are allowed, error resolution, security, really sets all the
parameters for the specific transaction. They are the rules that enable ATM
transactions, they enable direct deposit, credit card transactions, all of
those are driven by operating rules and as we looked at those transactions a
similarity with the eligibility and benefit transaction was really pretty
evident and that’s why we moved down the road to look at operating rules and to
see if that was something that would enable better information transfer.

So after all of this research we looked at how we could go about this and
developed the Committee on Operating Rules for Information Exchange, or what we
refer to as CORE. It’s an industry wide stakeholder collaboration that was
launched in January of this year and really what we’re getting at is the answer
to the question why can’t verifying patient eligibility and benefits in
provider’s offices be as easy as withdrawing cash from the bank. It’s a very
straightforward question with as you might imagine a very complicated answer.

Our vision is to make available to providers no matter what front end system
they’re using and no matter what back end systems they’re talking to what
health plan covers the patient, whether this service is a covered benefit
including co-pays, deductibles, what amount the patient owes for this service
and what amount the health plan will authorize, will pay for the authorized
services. And we wanted that to be available no matter where a provider is
asking for that information and no matter through what service they’re using to
get that information. So that’s the vision of CORE.

The mission of CORE is broader then just eligibility and benefits though, as
we got together the stakeholders we talked about a lot of other transactions we
could look at down the road if this is successful and so the broader mission
for CORE as you can see is to build consensus among health care industry
stakeholders on a set of operating rules to facilitate administrative
interoperability, and as we look at this particular interaction people have a
lot of ideas and are ready to move on to the next transactions and what we’re
trying to do is say okay let’s slow down, let’s get this one done first, and
then we’ll have a model to move on to further transactions.

At this point we have over 70 organizations participating in CORE, we have
health plans, we have different provider organizations, we have medical
specialty organizations, we have five government entities including CMS,
standard setting bodies, vendors, and then we have consultants and others who
are interested in this particular arena. And every month we are adding more
organizations as the word gets out, more and more groups are coming in to
participate with us.

The whole effort is governed by a steering committee and I’ve included the
steering committee because I wanted you to see the range of organizations that
are taking leadership roles in this effort. WellPoint is chairing it, HCA is
vice chair, Humana, PNC, Siemens, Aetna, Blue Cross Michigan, Trizetto,
Montefiore and HIMSS are all organizations that are chairing particular
workgroups and subgroups to get this done and so you can see the breadth the
organization type that are involved with us on this and very active I might
add.

The role that CAQH is playing is really facilitator, the structure for the
initiative is, there’s a governing structure and there are a bylaws and today
the steering committee as it is now is appointed by CAQH but the bylaws say
that after the first year or when the first set of rules are completed we will
add a nominating committee at which point that nominating committee can offer
new chairs, new steering committee members, and also change the bylaws. So this
initiative will become much more independent after the first set of rules are
completed but we wanted to assure that this set of rules moved as quickly as
possible and that’s why we structured the initial stage as we did.

In getting together early on it was clear that we really needed to agree on
a set of guiding principles so that we were all moving in the same direction
and really were coming from looking at it within the same context. The first
thing is that no one segment of this industry could do this alone, what we
learned from the banking industry was that the broader the representation the
more success you’re going to have in implementing the rules and that’s why we
really sought to include as broad a range of participants as possible.

Another principle that we take very seriously is that just because an
organization is participating doesn’t mean that they’re committing to implement
the rules. We couldn’t get people to come to the table early on if we were
asking them to commit before they really knew what they were committing to, and
so participation does not mean commitment and you’ll see a little bit later how
we’re going to get at commitment.

The rules are being built on HIPAA, so many organizations have put so much
energy and resource into HIPAA that certainly it made no sense to go down a
different track and so we are building on the 270/271 to develop these rules.

We do support the movement towards real time data exchange but understand
that it’s going to take a little while for organizations to get there and so
our first phase does support both real time and batch data exchange. And the
most important thing I need to point out is that we are not building a switch
or a database. This has been tried before and really we feel strongly that the
market needs to develop the front ends and the back ends that are appropriate
for each organization, they need to be making those selections themselves. And
so what we’re creating is something that will be if you will vendor agnostic,
any vendor, any software will be able to implement these rules.

We’re going about this through a phased approach, this year we are
developing phase one of the rules focused on the eligibility and benefits
online, phase two, which we’ll be doing next year, we’ll be starting them in
2006 for implementation in 2007, would be looking at extending the eligibility
and benefits rules to include accumulators and estimated plan payment. Phase
three is really unknown at this point and it will depend on what the group
wants to move forward with based on how we’ve accomplished phases one and phase
two. So we’re taking this, I’d say we’re taking it slowly, we’re going step by
step but in fact we’re trying to move this along as quickly as we can.

Which leads us to our timeline, we started as I said in January, in August
we distributed a set of draft operating rules for feedback from all the
participating organizations and we’re in the process of receiving that feedback
now. Our goal is to take that feedback, send it back to the workgroups, have
them adapt the rules to the feedback that they receive, and then go into
testing and hopefully approval by the end of this year for implementation in
2006.

So what are we talking about? The work is being done by three workgroups,
the policy workgroup, a technical workgroup and a rules workgroup, and each of
those are focused on their specific areas of responsibility. What they’re
working towards is the development, a commitment process for commitment to the
rules, response time, testing, communication standards, service type codes,
patient financial responsibilities, acknowledgements and companion guides,
those are the content that the workgroups are focused on and where their draft
and recommended rules are going to focus.

As examples, the pledge, we really believe, or the workgroups I should say,
all the workgroups believe that there needs to be a binding pledge that states
the commitment to the organizations to implement the rules. And so we would be
asking them to sign a pledge that has been developed and is in draft form to
implement and comply with the eligibility and benefits rules. Really what we’re
hoping to do is establish a commitment and a trust that parties will be
participating in the implementation.

The process is also going to include a certification process, we have an RFP
out for companies who are currently certifying, on doing HIPAA certification,
and the certification is what it sounds like. We’re looking to award seals for
certified health plans or vendor’s clearinghouses and for organizations that
are endorsing the rules but don’t, their businesses don’t require them to make
the transactions we’re asking them to also be certified as a CORE endorser
signifying their commitment to the concept.

One of the rules is around response times and as you can see we have
developed proposed response times both for real time and for batch, real time
we’re looking at 20 seconds and for batch we’re looking at between 9:00 p.m.
and 7:00 a.m. the next morning for a batch transaction. And compliance will be
that an organization measures 90 percent within the calendar month, so that’s
the guideline for meeting certification.

Another area that we’re looking at are patient identifiers, I know that you
were talking about that this morning, we are looking at patient search and
match, submission of a HIPAA 270 eligibility only one time and with a minimum
amount of ID data to find an individual.

Right now we’re looking at encouraging all four HIPAA implementation guide
minimum search options, the patient ID, the first name, the last name, and the
date of birth. And right now we are looking at ways that the plans can
implement this within their own organizations and we’re looking at standards
that have been set and are being used by the Minnesota HIPAA Collaborative,
those algorithms have been very successful and rather then reinventing the
wheel we’re looking at those for our plans.

The status right now as I said, there are draft rules, mission vision pledge
certification process, we are getting feedback and we are hoping for
participation for implementation in early 2006.

We are very excited to be moving so quickly on this and to have as much
support and commitment as we have from the 70 organizations that are around our
table and look forward to finishing this first set of rules and really seeing
what it’s going to take to roll them out and to get even broader adoption in
the industry.

And those are my prepared remarks, I’d be happy to answer any questions.

MR. REYNOLDS: Okay, thank you. I’ve got one from Jeff and then Stan.

MR. BLAIR: Robin, welcome back. Actually what I’m about to say is not as
profound as what you couldn’t hear, was the establishment of CORE in any way a
response to the proliferation of companion guides that —

MS. THOMASHAUER: I’m sorry, the proliferation of?

MR. BLAIR: The companion guides that health plans were developing because
there really was not, we realized there was another level of clarification that
was needed, I’m just wondering if that was part of what was driving this, or
maybe you could just put it in context of how did all of these folks come
together, you’ve got a large number of health plans and providers that are
participating in this, there’s broad recognition that this is an issue, and
when you started to discuss this it took me a while to understand what was
behind it and the only reason that I understood some of it was because of other
testimony that we’d received here on NCVHS, so I’m sort of feeling as if
there’s been some difficulties that the health plans and the providers have had
that enabled you to get this broad participation and could you help me
understand the driving forces behind this.

MS. THOMASHAUER: Sure. Just to back up for a second on companion guides,
several years ago we actually tried to standardize the companion guide format,
we worked with WEDI to do that and put a standard template up on the web and
tried to get the word out and didn’t have a lot of success quite frankly as
evidenced by the hundreds of guides that are out there. That was not a direct
driver though, the driver was really what we were hearing from the physician’s
offices and practice managers around how difficult it was and how much time
their staff was spending trying to get information about eligibility and
benefits before they see a patient, the amount of time they spend on the
phones, the fact that a lot of plans are making this information available
through their own websites but for an office manager to go in and out of ten
websites in a day is just not an efficient use of their time. So it was really
the lack of information available to the practices at the time of delivery that
drove our interest in this area.

MR. BLAIR: And these were practices that already had implemented the
270/271?

MS. THOMASHAUER: I think not a lot at that point to be perfectly honest but
I think that their perspective was the amount of information they were going to
be getting from the 270/271 was not going to be sufficient and they were still
going to have to make those phone calls and go to the websites. So it was
really the interest in making more information available to the provider to
eliminate a lot of their rework, or the time on the phones.

I was actually around the same time in a physician’s office and they didn’t
have the authorization ahead of time and I sat there while they sat on the
phone with the insurer who will remain nameless for quite some time trying to
get authorization and in the end they couldn’t. So I think a lot of us felt it
personally but we did a lot of quantitative and qualitative research to get to
that point.

MR. REYNOLDS: Jeff I’d like to comment on that also. A lot of people
implemented it initially, it was okay to implement the 270/271, was the answer
yes or no, which was not a complete answer, so a lot of what was out there was
you could be HIPAA compliant and answer yes or no and this takes it to the next
level of actually filling out information rather then just saying yes or no.

MS. THOMASHAUER: And actually the information that we’re providing was
considered in the HIPAA legislation and they are optional elements so they have
been identified but they’re option and were not available in most cases, so we
are building on that.

MR. BLAIR: Thank you.

MS. THOMASHAUER: Did that answer your question?

MR. BLAIR: That helped me quite a bit, thank you.

MS. THOMASHAUER: And one of the things we are doing through this is again
encouraging a standardization of the companion guides, so that is part of this
discussion is to try and get there as well.

DR. HUFF: So a question of basically how you relate to other organizations,
number one, one could argue for instance that what you create should be input
back to X12 so that they could basically reinforce and disambiguate whatever
problems there might be with the current standard. And the second question is
what is the difference in scope or what you’re doing versus for instance the
HIMSS integrating the health care enterprise activities, and do you have any
relationship or a different scope or feel from that activity? So that’s two
questions, sorry.

MS. THOMASHAUER: In terms of X12 we recognize that we need to be closely
aligned and working with X12 and so X12 is participating with us in our
workgroups and on the steering committee so that they know what we’re doing and
we get their input as well, so there is a lot of discussion and conversation
with X12 on that.

In terms of the IHE I have to be honest and say we have not had a lot of
discussion with them, Steve Lieber just joined our steering committee very
recently and we don’t have a relationship, a deep relationship with HIMSS at
this point.

RE. REYNOLDS: Okay, Judy?

DR. WARREN: I just wanted to follow-up, one of your slides dealt with
patient identifiers and we’ve heard this morning about those, and I notice that
of the one, you’re also proposing a match strategy of using certain data
elements but you have patient ID in there, could you talk more about what that
ID was, or what that ID is and why you chose patient ID as one of the match
elements?

MS. THOMASHAUER: The patient ID, health plans use patient IDs, they create
patient IDs, and they are interested in retaining that as a, today anyway, as
one of their criteria because they have assigned that and it means something to
them internally into their systems.

DR. WARREN: So this is the health plan ID you’re talking about, okay.

MR. REYNOLDS: Is that it? Maria?

MS. FRIEDMAN: I’m interested in how this all fits together with
e-prescribing because one of the promises of e-prescribing of course is to
eliminate the rework and all the time spent on the phone and you’ll be able to
do it in real time with some of these e-prescribing systems. And so I’m
wondering how that fits into this in general.

MS. THOMASHAUER: Well in the short term eligibility, pharmacy eligibility is
a different type of eligibility, so for example RxHub has access to all of that
eligibility through their PBMs, so today what we’re looking at is medical
services eligibility. We would very much and we continue to talk to RxHub to
see if we can engage them with us and at some point work together on it but
right now the pharmacy eligibility is a separate set of data and comes from a
different place within the plans.

MS. FRIEDMAN: Right, but I think as things evolve and e-prescribing becomes
part of a larger context of electronic health record systems and electronic
medical systems in general where all of these functionalities and all these
different things are linked, it just seems like you have a piece of it, the
e-prescribing people have a piece of it, and I’m wondering if there is ever
going to be convergence.

MS. THOMASHAUER: Well, we would like the operating rules model really to
have broad, we see it having broad applicability around each transaction, this
is really the first, it’s a pilot if you will, it’s a first transaction to
apply operating rules and see how they work. As I said our phase two and phase
three, we think this is a good model down the road for interoperability, it
would just be required to create those operating rules around each type of
transaction. So it’s really a model to look at.

MS. FRIEDMAN: Just one last question, do you those operating rules that
you’ve established for this will hold for the other transactions or do you
think you’re going to have to wait and see and judge it transaction by
transaction?

MS. THOMASHAUER: Well these rules that we’re creating are really just for
this transaction and so we’re creating a model and a structure really for
creating those operating rules and then hope that this process is successful
and that as more and more participants engage in this process we’ll take on
more and more transactions. So I think it has the potential to really support a
lot of different types of transaction.

MS. FRIEDMAN: Because I look at those rules and I do think about their
applicability across other areas —

MS. THOMASHAUER: And if you look in the financial industry they started with
one set of transactions and then built and built and built and today we have a
lot of expectations that those things happen invisibly for us and they do
because of that, but they also had to build it one transaction at a time.

MS. FRIEDMAN: Thank you.

MR. REYNOLDS: I have a couple questions, Robin. You said after the first
year that CORE would become somewhat independent from CAQH but I think one of
the reasons that the industry grouped up is because of CAQH’s focus and
leadership and do you worry about sustainability, especially as the
transactions change and especially as people want more and more information, if
it can remain sustainable outside your auspices?

MS. THOMASHAUER: I didn’t mean to say it would become more independent but
it will be more self directed I think is a better way to say it. We believe
that to get the kind of support we need as broadly as we need it it can’t be
just the health plans driving this. And yet the structure, even with a
nominating committee, in the end the rules the way it’s currently configured
with go through the CAQH board. And the CAQH board has a veto power, they do
not have an approval power, so it’s 20 days and if there’s no veto they are the
rules. And I think that, I didn’t really mean to say it would be independent
but it will be more self directed. I think that what we hear a lot, what we
heard a lot in the early days had to do with the health plans running this and
there’s healthy skepticism around that from the provider community and we
really want this to be a collaborative effort and want to have broad
participation and so we felt that it needed to be more self directed as it got
on its feet and had more confidence in their ability to make the decisions. But
that is why we kept control the first year because we wanted to keep it moving,
so there’s going to be a balance there, Harry, but independence is probably too
strong a word.

MR. REYNOLDS: Another question, any time anybody talks about batch and real
time, real time to most people sitting at a desktop is two seconds. Is the 20
seconds, back to your point a minute ago, is that a health plan standard or is
that something that the doctors and other have agreed would be inappropriate
real time? Because as one of the things that this committee continues to look
at is adoptability, whether or not standards or anything else that are out
there are going to be held, and so 20 seconds was an interesting choice.

MS. THOMASHAUER: And it’s a compromise, but I’d like to introduce Gwen
Lowes(?), who’s our project director, who is involved in all of those
discussion and really can answer them in some greater depth then I could.

MS. LOWES: It’s a compromise really but it’s really a round trip, so as
Robin has talked about there are a number of stakeholders are at the table,
everyone from the providers to the vendors to the clearinghouses to the health
plans, and we wanted to make it that it was a round trip versus hops in a
system, we’re at the point right now we’re looking at the hops in who’s
responsible, what time do they have in that 20 seconds for their hop. We also,
we have a lot of the Blues plans around the table and we want to make sure
we’re working closely with Blue Exchange because that’s working so well right
now, it’s a great model for us to look at with Blue Exchange, we’ve got some
great lessons learned from that —

MS. FRIEDMAN: For the uninitiated what is that?

MS. LOWES: I’m sorry, the Blues have a capability to exchange eligibility
data across their national plans and so we’ve been taking some lessons learned
from Blue Exchange and some of the compromise we’ve learned from that model
too. So I guess it’s 20 seconds full of hops and do you mind if I comment on
the companion guide question you had asked, I think Jeff you had asked it
earlier, it wasn’t as Robin talked about absolutely the driving force, it was
really the administrative simplification piece, but a lot of the vendors are at
the table because there are so many companion guides out there and they’re
hoping to reduce those companion guides by having a set of operating rules. So
indirectly it was a driving force to get the vendors to the table.

MR. BLAIR: Thank you for clarifying, and could you clarify one other piece
in your response here, you were saying it’s a round trip, I have a feeling that
round trip may mean something a little more complex then what I thought of as
an inquiry and a response, because it is 20 seconds. Could you elaborate what
you mean by round trip?

MS. LOWES: From the point where the inquiry is sent from the provider’s
office to actually hit the buttons and the inquiry and it comes back to their
office, so the eligibility inquiry leaves the provider’s office through the
vendor system of their choice, it maybe goes directly to the health plan, maybe
it goes through two clearinghouses, one depending upon on how the vendor works,
that’s completely up to the vendor, we’re not getting involved in any trading
partner arrangements in phase one. And then the information comes back to the
provider’s office so they actually can view it —

MR. BLAIR: Does the fact that it goes through clearinghouses, is that what
tends to increase the response time?

MS. LOWES: I think everyone has a role for improvement in the response time,
it’s not one stakeholder, some of the vendor systems will work a certain way,
the provider has a role in they actually are going to have to follow some
certain rules in order for the eligibility inquiry to work better. The health
plans have a role, so unless everyone is on the same page you can’t reach a
better response time because we’re all dependent upon one another.

I had one other comment, Maria I think you asked the question about
e-prescribing and if there was applicability to other rules, there’s a few
things that the group is looking at with regard to telecommunications like an
HTPTS(?) standard in phase one for CORE that may directly be applicable to
other transactions as we move in that direction, those that are more specific
to eligibility like the patient identifiers aren’t as clear but there is areas
that some of the RHIOs have looked in and we’ve looked at lessons learned, like
the companion guide rule that Robin had talked about, the flow and format for
phase one is involved in phase one of CORE and then also an HTPTS standard.
There’s a few other ones in that phase one package that may work well for other
transactions.

MS. FRIEDMAN: Just a follow-up on Gwen’s comment, I think that’s important
because one of the things that is the subcommittee’s charge is looking at
authentication and non-repudiation and of course as we go to more open systems
having an any more secure way of communicating information over the internet is
a good thing and more and more people are doing that and so —

MS. LOWES: And the group has spent a lot with the draft HTPTS standard which
we can share with you if you don’t have it yet, they’ve spent a lot of time
about in phase one as you were talking about what’s implementable, what’s
feasible, do we set a minimum standard around the format for authentication or
is just the data elements I phase one that they have to be included in the
format is up to everyone else, and that’s the direction that the group is in
right now, what’s feasible for phase one, the minimum standard, and that
authentication needs to be included, certain data elements but now how they’re
formatted is up to whoever implements it.

MS. FRIEDMAN: Because again, that’s a continuing issue not only in terms of
e-prescribing, especially as we go, or e-signature or other things for
controlled and non-controlled substances, some of these other transactions.

MS. LOWES: You had asked about HIMSS, I think it was, one of the things
we’ve been careful to do as Robin had talked about is getting X12 and HIMSS at
the steering committee level so we don’t create any rules that are not
compatible with other rules that are being created and you can’t obviously have
interoperability if the rules don’t work together so we’ve been looking and try
to do the lessons learned at the RHIO level, HL7, X12, anything that might be
good for us to know that we don’t want to go down a certain path where clinical
and administrative can’t speak.

MR. BLAIR: In the answers that you have been giving us I’ve started to have
a different image of the environment that CORE is mapping itself against
because originally when you started to talk to us I was basically thinking of
providers and payers communicating back and forth directly and it sounds like
you’re really thinking that this communication is going to be going through a
health information exchange or some other hub or multiple clearinghouses. Is my
understanding correct now of the background that you’re working within?

MS. LOWES: Yes, and I guess the response time is a perfect example is that
we’ve had all the stakeholders at the table to figure out what is feasible and
that 20 seconds is feasible but it’s a push for the industry, and if you look
at with another rule is that we have service level codes that are currently
optional under HIPAA but they’re not being used in the industry and it would
really help the providers to have them but the payers could offer those service
level codes but if the vendors don’t change their systems to have that detail
incorporated into their front end it’s not going to do any good for the payers
to change their systems if the vendors don’t change their systems, and then the
providers aren’t educated on how to use the data.

MR. BLAIR: Now the one thing that I don’t understand, I mean I think what
you’re doing is great and I think it’s the right thing to do, but since you’re
beginning to have performance rules for the system as a whole how do you relate
that back to accountability for individual partners or players within the
system? Because I can see finger pointing going on —

MS. LOWES: The group as Robin had talked about there is a certification
component in phase one and that group had said they want to do something that
is similar modeled around what happens with HIPAA that before any type of
enforcement happens or hard core finger pointing that every effort is made to
remedy the situation. So there is a process in place in the draft core phase
one rules for certification enforcement, that if a complaint is filed against
someone that they have to be involved in the transaction, if they feel that for
instance the response time isn’t being met, a provider’s office, they can file
a complaint, and then CORE has the responsibility to identify who in the hop
may, specific to response time, may have the issue and every effort is made to
resolve it and the opportunity to improve it. And in phase one the worst type,
the highest level of enforcement is that you lose your CORE seal if you
repeatedly fall out of non-compliance after you’ve been certified.

MR. BLAIR: So that’s really neat, so you’re setting up a process for
accountability and for reconciliation.

MS. LOWES: Absolutely.

MR. BLAIR: That is really neat.

MS. LOWES: But I want to emphasize that the process we’re setting up,
there’s a number of people that wanted it to be much more stringent for the
accountability as well as the enforcement, and those that wanted it to be less
stringent, and we’re taking an approach that the group feels is doable for
phase one and focused on as Robin had talked about with the pledge just
demonstrating that the industry is trying to work together to solve the
problems versus penalizing people so they won’t come to the table.

MR. REYNOLDS: One last comment, when the word industry is being used I hope
that it includes PBMs, I hope that it includes practice management systems,
because if it’s the membership of CAQH, I’m just asking, so if it comes across
as the membership of CAQH or CORE then back to Jeff’s earlier point, if two
members of CORE get it to the front door of the doctor’s office and the
practice management system can’t handle it, then 20 seconds to the person who’s
actually sitting at the desktop may be a misnomer of significance, so can you
comment on that.

MS. THOMASHAUER: We couldn’t agree with you more. When we say the industry
we do mean the broad industry, we’re not referring to the payer industry.

Before we started this we took this idea to a broad range of organizations
including practice management vendors because without their willingness to
adopt the rules there’s no way to get the data from one end to the next, so we
feel strongly about the participation and the materials that I’ve left behind
includes the participation lists and you can see the range of vendors that are
even today on there and certainly we hope to engage a much wider range of
vendors but we think it’s a pretty good start if you look at that list.

If you are working with organizations who are not involved with this yet
please encourage them to do that and to give us a call because we can’t do this
if every piece of this pie is not playing at the table. And one of the things
that we learned from the financial industry was that without the right
government agencies engaged it wouldn’t happen also and that’s why we’re so
delighted that CMS is involved with us because they are the biggest payer out
there.

MR. REYNOLDS: But as we think of, as we look at HIPAA ROI, something like a
CORE seal of approval might be a way to get some of this other stuff we’ve been
looking for this ROI might be a way to get people to buy in.

MS. LOWES: One of the things that the long term vision subgroup has been
doing that sits under the policy group, they’re not only looking at what could
happen in phase two and later phases, they’ve also developed some measures of
success that participants of CORE are going to be asked to track and it will be
everyone in the hop so the plan, the clearinghouse, the front end vendor, and
the providers, and they’ve set up a process where you measure ROI by tracking
what did it cost you to implement the CORE rules in phase one, and for some
people if they’ve adopted more of HIPAA early on that was option, it will cost
less, and for those that didn’t it will cost more, some vendors don’t have an
eligibility product or they don’t have it to the level they’ll need, they’ll
need to make changes.

So the cost will change, will vary by participant, in the ROI that group has
picked up about either two to four measures to track either reduction in FTEs
spent on checking eligibility or track increase in electronic transactions, and
assuming that two to four metrics are done by stakeholder and if some
assumptions are made about the cost of, an average cost of FTE, average cost of
electronic transaction up front from the group so we’re not, it’s going to be
something that has to be national versus regional. The group will be tracking
the ROI by stakeholder and publishing that after a six month period of using
the rules. And CAQH, that’s going to be one of our key roles is getting the
volunteers to submit their data in standardized formats and agree to the
average cost for some of these items which is a challenge as I’m sure you all
know.

MR. BLAIR: That’s outstanding.

MR. REYNOLDS: There are never challenges with volunteers.

MS. THOMASHAUER: Just to get back to one of the questions and then we don’t
need to take any more of your time, we don’t know what the process is going to
look like down the road. Today we think, we know that we need to include the
payers, the providers, the clearinghouses, the practice management systems but
whether or not in the long run we need clearinghouses, right now they’re very
important but our rules can facilitate the transaction between any two parties
so it may evolve different, we just don’t know, but we want to create these
rules so that they can support the transaction no matter how many parties are
involved in it.

MR. REYNOLDS: Thank you, very helpful information, appreciate it. We wish
you success.

MS. THOMASHAUER: And if anybody is interested in seeing the draft rules we’d
be happy to make copies available.

MR. BLAIR: Yes, outstanding.

MR. REYNOLDS: We’re right on schedule, that’s a good thing. Next, she’s
getting set up, Halley that’s going to talk us about, she’s from the FHA and
going to talk to us about the CHI standards.

Could everyone on the phone please identify themselves?

DR. DESI: This is Dr. Desi, Social Security Administration.

MR. KROTMAN: This is Alan Krotman and Brent Han, we’re in the FHA PMO.

MS. ORVIS: This is Nancy Orvis, Military Health System, DOD.

MR. REYNOLDS: Is that all your friends, Beth?

MS. HALLEY: There might be a few more coming.

MR. REYNOLDS: Okay, we’ll go ahead and get started.

Agenda Item: Update on Key Issues: CHI – Ms.
Halley

MS. HALLEY: My name is Beth Halley and I would like to thank Mr. Reynolds
and Mr. Blair for allowing the CHI Workgroup to come forward and present an
update to you all today, so thank you very much.

I work with the MITRE Corporation which is a federally funded research and
development corporation and we are in a position supporting the Federal Health
Architecture with HHS. I’m also the facilitator for the Consolidated Health
Informatics Project and have been nominated to come and present to you today. I
would like to mention that Marcia Insley who is one of our co-leads for our
allergy workgroup is here in the room with us, Dr. Desi who is one of our leads
and I’ll mention that again in the presentation is on the line, and Dr.
Hedrix(?) and Dr. Swasha(?) from NIH, also one of our co-leads, may be joining
us.

The purpose today is to present you all with an update of CHI, I am not a
subject matter expert in all of the areas but I do facilitate all of the
workgroups. So I will be giving you an overview of where we are with CHI today.

One of the main changes probably since the last time you heard about CHI is
that it has been reorganized to be under the Federal Health Architecture
program under the Office of the National Coordinator, and we’ll talk a little
bit about that. We’re going to give you a brief update on each of our
workgroups as I mentioned. I want to talk a little bit about some of the
collaboration activities, we’ve been working with USHIK, the caDSR, as well as
NIST, and then we’ll complete the presentation today with some of the next
steps as we move forward with CHI.

As I mentioned I think the last time we spoke to you the CHI Initiative was
one of the OMB initiatives in the eGov presentation, I believe the last
presentation you may have received was back in May of 2004 where approximately
20 of the standards were brought forth for recommendation. Since that time the
CHI Initiative has moved under the Federal Health Architecture, Captain Forbes
at HHS is the program manager for the FHA project, and that is under the Office
of the National Coordinator as I mentioned.

The national coordinator is in the process of establishing four different
departments and these departments are identified here and the FHA, the Federal
Health Architecture, of which CHI is now part of, will be considered part of
the Interoperability and Standards Department, so that’s where we will fit now
as CHI moves forward.

One of the other changes that you may or may not be aware of is when CHI
moved under FHA a new website was created with all of the standards and it
basically migrated the OMB website over to HHS. Listed here is that URL for
those of you who may not have had the opportunity to see it, and you will find
it, it is under the Office of National Coordinator, Federal Health
Architecture. All of the reports that you all have adopted are part of that
site as well.

And as you are well aware that the Office of the National Coordinator is
responsible for the nationwide look at health information technology so CHI
fits nicely within that organizational structure. The co-leads for the CHI
workgroup are Gail Graham from the VA and Captain Mary Forbes from HHS, and
that is at the workgroup level.

As we move down to the sub-domains, or if you like the actual different
terminology domains where we are working on adopting and recommending to you
all standards we have three workgroups that we are currently working on, a new
workgroup that you’re probably not familiar with because it was created after
the original phase of CHI is allergies and I’m going to talk a little bit about
what we’re doing with allergies, and as I mentioned Marcia Insley from the VA
is our co-lead for that and Marcia is here with us today.

Disability and multimedia, these are both domains that you perhaps remember,
they were part of the phase one, very complex areas, and they are two of the
areas that we have reestablished and are taking somewhat new approaches on how
to move forward with adopting standards for those areas, I’ll talk a little bit
about that as well.

The allergy workgroup, similar to all of the CHI efforts is it
interdepartmental, we do try to look across all of the federal agencies and
bring in subject matter experts that have experience and interest in this area.
The CHI Allergy Workgroup right now, CMS, DOD, the EPA, the FDA, the National
Library of Medicine, and the VA. And basically the approach that this workgroup
has taken is to get a framework for what are the allergy related terminologies
we need to look at in order to come up with vocabulary standards in that area.
And the framework that we looked at was the HL7 information segment for both
allergy and adverse reactions, and within those information segments we’ve come
up with the different vocabulary needs for addressing allergies.

Also in that process has been brought forth to our workgroup that HL7 is
working on the version three information model which really does take a little
bit different look at how allergies and adverse reactions and intolerance and
observations are considered and the concepts that are related to them. However
we really feel like the vocabulary work that is being looked at under the HL7
2.0 versions really will be able to be implemented in a version 3.0 as well. So
I just want to give you the framework for how we determined what vocabulary
needs we were looking at.

Within the HL7 environment we were looking at things like allergen type, is
this a food allergy, a drug allergy, an environmental allergy, allergy
severity, mild, severe, moderate, allergy reaction, is this a rash, is it an
anaphylactic reaction. The allergen name and the allergen group, this is where
this field gets very complex, particularly as we get into the terminology for
drugs, drug names, drug classifications, and we have a lot of experts, FDA, VA,
DOD, have all been very instrumental in helping to work through this very
complex area.

As you may know we do have some CHI standards that have been adopted in this
area, the NDFRT is one area for drug classifications but it looks really at
only certain aspects of drug classifications so we were trying to look at how
to address drug classifications as well as drug names. We also are looking at
combination of both proprietary and non-proprietary standards in this field.

And some of the strong candidates just to give you a sense of who seems to
be the strongest candidates in this field, SNOMED, the FDA SRS which is
including, going to be including a whole combination of drug types of
terminologies, the UNII codes, which is the unique identifier, the structure
product labeling which will include things like the drug names which we’ll be
pulling from the RxNorm, the VA DOD non-drug allergens list, this is a
collaborative effort that’s been worked on through their health data repository
effort. We’re looking at having that being mapped into SNOMED and hence into
the FDA, and then into the FDA SRS and potentially the EPA SRS. The NDFRT I
mentioned for drug classifications, and the food allergen label consumer
protection act to look at food classifications.

Where we are in the actual process with allergies, this is a new terminology
workgroup that got developed or initiated this summer, we are in the process
now of developing a draft report which we would like to have the opportunity
perhaps at your next meeting to bring that report forward with our
recommendation. And as I mentioned some collaborative efforts with some of the
other allergy vocabulary initiatives going on like HL7.

The disability workgroup, and I know Dr. Desi is on the phone as well, again
another very collaborative effort, Dr. Desi is with the SSA and Jenny Harvel(?)
is with ASPE, they are our two co-leads, AHRQ, CDC, CMS, DOD, Department of
Labor, Workman’s Comp, has just recently got involved with our efforts, the
NLM, the VA, and the VBA, the Veterans Benefit Administration, also recently
involved, it’s interesting, within the disability domain depending on the area
there are very different uses for disability terminology and if you remember
from phase one from the report that was brought forth to you part of the reason
that a standard did not get adopted is because they’re used in such a different
way. For instance in CMS they look at it from a very clinical perspective,
they’re working with the MDS, the minimal dataset within the nursing home
environment, where SSA is looking at it maybe from an eligibility and a
benefits standpoint and the way they classify and determine is really based on
a Congressional mandate. So we have two very different needs within this
domain.

So the approach as we moved forward into phase two knowing that not one
terminology can really at this point be, can really support the many different
uses, was for the different organizations to come up with use cases for this
terminology. So we are in the process right now, CMS is working on a clinical
use case, the SSA is working on a disability eligibility and benefit use case,
and what we’ll be doing is as we look forward is to try to look across the
federal government ensuring that we’re looking at all the different uses of the
terminology and then trying to figure out a way either of harmonizing the
different terminologies like ICF and SNOMED and LOINC and the different ones
that address different areas and see if there is a way to harmonize amongst
them. And if not there may be a need to adopt different standards for different
use cases.

Where we are right now, we are in the process, two of our use cases have
been defined, we’re looking at different vocabularies to match those use cases,
and I think as I said the end point is trying to determine whether or not we’ll
be able to identify one particular standard or multiple standards and if they
are multiple standards how are we going to continue to harmonize across both
the use cases and the federal government.

May I ask Dr. Desi at this point if he has any comments or should we wait
until the end, Mr. Reynolds?

MR. REYNOLDS: If it fits in best, you’ve got the floor for the next period
of time so however you want to orchestrate it.

MS. HALLEY: Dr. Desi, do you have any comments at this point?

DR. DESI: The connection is not real good but let me, I think you’ve done a
good job of summarizing what we’re looking at here, is that there are different
uses of disability vocabularies, or disability vocabulary across the different
federal agencies and in one sense we have to focus on not the concept of
disability because that’s a legally defined term as opposed to the medical
terms which may be more uniform throughout the agencies. In other words if
disability to Social Security means one thing, it means something else to VA,
and it means something to DOD and it means something else to CMS. But if I say
this individual can only lift up to ten pounds, that’s straightforward,
everybody understands that.

What we’re looking at doing, I hope I’m not being repetitive, like I said it
wasn’t the best connection, is to define a core vocabulary with a hierarchical
structure that supports it and then each agency can then map its particular
definitions to what’s there, in other words for Social Security when we say
severe we may mean something that comes out to a certain code, say at a level
two, where CMS may say well that same type of thing for us is a level four. And
we’ve also taken the additional step to recognize that at least for Social
Security we may have to make certain regulatory changes to fit in to whatever
the adopted standard in, in other words we may not get 100 percent
harmonization with our needs to the vocabulary that’s finally selected so we
may have to make some tweaks to our regulations to harmonize with that and to
adopt that.

And I think that pretty much covers what we’re doing and we’re going to try
to move this along fairly quickly because in a sense we’re at least a year
behind most of the other workgroups in terms of we haven’t actually recommended
a standard much less gone to the point of how we’re going to implement that
standard. That’s about all I have.

MS. HALLEY: Thank you, Dr. Desi.

The next workgroup that CHI has been working with is the multimedia
workgroup, again and also a workgroup that came to you a year ago in May,
presented a recommendation, but really wasn’t able at that point to come up
with consensus. So the group has been working pretty diligently since then in
trying to come up with a consensus report that they could bring forward to you.

One of the steps that they have taken is to also to break out six different
types of scenarios that may not fit into what the recommendation would be, for
instance DICOM is the strong candidate for multimedia but there are many
situations where DICOM, particularly in a transitional standpoint, may not be
the right solution. So the report has broken out six scenarios, I’ll give you a
couple examples, if you’re a DICOM system and you need to send to a non-DICOM
system, that non-DICOM system might be HL7 compliant, how would that be
addressed. So there are six different scenarios that the report addresses at
this point.

Where we are with this, we are in the final stages of developing consensus,
there is still some vetting to be done with the report, and as I mentioned with
allergies we hope that at your next meeting we’ll be bringing forward a report
for recommendation.

MR. REYNOLDS: When you say next meeting did you mean December or February or
—

MS. HALLEY: I was thinking it was December, keep our fingers crossed on
that.

Some of the collaboration activities that have been going on since the last
time CHI presented to you, one of them is with USHIK, it’s the United States
Healthcare Information Knowledge Base. This is an initiative under CMS and what
it is is they’ve developed a registry that stores all of the different CHI
standards. And when I say that it may store them, it may also be links to them,
so if they are like SNOMED, a link to the NLM system, etc., so this is a
portal, you can go there now, it is being developed, we have presented it to
the CHI Workgroup and one of the suggestions or one of the approaches that has
been presented to us is to link that through the next initiative noted here,
the caDSR, which is the National Cancer Institute’s registry —

MR. BLAIR: C a D —

MS. HALLEY: ca for cancer, small ca for cancer, capital DSR and that’s the
data standards repository.

MR. BLAIR: Thank you.

MS. HALLEY: So the caDSR. And the links are noted here and the NCI folks
came and presented to the CHI group and we were going to work on some potential
collaboration there between USHIK and caDSR where caDSR may be the back end
processing a lot of these standards and links and things like that and USHIK
would be the front end portal to the population.

Another system that has come to CHI and presented is the NIST Healthcare
Standard’s Landscape, you also see it called HCSL, and what NIST is doing is
they’re creating a system with all types of health care standards, not just CHI
but a place where if you want to go and look at standards that are available,
may or may not be CHI adopted standards, but this will be a very robust type of
a system with links and information about all kinds of health care standards.
And one of the things we’re going to be presenting with NIST is the possibility
of how we might manipulate and use that for not just linking to CHI but
actually putting data from the workgroups in there and the agencies and things
like that and we’re just starting that process, NIST came and presented to us
at our last meeting so we’re going to be following up with that as well.

In terms of our next steps, as I mentioned our three workgroups, allergy,
multimedia, and disability will be continuing their efforts and we would in a
hopeful situation look forward to coming and presenting reports to you in
December. One of the other functions that CHI has been involved with,
particularly under OMB’s guidance, is the need to not just identify standards
but how do you implement these standards, so the idea of developing
implementation guidelines. By the end of the year with the assistance of DOD
and VA we hope to have a DICOM implementation guideline and an HL7 CDA
implementation guideline available. They are both currently in draft forms at
this point.

Continue the collaboration efforts, which I mentioned, and also and probably
very significantly is to coordinate with the new office under the Office of the
National Coordinator and their efforts to develop standard harmonization
through the new RFP that will I guess shortly be awarded and the other
activities within the Interoperability and Standards Department.

Thank you.

MR. REYNOLDS: Okay, thank you very much. I’ve got a question from Jeff and
then Simon and then Stan and then me.

MR. BLAIR: All right, Beth thank you for bringing us up to date on what’s
been happening with CHI and the Federal Health Architecture, I’ll have to wind
up saying I’m kind of excited because this is an area that I think is critical
to the development of the infrastructure upon which so much of our health care
applications will be riding.

One aspect that I’ve run into in the part of the world that I’m living in
part of the time of Arizona, Utah, Colorado and New Mexico, Four Corners
Tele-health Consortium, is we’re trying to see how we could wind up forging
harmonization of the emerging tele-health networks, which as you probably are
aware tend to provide imaging and audio, video and audio and stills, in many of
these cases to rural and under served populations, how do we start to link that
to the emerging health information exchanges and how do the standards for both
begin to enable us to do that, how do we harmonize those? Has CHI or the
Federal Health Architecture begun to look at that in terms of RHIOs?

MS. HALLEY: Mr. Blair, I’d have to be honest with you, I am not familiar
with efforts to harmonize with the RHIOs and the tele-health efforts. The
effort particularly in the multimedia group has been really to look at as I
mentioned those six scenarios, and particularly in a rural situation we may be
in a situation where you have a large hospital trying to communicate with a
rural situation that may not be DICOM —

MR. BLAIR: Because I think of DICOM for the most part as radiological
images.

MS. HALLEY: I believe it also has the audio, the wave form data, and some of
the other wave form audio and video, and I believe they’ve actually looked at
each of those areas to potentially adopt DICOM. And I apologize, I don’t really
have on the line to my knowledge any of our subject matter experts on DICOM.
But I do know within the multimedia they are pieces that they are considering,
all of the different types of multimedia. I’m sorry, Nancy, I didn’t realize
you were on there.

MS. ORVIS: If I could clarify for the question, I think what the gentlemen
is asking about in terms of tele-health issues may or may not, CHI has been
mostly dealing with the content of imaging and audio that needs to be contained
within electronic health records so I think, I’m not clear exactly on all the
other issues he’s dealing with with the RHIOs but our focus has been primarily
on how you capture that and put that within a record, not how you’re just doing
the tele-video or tele-health consultation across.

MR. BLAIR: Let me clarify then, okay, we have emerging health information
exchanges which use all of the standards that CHI has elaborated on so far but
in parallel there’s a growing connectivity across the country now with
tele-medicine and tele-health which tends to deal with stills, videos, and
audio reaching out primarily to rural and under served populations. Well, I
would think that it would be within the domain of the Federal Health
Architecture to say how do we combine tele-health and tele-medicine with health
information exchanges and what are the standards issues there where they might
be incompatible where we have to harmonize those. Because that’s what we’re
starting to look at right now in the Southwest —

MS. ORVIS: — Captain Forbes as the chair, managing partner, what I can say
is that CHI under the scope of dealing with terminologies and content for the
record may not be the group that will deal with all those issues.

MR. KROTMAN: And Nancy, this is Alan, and I think also over the next coming
weeks some of the RFPs that deal with standards harmonization and the NIN(?),
which deals with the RHIO aspects, will be coming out and some of that will
help focus I think on some answers that may answer this question.

MR. BLAIR: Well then maybe this question might be timely because if it
hasn’t come out yet and if the scope that they’re setting forth is the
traditional one and they haven’t broadened it to say how do we include
tele-health then maybe I could put that out as a question to say that we may be
missing an opportunity here to address a harmonization issue that’s getting
larger.

MR. KROTMAN: Understood and I agree with what Nancy said, we’ll take this
back to Captain Forbes and express it to her and see where we can go.

DR. STEINDEL: Alan, Nancy, this is Steve Steindel, and I’m taking off my
NCVHS hat and putting on my CHI hat to respond also. And I think Beth used the
proper words when she was addressing the group about the status and we’re in
the final stages of developing consensus on the multimedia report and I think
one of the main things that’s driving the final consensus that will come out is
the depth of where the DICOM standards are proposed as actual standards versus
conditional standards. And one of the reasons that we’re looking at that is to
a large extent around what Jeff has just raised about the penetration of DICOM
outside the traditional imaging area in large institutions and our ability to
push DICOM out beyond the federal work force while CHI itself is concerned with
federal to federal exchange, we’ve always had the hidden agenda of trying to
use it as a tipping point and the big question now is how far can we push DICOM
with respect to that tipping point and I think that’s what’s going to drive the
final consensus.

MR. REYNOLDS: Simon?

DR. COHN: I actually was going to ask, I wanted to find out a little more
about the disability activity, I guess I’m reflecting that the last time we
heard about that it was unclear even what the questions were much less what the
answers were and I think that that’s sort of how we left it about a year, I
guess it’s been a year and a half ago now. And I’m hearing that you’ve gone
back and started asking potentially more basic questions like well what are we
talking about and beginning to develop use cases. You had referenced use cases
but you never, at least when I was listening I didn’t hear exactly what the use
cases you were talking about were, so maybe you can reflect on that a little
bit, just to help ground us for when we see something coming out in December.

MS. HALLEY: I will try and Dr. Desi, if you’d like to chime in at any point
feel free. I know with the CMS use case what they are doing is they’re taking a
look at the concepts within the MDS and saying what are the concepts that we
have to capture within the MDS and then what vocabulary is supporting them, and
then within them where are the gaps.

Dr. Desi’s group is doing a similar thing with the RCF form which they use
to capture some of the disability and eligibility and benefit information, so
they’ve actually gone to the actual source documents or identifying the
different vocabularies, and then it may end up that there is no harmonization
between these two as Dr. Desi was pointing to, the way that they are
Congressionally mandated to categorize and classify certain disabilities may
never be in line with the way the clinical forms are designed.

So there may be the, they’re looking at two different approaches, either
trying to figure out how, because ICF, the International Classification of
Functioning, is the standard that SSA and some of the other organizations use,
SNOMED is the concepts and the terminology that support the clinical disability
terms, so one concept was do we try to move forward and try to get ICF and
SNOMED to be aligned and closer aligned and can the federal government through
its contracts with SNOMED, can we have some influence on getting that done. Or
are they really so different and will Congress not as Dr. Desi mentioned, for
them to change how they capture and how they classify disability they need to
go to Congress and say we need to change this format.

And that may not happen, so the thought is in going through this exercise is
they may come forward to you and say we’re going to recommend two separate
standards, one that is fitted for the eligibility and benefit needs and one
that’s on the clinical MDS side. Unless there are ways to harmonize those two
needs and then what would happen, say we can get ICF and SNOMED and there have
been attempts to work with SNOMED and say is there a way to prioritize this,
this is used across the federal government, we have this need, they recognize
the need is out there but whether or not it’s prioritized into building new
concepts into SNOMED or for ICF to build the SNOMED concepts or one of the
other, if that can’t happen then they may come forward and say these needs are
so different that we’re going to need to look at two different standards.

DR. COHN: I think that helps but I guess I’d have just a question of
clarification, I actually hadn’t realized that ICF had been implemented in the
United States anywhere, so has Social Security implemented ICF at this point?
Dr. Desi, can you respond?

DR. DESI: No, we have not implemented ICF, we have not implemented any
particular standard, we did find that ICF does a better job of meeting our
needs then does SNOMED and as has been pointed out ICF is a classification
scheme and it has very good hierarchical structure but the SNOMED has the
granularity for describing clinical terminologies and clinical situations. Not
that ICF doesn’t do that either but SNOMED does seem to have some advantage in
that area.

The other thing that is of concern is SNOMED is already set up I believe it
gets revisions or terms added to it about every six months as a regular
process, that’s not the case with ICF. It’s not to say that it’s static but
there hasn’t been a lot of movement with that so far. Now there are some, I
think it’s Denmark I’m not sure, that are looking to map the SNOMED terms of
the ICF, to essentially get to, as one possible solution. I don’t know what the
status is of that process at this time but just that I’ve heard that they’re
attempting to do that.

I think you could see that this, the difficulty is that we use these terms
different ways and I think everyone would prefer that we came up with one
vocabulary so that if we’re communicating information to CMS and you use the
terms clinically or vice versa and we use it for benefits termination that we
don’t have to have something to translate these things in between, they should
be the same, but there are these hurdles to jump over especially with regard to
ICF as to whether or not we could do, the United States do a clinical
modification the same way it’s done with the ICD-9 and the ICD-10, clinical
modification to do that, obviously that’s out of our hands in terms of actually
accomplishing that but it could be a recommendation, you’d have to find out
whether or not that would be possible.

My understanding also to just add a little bit more to this is that looking
way down the road ICD-11 I believe the World Health Organization is looking to
incorporate the ICF into the ICD so that you get in addition to the diagnostic
data they also get disability data along with that so it all gets coded
together. That could also be a good argument for using an ICF structure but
again that’s way down the road but it’s something to keep in mind.

DR. COHN: Thank you very much and certainly mapping or the various other
approaches you’ve described are certainly all reasonable. I guess the other
question I really had was when you were talking about, now that I understand
what your two use cases are the question is are there any other major use cases
that you should be looking at, not to prevent you from ever making a conclusion
but obviously disability is not a concept that’s just limited to Social
Security and CMS and I was just wondering whether the Department of Labor or
the VA or the DOD or other such groups may have at least occasionally come
across this as an issue.

MS. HALLEY: Would you like to join our group because this is exactly what
we’ve been talking about.

DR. COHN: It’s a very important but it’s obviously a complex topic and
trying to figure out exactly what you mean by it is not the easiest thing in
the world.

MS. HALLEY: We actually have made an effort in the last month or so to reach
out both to DOL, we now have a representative from the Department of Labor, and
also the Veterans Benefit Administration has just joined us as well in the last
month and we hope to do exactly that, make sure that the use cases that we’re
identifying really look across the federal landscape and make sure that we’re
identifying all the needs. So yes, thank you, and Marjorie Greenberg who is
also a member of your committee is a very active member of our committee and
unfortunately she’s not here today, but she has brought up similar comments.

MR. REYNOLDS: Stan.

DR. HUFF: Thank you very much for coming to present and I just wanted to
applaud the progress that we’ve seen from earlier presentations and in
particular I wanted to compliment the committee on the evolution of this
process, basically of seeing use cases, then understanding transactions,
specific transactions that would be exchanged, and then adopting vocabulary in
the context of those transactions because I think that’s the only way you can
solve the problem.

If you just talk in general terms what’s good for allergies you can’t solve
the problem, you need to say if we said we were going to send this allergy
message and it had this structure and these fields in it then you can say what
terminology should go in that field in that message and I think that’s the only
way that you can solve a lot of the issues. And some of the early work didn’t
quite have that detail of content and background in it yet and so just, it’s
very clear for instance for the allergy work now that they’ve focused in a way
that they can really come to a good resolution.

And the same way I think much more so also, or the same sort of situation
with the multimedia things, it sounds like we’re a little earlier for the
disabilities part, you’re in the use case definition part, the natural
progression of that would be to define exact messages that you would want, or
even if you don’t get to the message stage if you say this is the kind of
information exchange we want to support and these are the fields of data that
would be communicated in that transaction, then you can resolve issues
specifically about, and if you don’t get to that level of detail then you’re
not going to have a tight binding to the terminologies in a way that makes it
operational and especially interoperable when you start involving DOD and VA
and Social Security and everybody in that same transaction.

So I just wanted to applaud the progress that we’ve seen and compliment you
on the work that’s been done, I think that’s wonderful.

The only other thing would just be a comment that these are the same issues
sort of everybody is struggling with everywhere, within HL7 and DICOM and
everywhere they’re saying oh we’ve got these great message structures, now how
do we bind specific sets of codes to those so that they become interoperable,
and that’s exemplified by what’s called the termental(?) work within HL7 that’s
looking at how, if we use SNOMED in HL7 version three messages exactly how do
we do that, exactly what parts of SNOMED fit into what slots. A lot of that
work is being supported and funded by the National Library of Medicine also.

And so I see it as all very complementary and again I would just compliment
you on the progress that we’ve seen here and in the detail and usefulness of
what’s coming out.

MR. REYNOLDS: I have a question and I’m not as learned as my colleagues on
the whole thing of the terminology and everything but I guess my question is as
you look at CHI which is now, each time they come they tend to end up being
somewhat of a defacto standard, not just in the government but because with CMS
as such a large entity, so I’m going to kind of ask it to those of you who
represent CHI and then maybe to Stan also.

So as this, as CHI continues its work and then you have HL7, and we’ve heard
the word harmonization, and then Stan we have, using you as an example of a
health group that has electronic health records and does those things, how in
the end does it really blend and with EHRs being such a big issue right now, to
where more people are going to be jumping into it, both individual doctor
practices and smaller providers that have maybe been in it before and so on,
how’s it work?

DR. HUFF: I can address that. The first thing is that to say is your concern
is a valid one and what I mean by that is that CHI by its definition is a
consortium of government entities and HL7 and DICOM and the other standards
group are open consensus bodies that include the government as well as
providers, vendors, everybody else. And so there’s the potential that in fact
HL7 following its open consensus process could reach one conclusions and CHI
could reach a different conclusion.

So recognizing that that’s possible in actual fact that’s not happening and
the reason it’s not happening is because the CHI people have been very good at
actually participating in the standards activity. And we need to encourage that
and in fact with all possible encouragement that we can give because what you
really would like, it can be very complementary because HL7 and DICOM and X12
and the others are very good at developing standards but they’re doing it
mostly, if not exclusively, with volunteer efforts. The CHI activity on the
other hand, it may not be everybody’s full day job but they can actually bring
real staff paid resources to work on issues that HL7 might not be able to
address. And so there’s, I’m talking about how I want it to be, not necessarily
how it is —

— [Laughter.] —

DR. HUFF: I think when we talk about the government taking a lead in
standards that’s what we’re hoping for is that some professional resources can
be brought to bear in ways that we probably wouldn’t be able to accomplish, at
least not at the same pace or at the same quality as might be accomplished by
people who are doing it as a real, but what it means is that there is a real
danger there and so if the CHI people don’t come to HL7, don’t come to DICOM,
don’t go to X12 there could be a schism and you could see CHI standards that
are not completely aligned with the other standards bodies and so we hope that
that continues and increases.

And then as a private group representing my hat now as IHC what we’re
looking for is we’re going to do what we’re going to do internally, when we
start talking to public health institutions, we talk to Social Security, we
talk to CMS, and we have specific transactions that we’re going to exchange,
then we’re going to adhere to what CHI and what HL7 and what other people do.
We’re going to do whatever we do internally and we’re going to look at what’s
happening and it may be that what we’re doing to adopt terminologies and
standards internally based on what we see happening in the community but
ultimately what we’re committing to is that when we might make our internal
decisions but when we communicate information outside of our enterprise we’re
going to adhere to the standards that are specified by HL7 and by CHI and the
other open standards organizations.

MR. REYNOLDS: Because one of our key things that we’ve always talked about
is adoption, so for the large institutions like yourself that’s one thing but
as we talk about EHRs and everything all the way down to the small doctor
offices their ability to buy is once, their ability to communicate with many
people is limited in different ways, so that’s kind of what I’m, since I don’t
understand a lot of what you’re talking about I’ll take that stance, I’ll go to
that and be an expert, but I think that’s the kind of thing. Jeff?

MR. BLAIR: Harry, you said that you referred to the CHI standards as defacto
and I know that I really felt as if from an NCVHS standpoint that they would be
and I think at least in my thinking I felt as if when Tommy Thompson made the
press release, I guess it was either April or May of 2004 and announced all of
the CHI standards, it was my hope that the industry would say the federal
government is setting an example and setting the direction.

I’m very concerned because I don’t think that the industry has reacted that
way, I’ve been in a couple of vendor conferences and in those conferences,
these were specifically designed to speak to vendors of electronic health
record systems, less then ten percent of the vendors knew what CHI was. I was
very disappointed, and of those who did know what CHI was they felt as if it
was only directed to federal government agencies, not for the industry as a
whole.

And I’m mentioning this because I am concerned and disappointed, and if this
is the case the intent that we wanted to achieve with CHI as part of the FHA I
think we may have to do something else that is bold and dramatic to get the
attention of the private sector, all these vendors, that these CHI standards
are what they are, they may be identified as the standards that the different
federal government agencies have agreed to adopt but they’re intended to be
setting the direction for the industry as a whole. And that last message
apparently has not gotten through to the industry —

MS. ORVIS: Sir, could I make a suggestion?

MR. BLAIR: Yeah.

MS. ORVIS: This is Nancy Orvis, I’m with the CHI membership and have worked
on these standards for a couple years and with DOD Military Health Systems,
just I think it’s taking, it will take a couple years to percolate through
because the main issue for commercial electronic health vendors is terminology
is imbedded often with when you buy an application you buy reference
terminologies with the application vendor. Now DOD as a health care provider
has put those reference terminologies in contract languages, so new things that
DOD Military Health System will buy have references to those but it takes a
while.

Now I think one should wait and see what happens here in this next fiscal
year because requirements have to be written, they have to be put into RFPs and
put on the street and I think a lot of the vendors are waiting to see how do
you incorporate this, this is in some cases terminology is kind of like rocket
science for some of these vendors, it gets into the very deep set of concepts
where they’re not always comfortable talking I think. But I do believe that
there are now some, there will be some small test cases and things that might
be coming up here in the next annual conferences here in the fall and winter
and spring where some applications or some vendors and some of us in the
government have been doing some testing to see how these work.

I think the benefit that you’re looking for is that as reference
terminologies get imbedded or linked to these application vendors you will be
able to see something like a pharmacy vendor or an ancillary vendor or an E HR
vendor say how do I work with a decision support application, and what will be
very important is when you put fleets of products together and you see that
because the reference terminology is common, say a pharmacy that lists patient
medications can interact with a decision support application for the physician
that advises them on the best protocols or something, they will communicate
through the ability of understanding the reference terminology.

So that may be kind of a lengthy explanation but I think, I have been
pleased to see how, we in DOD have a blanket policy that we want to use
external standards as much as possible, we use that in our acquisition
capabilities, but it does take more then a year to percolate through because
you have to be able to put that in that process and I think that we have this
in various agencies now where the requirements to look at products that can
utilize these is now out there and I think we’re going to see some more
maturation of this in the next year or so.

MR. BLAIR: Nancy, what you say is true and I do understand that, and not
only is DOD doing that but CMS has also identified that in the docket program
SNOMED, LOINC and RxNorm will be the standards required there. But the
observation that I was making was that if that’s the only way that we’re going
to get the industry to transform itself, the length of time that it will take I
think is longer then many of us feel we can afford. I think that we need to get
the attention of the vendors, that this is something that they have to begin to
learn about and begin to design it into their next product cycle, because I
don’t think we can wind up waiting another year before we start to introduce
them to the fact that it’s going to be required by docket or by DOD or the
e-prescribing pilot tests are done and that RxNorm might be part of that. All
of that I think is appropriate, I guess I’m just expressing my feeling that I
think that, I think we’ve got to raise the visibility of the role that CHI
standards are going to play so that the private sector vendors can begin the
work now to get ready. It takes them quite a while to develop systems that
implement these standards.

MR. REYNOLDS: Steve and then Simon.

DR. STEINDEL: I’m putting on my CHI hat and I have a couple of responses and
comments. One was to Stan’s comments and I really appreciate Stan’s observation
about the number of CHI people, etc., who are involved in the standard
development organizations and trying to harmonize from that point of view and I
can assure Stan that that is not accidental, it’s a deliberate plan.

But I would like to also point out something that Beth alluded to in her
presentation here is CHI also envisions a very important role in NCVHS in
bringing in the private sector influence on the evolution of CHI standards with
the policy that we’re going to be adhering to in phase two that was used in
phase one is preliminary discussions about where we’re going and what type of
ideas we’re doing and then final discussions. And having been involved on both
sides of many NCVHS/CHI discussions in phase one I can assure NCVHS that those
discussions did influence the standards and I am sure they will influence the
standards in the future.

So I don’t want this group to be unaware of their critical role in moving
these standards forward in a fashion that can be utilized by the private sector
even though they are meant to be for the federal sector.

And in the other respect with regard to what Jeff was saying about the
visibility of CHI while I probably do agree with him in the sense of the number
of EHR vendors that might not be aware or are implementing CHI standards,
probably in terms of the number of EHR vendors that in terms of their
installations and how many are being used I would say that a large proportion
of them are influenced by CHI, are influenced by them and are building them
into their product systems.

However, as Jeff also pointed out, the cycle time for that, and the cycle
time for terminology use in general since we basically do not use standardized
terminologies today in most systems, is going to be long. And I don’t think
we’re going to see it in the next year or two, it’s going to be five to ten
years before we actually do see it in place. And I think an important role that
the Office of the National Coordinator has seen in this area is to build the
CHI standards into their RFP process and also roll those CHI standards into
NIST and making them federal standards so that when not just DOD when it goes
out and tries to procure something it will point to CHI standards but
throughout the federal procurement process we will have NIST standards that we
can point to and say okay if you want to meet our requirements you’ve got to
adhere to these standards.

So we are making a lot of efforts to make this more visible, I don’t think
we’re going to achieve Jeff’s rapid timeframe but I think we’re going to be
moving as expeditiously as possible.

DR. DESI: Could I ask a question? Has there been any move to include the
private sector as part of this process? The reason I ask is when we started up
with CHI II in the disability workgroup we were essentially told that we were
not to include the private sector, to find out what they were doing or if
they’ve had any approach to this. And I was wondering if we’re interested in
this getting adopted by the private sector but we’re not including them in the
process, is that a problem.

DR. STEINDEL: Dr. Desi, this is Steve Steindel again, we brought that up in
CHI Phase I, it was looked at, the Office of General Counsel told us that
because of the construct of how we were working we could not work directly with
the private sector and the only way we could expose the CHI process to the
private sector was through a FACA group like NCVHS. We actually did reopen that
question and asking for more definitive opinion from the Office of General
Counsel with respect to the CHI, not the CHI but the FHA Public Health
Surveillance Workgroup, because the private sector is key to public health
surveillance, most of it is done by our state and local partners who are not
part of the CHI process. And actually the Office of General Counsel searched
for about a month to try to figure out if we could any way shape or form bring
them in and it turns out that we don’t have legislation that’s broad enough to
allow them to be part of the internal process and that’s an unfortunate thing
that we all are very upset about.

DR. DESI: I can understand that. Is there any legislative affairs liaison to
maybe entice Congress to address that issue since obviously the President is
very interested in moving this along as rapidly as possible?

DR. STEINDEL: I think that would be something you’d have to bring up with
the Office of the National Coordinator.

MR. BLAIR: And that was essentially the message I had too because all of the
things that Steve said, I agree with every single one of the points, and it’s
very hard to get this complex multifaceted industry and the vendors in it to
move quickly, for a lot of good reasons. And maybe what I was expressing was
that when NCVHS was looking at these standards we had the private sector
testifying and we felt that we were reflecting the consensus of the private
sector as well as the federal government.

And then when Tommy Thompson announced it publicly we felt that we had the
visibility, so all I was really echoing was a surprise that the vendors that
are not directly involved at HL7 and SNOMED, all of those vendors out there to
my surprise were not aware of a lot of these standards efforts or Tommy
Thompson’s announcement on CHI and so I thought it’s important that you be
aware of that, it came as a surprise to me, and I think that maybe David
Brailer needs to be aware of the fact that even though we’re doing all of this
good work, NCVHS and CHI and HL7 and SNOMED and all and we’re doing all of this
good work, that a large part of the industry isn’t aware of what we’re doing
and the direction we’re going.

MR. REYNOLDS: Simon? And then we’ll take a break.

DR. COHN: Maybe I should try to make a comment about all of this. First of
all I want to compliment the work of the CHI and I think really what I was
going to comment on was really to thank you for beginning to work on
implementation guides and I think by way of commenting also on what Jeff was
commenting on, I don’t want to overstate or even fully agree with some of
Jeff’s comment because I think I would observe that many of the CHI standards,
HL7, many of the other standards that were identified by CHI are obviously
already generally implemented by the industry.

Now what is not implemented at this point is connecting terminologies to the
standards which is I think really what Jeff was referencing and I will tell you
that even as we looked at them last year we realized that many of the
recommendations, and I think this is where Stan was coming to also, is that
it’s great to say use SNOMED or use another terminology but until you have
implementation guides, and I actually was reflecting on John Halamka’s comment
this morning where he was saying geez, not only do we have these concepts but
we actually have implementation guides that we’re going to make available to
people so they’ll actually really understand how to implement these things down
to the specifics.

And until we get to the point where there actually are implementation guides
that we can point to that show that the answer is not SNOMED but use these
parts of SNOMED in these fields in HL7 version 2.X or version 3.X for these
specific purposes we don’t have interoperability and we really don’t have
really implementable standards.

And so I think that really the point that we saw a year and a half ago was
clearly there were open issues, things like disability and all of that, but we
were all really looking forward to the next step of CHI being really coming out
with implementation guides that then the industry would really know what to do
with it. So I think we just need to realize the industry I think is making
progress, we’re obviously Dr. Desi here to, we are not the same as having
something on your workgroup but if you have issues we’re obviously happy to
have a session where we bring and more fully discuss issues of disability or
otherwise, sounds like December that will be happening, and we’re sorry that we
didn’t know that you needed it before or else we would have been happy to have
stepped forward to have of some assistance to you and your workgroup. But
obviously at the end of the day we still are going to need those implementation
guides so that people really know what to do with things.

Anyway, that’s my comment and thank you again for starting that work on the
implementation guides.

MR. REYNOLDS: And to play off of that, as you want to come forward, if there
are others that you think should be part of that same discussion, in other
words whether it be HL7, whether it be anybody else, as part of the subject, so
to hear from you but we could also use your help as you want to get more
visible and as we want to do this differently if there are others that would be
good to hear from at the same time that would be helpful at least in building
the plan on what we think about.

We thank you very much, nice job, thanks for all of you being on the phone,
and we’ll take a 15 minute break.

[Brief break.]

MR. REYNOLDS: Okay, we’re back started again and our next one is Maria is
going to talk to us about the e-prescribing pilots —

Agenda Item: Update on Key Issues: E-Prescribing Pilot
– Ms. Friedman

MS. FRIEDMAN: Before I start I’d like to introduce Drew Morgan, Drew is new
to CMS, he’s been in our office and on my team for six weeks now, he comes to
us from NAMSI and we’re very glad to have him. One of the reasons I’m
especially glad to have him is that they made the team leader for not only
e-prescribing but HIPAA, so I needed help and we have Drew so I just wanted to
introduce him to the group.

What I’m here to talk about today is the e-prescribing pilot RFA that just
came out —

MR. BLAIR: By the way I think we need to congratulate you for that
achievement.

MS. FRIEDMAN: Well thank you, we’d hoped it would have been out sooner is
all I can say, but having said that, and I’m going to go through just a little
bit of background which I don’t think I need to do too much of seeing the group
out here.

But anyway, the MMA, and I went ahead of my slides here, MMA requires that
we conduct an e-prescribing pilot during the calendar year 2006 for standards
for which there is not adequate industry experience. And those of you who are
regulars here to the subcommittee know that we’ve spent a lot of time looking
at e-prescribing and talking about foundation standards and other standards
that might be tested and in February CMS issues an NPRM talking about what we
might propose as foundation standards based almost I would say to a large
extent what came out of this subcommittee and hearings and all were very, very
helpful to us. And we’re in the process of putting out a final rule and I’m
saying that now that because of the timing on this we could not say in the
pilot RFA what were going to be foundation standards or not just because of the
legality of the fact that the final rule was not out, so I just wanted to make
sure everybody understands that.

The other thing that MMA requires is that the pilot project have to be
evaluated and because of the timing, the pilots run calendar 2006 and there’s a
report to Congress due April 2007, in order for that report to Congress be
written the pilots need to be evaluated and the only way we could see doing
that is to actually run the evaluation concurrent with the pilots. Normally you
do it step wise but we don’t have the luxury this time of doing that. The
contractor for the evaluation has not been named yet.

As many of you have seen we have an RFA out on the street, that’s just a
term of art, it’s a request for applications because the mechanism, the funding
mechanism is going to be cooperative agreements. We’re going to make the awards
competitively which means that people are going to have to submit proposals and
we’re going to talk a little bit about that process in a little bit about
what’s going to be required and how it’s all going to work together.

Interestingly we’re partnering with our friends at the Agency for Healthcare
Research and Quality, AHRQ, to get these applications in and get the awards
made, in fact the RFA was put out by AHRQ in collaboration with us. And they
will be convening the review panel for it as well for the applications that we
get.

The RFA was just announced on the 15th, like last Thursday, and
I’ve included the website and I’m going to read it in case anybody is listening
and doesn’t have it, I apologize. If you click on this link it will take you
right into the application itself and that’s
grants.nih.gov/grants/guide/rfa-files/rfa-hs-06-001.html. As I said the
proposals will be evaluated by a peer review group. We have a total of $6
million dollars available, we envision a max of $2 million, so you can do the
math. A lot of how the money is going to be divvied up and who gets what
depends on the number of applications we get, who applies and kind of how the
results are configured.

We envision that we will get applications from some of the big
implementations that are already in progress, they may have to make some tweaks
to be able to test everything that we’re going to ask them to test. But we’re
also interested in applications including if not exclusively from entities of
interest like long term care facilities, long term care pharmacies, and folks
like that, and that’s listed in the RFA as well.

There are key dates, we’re going to have a bidder’s conference on the
29th and you have to apply to get on the list to get the information
of the bidder’s conference and I’m going to get to that in a moment but I’d
like to complement Tony Sheath(?), who’s here, he was absolutely the first
person who signed up, he gets the award. There’s going to be letters of intent
due October 7th, applications are due October 25th, and
we hope to get the peer review in November although it says in the RFA
December, and the awards will be made in December, because according to the
statute the pilot projects have to begin January 1st.

Bidder’s conference. One of the things we really are interested in is
getting questions from potential bidders up front so we can answer as many
questions as possible and make the conference more productive and efficient.
It’s open to any individuals or organizations intending to apply, and AHRQ set
up a special email address for you to sign up and that is
eprescribingrfa@ahrq.gov, and you
need to register by the 28th since the bidder’s conference is on the
29th. So again submit your questions in advance and that will be
very helpful to us. The call will be at 1:00 eastern and we expect it will run
for a couple of hours or more.

The RFA is very specific about what needs to be tested and one of the things
that’s important to know is that everything that’s on the list has to be tested
together, there’s no mix and match on this, and again its been very difficult
to talk about this since we don’t have the reg out and I can’t tell you what
foundation standards are final and what aren’t.

So here’s the list as in the RFA, test the formulary and benefit
information, the NCPDP is working, actually has ratified the formulary benefit
protocol that RxHub donated to them. Medication history, same thing, NCPDP
Script fill status notification, we’re looking at the business value and
clinical utility of this function, it’s out there but nobody uses it much.
NCPDP Script cancellation and change function, same thing. Structured and
codified sig, this is something new, this is something that the industry is
actually busted its hump to pull together and it should be ready for prime time
at least on a pilot basis.

And then there’s the clinical drug terminology pilot should determine
whether the RxNorm terminology translates to NDC, and also works well with some
of the other reference based vendors who are out there as well. Prior auth
messages is on the list, NCPDP standard version, Script standard version five,
telecom standard version five and the 270/271 version 4010, round out the list.
And again if you’ve been a regular at the hearings we held over the past year
and kept up with our letters and stuff this is all stuff that was discussed at
length and was in our recommendations.

Basically one of the reasons that we’ve put everything together in this and
we them all tested is we want to make sure that they all work together with all
of the standards that have been proposed, as well as some of the new ones like
the codified sig.

Again this is in the RFP, one of the things we want to test is are the right
data being sent, are the data usable and accurate, are they well understood at
all points in the transaction, did they work, is the right stuff being sent to
the right place the right way and do they all work together. Data accuracy is
very important and because some of these things are new it’s important to know
whether these new functions actually work and they work with what’s being used
in the industry today as well as some of these other functions that aren’t used
very much at all.

The other question that we want to know is if things don’t work well
together were there work arounds, what were they, how did those work, how can
they be improved to address work arounds, how long does it take to turn the
transactions around, and does it work for what you need it to work for, can you
order what you need to order.

Again more on the project characteristics, the methods of testing, and this
is a point I’m going to make at the end but I want to make this now, these
project characteristics are very important and some of the other things that
are in the RFP are very important and the reason for that is that the
applications are going to be undergoing the regular scientific review process
and you want to make sure that your proposal, if you’re submitting one,
addresses all these points. There are evaluation criteria as well included in
the RFA but again we’re going to be looking at whether you addressed everything
we ask you to address and these project characteristics are important. And
another thing that’s important is budget, is the budget going to be reasonable
and all of that but I’ll get to that.

I’m just going to run down the project characteristics, methods of testing
and why they were chosen, and normally those are handled in applications and
there’s some kind of narrative that kind of talks about, that tees it up and
then there’s specifics on what you’re going to do and how you’re going to do
it. The nature of the prescriber pool including specialty, size of practice,
percent of participation. Number of patients, demographic characteristics,
uptake, enrollment, dis-enrollment, that kind of thing, these are the kinds of
things again that we’ve discussed as issues and that are important for
determining what standards coming out of the pilots will be proposed for
adoption in 2008 and of course there are metrics to consider how robust these
things are, how they work well, again uptake, the use for specific patient
populations and that kind of thing is going to be very important and very
telling.

Some break and butter things, where are you going to test it, how many
sites, who’s participating, what’s it look like, baseline numbers of
prescriptions per month and you have to have something to measure against so
it’s important to kind of know up front or at least guestimate up front kind of
what the baseline for the prescriptions are going to be. Again the same thing
with the calls backs to pharmacy because what you really want to do, one of the
measures of success will be to show how its reduced call back time and
basically if you will improve the ROI. And the other thing is that any other
additional metrics that people can provide has to how you might measure
success, ROI, these are not the only ones but these must be addressed.

Outcomes reported, again this goes to measurement of how you define success
and how you’re going to look at things coming out of the pilots, just a few,
and I’m not going to run down the list of the number of medication errors and
the number of adverse drug events that you found or were reduced. Rates of
hospitalizations and emergency visits associated with adverse drug events, I
mean that’s another way of looking at costs and benefits, especially with
elderly populations. Work flow changes are important, renewal rates, I mean all
of these are there, these are definitely measures and anybody has any other
ideas they want to throw in we’d like to hear them in the applications as well.

We’re hopeful to get multiple sites, geographic diversity, we hope to get
applications from public/private partnerships. And again, we are interested in
Medicare, in pilots that have fairly large Medicare base, I think it’s at 25
percent. We’re interested in provider types, again I know it’s going to be
difficult because of the quick turn around time for getting these applications
together so these are things to consider.

We would especially be very appreciative of applications that would test
the, or use the structured product label and employ that too. So those
applications that have that in it will be looked upon favorably as well.

I know we’re going to have our own evaluation contractor but because of the
timeframes it would be very helpful to have the applicants tell us how they
think their particular pilot should be evaluated. Obviously the pilot sites and
the evaluator are going to have to work hand in hand so it’s kind of nice to
know up front what capabilities and what you think is important because we’re
going to have to figure that out pretty much very quickly. And of course
everybody has to comply with the HIPAA privacy and security requirements.

Again attention to detail in the RFA is very important, you need to explain
who you’re partnering with, what the relationships are, who’s bringing what to
the table, and that not only needs to be reflected in the narrative but the
budget as well. And there’s a wide range of entities who can apply, eligible
institutions, there are a lot of them, for profits, non-profits, public or
private institutions such as universities, state and local governments, federal
agencies, faith or community based organizations, and then of course the MMA
was very specific about who we should consult with but also entering into
cooperative agreements with physicians, physician groups, pharmacies,
hospitals, PDP sponsors, MA organizations and other appropriate entities. So
there’s a wide range of people who can and should be involved in this pilot
projects. Again we’re looking for long term facilities and rural health clinics
as well if we can get them.

And this is my take away for today, I’ve said it before, I’ve said it again,
attention to detail is important, pay attention to all of the characteristics
set forth in the RFA and make sure that you address what we’ve asked you to
address. The budget is a very critical piece and that needs to be done well and
it needs to be reasonable. You know what the pot of money is so don’t come
through with an application that asks for $7 million dollars, it ain’t going to
happen. The deadlines must be met.

Get help with your proposal, I know that a lot of folks who are not, who are
going to apply or who are considering applying have never really done this
before, this is kind of standard operating procedure in the academic world
where people apply for grants all the time and there are people who know how to
do this. I’m not suggesting you need to partner with academic institutions but
there are people out there who are professional grant writers and who’ve been
very successful in getting their grants through the application process, so to
the extent that you think you need help do seek it out because even if you have
the best idea in the world and it’s well thought out if your application
doesn’t pass muster it’s not going to get funded and I can’t say that strongly
enough.

So thus concludes my rant on the application process and again all of this
is on the website, it’s in the RFA, and we’ll be going over questions at the
bidder’s conference on the 29th.

MR. REYNOLDS: Thanks, Maria. Jeff, you had a question?

MR. BLAIR: About halfway through your presentation I was hitting my co-chair
on the shoulder saying to put me in line with the queue but by the time you
finished your presentation you had answered every question that I had
anticipated so let me just simply say well done, Maria.

MR. REYNOLDS: I have a comment. We had written the letter of recommendation
from the committee we had recommended that after the pilot that the results be
reviewed before it becomes a rule, I don’t remember the exact words we used, I
didn’t see anything, that’s the process and what you want them to do but how do
you see it working after that?

MS. FRIEDMAN: Well, two things are going to happen, one is we’re going to
have the report to Congress and then we will have a subsequent rulemaking round
to adopt standards that make it through the pilot process, the ones that work
and they’re interoperable with other stuff. So these pilots are very important
because the results really feed into the next round and what will be adopted in
2008.

MR. REYNOLDS: Because your slides, you paraphrased a lot of cost benefit but
the actual words never said it.

MS. FRIEDMAN: That’s true, that’s a true statement, but to the extent that
people can quantify things, and we tried to lead you down the path, to the
extent that you can quantify as much as you can quantify both in terms of costs
and benefits, especially measuring some of this stuff has been very difficult
to measure. And we’ve discussed that here, I mean how do you measure an adverse
drug event, or how do you measure one that’s averted, and so some thought needs
to be put into that, we tried to give you some ideas for example but still it’s
very hard work and I realize time is short.

MR. REYNOLDS: Okay, any other questions or comments? Stan?

DR. HUFF: Just a statement of the obvious which is this is a very tight
timeframe, I mean if you award those in December I mean, then I would assume
that there would be some implementation that had to go on, the actual
programming the stuff to support this, which means data collection might not
start, the actual exchange of data until June or something and then you’re
expecting to do the evaluation and report out by —

MS. FRIEDMAN: That’s why it’s got to be concurrent, we have no luxury of
time, I mean to be very honest we had hoped to get this RFA out a whole lot
earlier. It’s tight.

DR. HUFF: I think it will be difficult for people to, even with their best
intentions, to be able to do all of the programming, install and implement this
in the timeframe that’s being asked for.

MR. REYNOLDS: Okay, anything else? Okay, Maria, thank you very much.

MS. FRIEDMAN: Thank you and we look forward to the applications.

MR. REYNOLDS: All right, next on the agenda is a Katrina update by Steve
Steindel. Maybe he’s working for FEMA now —

Agenda Item: Katrina Update – Dr. Steindel

DR. STEINDEL: Thank you, Harry. I am going to do a very brief update on what
has been going on primarily within HHS and primarily coordinated by the Office
of the National Coordinator on some responses to getting electronic medical
information to providers and patients who were dispersed by Hurricane Katrina.
I’m giving this report based on information that I’ve gotten second or third
hand primarily because everybody who’s involved with this process is very
involved with this process and there are a few people in this room I believe
who have been peripherally involved with it who probably know more then I do
and if they want to contribute I would love it.

But the whole intent is to make NCVHS aware of what’s been going on because
it fits in very well with a lot of what we have discussed here through the
years. And the intent of making you aware of it is to perhaps look at a quarter
day or so, sometime after the first of the year after the dust has settled to
find out the details of the people who actually did the work. So if I misspeak
for any of these people and if any of them hear about it I’d like the
transcripts and everything to reflect my apologies, I am trying to present it
as best as I know how and I’ve gotten some good information but it’s a very
rapidly evolving area.

As background, soon after Katrina hit New Orleans there were federal workers
who started to go into the area, maybe not on a massive basis but on a basis,
evolving what was going on and looking at the response. Several of those were
from HHS, primarily from CDC, which of course has public health responsibility
and lead in this area. And I do know on I believe it was the Friday after
Katrina hit there was a high level CDC group, including Secretary Leavitt and
Dr. Gerberding, who went into the area and visited several sites to see what
was going on and what was needed. And even before that and definitely after
that there was a movement of CDC workers into the area, and an email I just got
a minute or two ago we are now down to 161 people based on the Gulf Coast
region and I say down to because it peaked at about 200 —

MR. BLAIR: We being CDC?

DR. STEINDEL: CDC, these are CDC workers. They are supported right now by a
staff dedicated to their support of 352 workers within CDC in Atlanta. So there
is a massive public health, federal public health response to this.

One of the things that CDC did observe during its visits, the early visits
to the Gulf Coast area, was that there was a tremendous need to meet the
ongoing medical needs of the evacuees and also that a lot of this information
actually did exist in electronic format, not necessarily as electronic health
records but in particular medication histories, prescription information. It
was dispersed, it was in multiple people’s databases, it was not readily
accessible, but it was there, and there was a need to get this information into
the people’s hands as quickly as possible, both the physicians and the
patients, so they could renew their medications, particularly those who have
chronic diseases, who need their various medications refilled, or may have left
without enough medication.

So this was identified very, very quickly, I don’t know how many other
groups within the federal government or outside communicated this to Dr.
Brailer but I do know that John Linsk(?) from CDC was instructed by Dr.
Gerberding on Saturday to call Dr. Brailer and suggest that he start looking at
some way to coordinate this information.

That’s what I know as background on this. I do know what happened after
that.

On August 28th, Sunday, David Brailer formed an internal team
within HHS and the federal government involving DOD, VA, etc., and then
reaching out into the private sector and I don’t know what the peak was but
there’s a tremendous number of federal and private sector people involved with
this, with the charge of coordinating prescription information within the areas
affected by Katrina and getting this information to the evacuees and the
physicians that were seeing them at that time.

MR. BLAIR: Steve, you may want to point out where you referenced on August
28th, that is two days before the Hurricane struck New Orleans.

DR. STEINDEL: Sunday the 28th, August 28th —

MR. BLAIR: August 28th, that would be a day before it struck.

DR. STEINDEL: I believe this was the Sunday after that the meeting took
place.

But this started, this started very quickly, and the net effect of it was
soon after, and we heard this a little bit in Teri Byrne’s presentation
earlier, the ability to exchange medication information from the private sector
groups was starting to come online, particularly, and RxHub was involved with
this, five chain pharmacies, Albertsons, CVS, Rite Aid, Walgreen’s, and
Wal-Mart, were exchanging data by Tuesday the 13th of September and
probably before that, others were coming online soon after. The VA facilities
were going to be coming online, I’m not sure they’re online, my understanding
is they are still working with the Medicaid information but they expect that to
be online also.

And if there’s anyone who can actually correct what I’ve just said it would
be appreciated but that’s the basic idea. Teri?

MS. BYRNE: Actually Steve I did get involved in this actually Monday, Labor
Day, and have been pretty much living and breathing it since then. The
Medicaid, the Mississippi Medicaid data was live originally with gold standard
because they already had the data, and then they moved the pharmacy data in,
those chains you mentioned, and that became live as you said last Tuesday. The
VA data is not live yet but my understanding is the Louisiana Medicaid data I
believe went live today. RxHub went live yesterday. So what we did was we
pulled in the pharmacy data and married it with the Medicaid data in the gold
standard database and then we created a real time connection to RxHub from gold
standard because we weren’t yet working with them, we weren’t implemented with
them yet, to feed them the PBM data. So we didn’t take the PBM data and load it
into their database which has been reported so I wanted to clarify that, many
times and is not true, we actually have a live connection with them. So we are
feeding them real time data and like I said Louisiana Medicaid went live
yesterday.

DR. STEINDEL: And thank you, Teri, basically this is very good because all
that I wanted to do with today’s very quick briefing was just point out what is
happening. And I think we can realize a lot of what is happening is the types
of things, while we would like it to happen in a much more seamless and
coordinated fashion we were able to do a lot of it through much, much struggle
as Teri pointed out. I can assure you she is not the only person who was living
and breathing this for the last several weeks, everybody I’ve spoken to has
been involved with this process, has been living with one or two cell phones
glued to their ear for this period of time while reading a Blackberry.

So it’s been a very intense period of time, I think they have made
tremendous progress, I think it is a wonderful example of how electronic health
information can help especially in the future when it comes together in a
seamless fashion. And I would like NCVHS to explore what has happened with this
with time and detail from the experts.

As another matter associated with this and somewhat more a little bit
aligned with CDC’s particular interests, a similar effort has been going on
with immunization records. As you probably know the states in the region, most
of the states in the region do run immunization registries, one of the problems
that CDC has been having with immunization registries is that there have been
state barriers to exchanging state immunization information with other states.
I can assure you these barriers went down, not totally, but on a temporary
basis is my understanding between some of these states because we now had
evacuees from Louisiana in Texas who now needed immunization records that were
in the Louisiana immunization registries and so the exchanges started to take
place using the standard HL7 messaging.

So this has been another, from our point of view of a health IT and an
information exchange point of view, another positive example of what happened
during the Katrina incidences, and I think it would be very useful for us to
find out in depth what happened.

MR. REYNOLDS: We have added to that our charge, call it special areas of
interest, Katrina aftermath.

DR. STEINDEL: And that is my report as shaky as it is and as third or fourth
hand as it is, Harry.

MS. BYRNE: One other thing of interest I think Steve is that Dr. Brailer has
asked the Markle Foundation to organize a lessons learned meeting within the
next several weeks so I think that will be really important information out of
that meeting.

MR. REYNOLDS: Any other questions or comments? Any other agenda items for
today? I’d like to then thank Janine and Marietta and Maria for setting the
meeting up today, getting everybody out here and especially the presenters and
we thank them for getting out here. And Judy, thanks for handling matching
records and you set a high bar for Stan tomorrow, let’s hope he does as well
with this portion of the program.

And we plan to start tomorrow at 8:30 and adjourn at 11:15. Everybody have a
nice evening.

[Whereupon at 3:55 p.m. the meeting was adjourned.]