American Health Information Community

Personalized Healthcare Workgroup Meeting #2

Wednesday, February 21, 2007

**Disclaimer**

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

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

Sorry for the delay. We\'re ready to go, Judy.

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

Thank you very much. And welcome, everybody, to the second meeting of
the Personalized Healthcare Workgroup. Just a reminder that we operate
under the auspices of the FACA. This meeting is being Webcast, the
public will be invited to make comments at the meeting. Workgroup
members, just to remind you to speak clearly and distinctly and to
identify yourselves before you speak so the transcribers will know to
whom to attribute your remarks. Also when you\'re not speaking, if you
could mute your telephone to help reduce the static.

I\'ll begin here by going around the table and introducing the members
at the table here at ONC, and then Jennifer, you can introduce the
people on the telephone. I\'ll begin on my right.

**[\>\> Carolyn Clancy:]{.underline}**

Carolyn Clancy, AHRQ.

**[\>\> Paul Cusenza:]{.underline}**

Paul Cusenza, 23andME.

**[\>\> Allan Guttmacher:]{.underline}**

Allan Guttmacher, National Human Genome Research Institute.

**[\>\> Greg Downing:]{.underline}**

Greg Downing, Office of the Secretary.

**[\>\> Kristin Brenner:]{.underline}**

Kristin Brenner, Office of the Secretary.

**[\>\> Erin Castigli:]{.underline}**

Erin Castigli (ph), Office of the Surgeon General.

**[\>\> Dina Paltoo:]{.underline}**

Dina Paltoo, Office of the Secretary.

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

And Jennifer, could you introduce those on the telephone, please.

**[\>\> Jennifer Macellaro:]{.underline}**

On the phone today we have Beryl Crossley from Quest Diagnostics.
Douglas Henley, American Academy of Family Physicians. Michelle Puryear
from FirstHealth. Steve Matteson from Pfizer. Kevin Hughes from Partners
Health Services. Amy McGuire from Baylor College of Medicine. Marc
Williams from Intermountain Health Care. Campbell Gardett from the
Department of Health and Human Services. Jean Slutsky from AHRQ. Betsy
Humphreys from the National Library of Medicine. Mark Rothstein from the
University of Louisville. Kathy Hudson from Johns Hopkins University.
John Glaser from Partners Health Care. Janet Warrington from Affymerix.
Deven McGraw from the National Partnership for Women and Families. John
Halamka from HITSP. Steve Teutsch from Merck. And Lisa Rovin from the
FDA. Did I miss anyone?

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

Thank you, and I\'ll turn it over now to the co-chairs.

**[\>\> Doug Henley:]{.underline}**

Thank you, Judy. This is Doug Henley. I too want to welcome everyone to
the call today, both the members of the Workgroup as well as members of
the public. I would reiterate Judy\'s earlier direction that if you\'re
on a cell phone try to mute as much as you can, to avoid background
information. And I remind everyone that we did receive the agenda and
attachments both yesterday, and I think we received a few documents last
week, as well.

As we\'ve set up the meeting today by telephone conference call, per our
discussions last time, we wanted to hear a bit more from our
conversations last time about the HIT Standards Panel process and how
that relates to our work in going forward. And then we\'ve had,
obviously, on our two previous calls we\'ve had a lot of discussion,
appropriately so, about the importance of family history in this context
of personalized healthcare, and its role in that regard looking to the
future both in terms of history-taking as well as how that information
gets transmitted electronically and captured electronically. So we\'ll
hear a bit about that.

And then we\'ll obviously get into some information from John Loonsk or
others at the Office of the National Coordinator about use case
development and how we proceed in that regard. And then we\'ll finally
talk about our next meeting on March the 12th, and some thoughts about
the visioning and work plan development process at that time.

John Glaser, before we get into the agenda, any additional comments that
you have?

**[\>\> John Glaser:]{.underline}**

No, Doug, you\'re doing just fine, can\'t add anything to that.

**[\>\> Doug Henley:]{.underline}**

All right, thanks very much. The first item of business is to draw your
attention to the minutes of our last meeting on January the 4th, 2007,
those were sent to you in advance, and I first wanted to ask members of
the Workgroup if there were any corrections or edits that you would like
to suggest to the staff.

Hearing none, are there any objections to adopting these minutes as,
draft minutes as proposed?

**[\>\> Carolyn Clancy:]{.underline}**

No.

**[\>\> Doug Henley:]{.underline}**

All right, hearing no objection, they will be adopted, and will become
part of our official record.

Now, I recall as our first item of business we have had previous
conversations about the importance of how we go about determining the
standards that relate to our charge, and how that standards development
process works in terms of development and approval and implementation.
So we\'ve asked John Halamka from Harvard, who is chair of the HIT
Standards Panel, to be with us today. I think you have a PowerPoint
slide deck from John, so we want to welcome him today. John is doing a
tremendous job as chair of the HIT Standards Panel. John, thanks for
being here, and we look forward to your presentation.

**[\>\> John Halamka:]{.underline}**

Very good. I\'m very happy to be here. Just so I follow your agenda, I
understand you want about 20 minutes of presentation until 1:30, and 20
minutes of question and answer, is that the agenda?

**[\>\> Doug Henley:]{.underline}**

I think that\'s fine as we go right now I would suggest, John, that we
probably, our time is somewhat limited to the two-hour time interval, so
let\'s allow to you do your presentation, and we\'ll see how the Q&A
goes after that.

**[\>\> John Halamka:]{.underline}**

Wonderful. In the PowerPoint stack, and since this is telephonic for
many of us I\'ll mention slide numbers. Please take a look at slide 2,
the landscape of genomics standards today. I start with this slide
because it shows you to standardize data flows for genomics is quite
different depending on the approach, the use case, the special interest
group you may represent. So for example if you\'re interested in
clinical trial development, there are standards that CDISC has put
together that are emphasizing collecting genomic test data for clinical
trials. If you\'re interested in clinical care, there are various
aspects of HL7 data flows that describe clinical genomics or family
history, those are important. There are various standards organizations,
ISO, IHE, DICOM, all working on various aspects of genomic data and
family history. And so when we describe this whole landscape, it\'s very
clear that you need a use case that says what is the purpose of the
data. Therefore that purpose, that use case, will dictate what standards
are developed to support it.

And so if you move on to slide number 3, what you\'ll see, this is a
general organization of the Office of the National Coordinator and
AHIC\'s four-armed activities. Standards harmonization, the nationwide
infrastructure network, HISPC for privacy, and CCHIT for certification.
Broadly speaking, AHIC and its working groups set the breakthroughs, the
priorities, the use cases, and then hand them off to these other
organizations. So HITSP of course receives all of its marching orders
from AHIC.

In 2006 we were asked to work on consumer empowerment, where that meant
demographics, and it meant various aspects of medication, and allergies.
EHR, and that meant labs. And population health, biosurveillance. Well,
in 2007 we\'re being asked to work on emergency first responder use
cases, aspects of medication management in E-prescribing, personal
health records, and quality measurement. And those particular use cases
you\'ll see in my ensuing slides have a very structured approach as to
how we fill out the standards, and then the interoperability
specifications, the unambiguous cookbooks of how standards should be
used by vendors, payers, providers, patients, and other stakeholders.
But at this moment, AHIC really sets our agenda. And I\'m often asked,
well, can\'t you just squeeze in clinical devices or clinical trials or
some other new aspect of work, and our answer is at the moment, we are
funded and staffed to do those use cases that AHIC presents to us. Three
in 2006, four in 2007.

So let\'s move on to slide number 4, responsibilities of HITSP. So HITSP
is a multi-stakeholder group currently of 261 organizations, about 500
different people, who come together to harmonize standards. Now, what
does harmonize really mean? The answer is, well, there are often
competing standards. You may find that I triple E, HL7, and ASTM have
standards that do the same thing. So which do you pick? The last thing
you want is to drive a car that has an 8-track tape player, a CD player
and an iPod jack. You really want one approach to information exchange.

And so we take a use case in from AHIC, we then come out of that with
interoperability specifications returning to AHIC and the Secretary, and
as you\'ll see, the outcome of all of that is acceptance and recognition
by the Secretary, which then results in both certification by CCHIT, and
by executive order, federal procurement, which requires products have
these standards baked into them.

If you look at the next slide, slide number 5, you\'ll see this is the
way in which this whole standards harmonization process works. A use
case comes in from AHIC, and that use case may very well not have a huge
number of details. It may be generally, you know, a patient walks into a
doctor\'s office and has a problem. The doctor needs to retrieve
information and take action.

What HITSP technical committees will do is we'll break that use case
into actors, actions, and events. Who are the actors? The patients. The
doctors. The laboratories. What are the actions? Ordering tests.
Receiving data. What are the events? All of that becomes an
extraordinarily detailed diagram, and therefore, it becomes a framework
by which we would select standards.

Once we\'ve defined all the requirements of the use case, we\'ll then
identify candidate standards to fulfill those requirements. In the case
of the three use cases for 2006, we found over 700 different standards
that could possibly meet the requirements. Now, obviously, 700 different
standards is like having no standards at all, because there\'s just far
too much flexibility, optionality, complexity. So we ended up over the
course of this process, as you\'ll see, reducing 700 standards to 30,
and then building implementation guides that were extraordinarily
detailed about how a vendor should build a product using those 30
standards.

Once we identify candidate standards, we recognize there may be some
overlaps, but there also may be some gaps. So you and your group have
been discussing family history, and you can recognize that the work on
this is ongoing, but it is by no means complete. So this is the
responsibility of an SDO. If a use case is going to be completely met,
this standard SDO, standards development organization, must be
completed. So HL7, get work on family history, get it all done.

Once we\'ve identified gaps and overlaps, we try to accomplish
resolution. That is, are there standards that may be used to fill the
gaps with just a little more work? And in the case of 2006, we found
that the continuity of care document, this notion of bringing together
ASTM and HL7 to have a unified approach for exchanging information,
would meet the use case if only it were done and we were able to get
ASTM and HL7 to accelerate their work, to complete their work in 2006,
to successfully ballot it, so we have now a harmonized and accepted and
balloted standard. And that was a good example of the gap resolution
process. For overlaps we use a set of objective criteria and ask what\'s
the suitability of the standard, what\'s the cost of using the standard,
the burden of implementing it, what\'s its life cycle maturity, is it a
new standard, or something everybody is familiar with? At which point we
can make a decision which of those overlapping standards is most
appropriate.

We then have a standards selection, on from 700 to 30. And of course all
along the way there\'s much opportunity for public comment,
multi-stakeholder involvement, very much an open and transparent process
with all aspects of our work, all of our minutes, all of our meetings
publicly available, published on the Web, and available by audio
conference.

Once we pick those standards, you know, it\'s not good enough just to
have picked even a small set of standards, because there\'s still
ambiguity. An example I\'ll give you is I could tell you that as part of
demographics, gender is a required field. Well, what does that mean?
Because in fact, gender could be male, female, unknown, other. It could
mean many, different things. And in fact, in some vocabularies there are
27 different classifications of gender. So as part of implementing a
standard you have to be extremely specific about what are the possible
states of gender. What are the ways in which you represent medication
names? How in fact do you have vocabularies that enforce not
unstructured text, but very structured data? And so an interoperability
specification is all that level of detail that ensures not just a
standard is selected, but guidance as to how to implement that standard
in a product.

Now HITSP, of course, tries really hard to get it all right, but we need
to be vetted by the industry, by labs, by pharmacies, by vendors. So our
interoperability specifications are then circulated broadly among all
these stakeholders, and tested, reality checked. And once we get their
feedback, we\'ll then do a final revision, and the interoperability
specification will be submitted to the Secretary, disseminated. And the
way that our first round worked, I delivered to AHIC our first body of
work on October 31st. The Secretary accepted that in December, and then
there is a year-long period between acceptance and recognition, and on
December of 2007, you know, all the year\'s worth of work in the
industry may require us to do, you know, a little bit of technical
enhancement or modification, nothing major. January of 2008 we then will
see the official use of HITSP standards in federal procurement. That\'s
its recognition, and official use.

So if we could move on now to the next slide. Next slide is HITSP 2007
timeline. And this slide, obviously the details are not that important,
but I just wanted to give you a sense as to how the process that I
outlined in the previous slide actually gets done. Where we gather 261
organizations together in Washington, we gather intermediate to that
board meetings of 21 members representing each of the major stakeholder
groups to insure the process is appropriately being followed to deal
with issues of governance, to make sure that any opportunity we have to
enhance our work together is done, and with board oversight. The board
has no specific authority. All the decision-making is made by the panel,
in this consensus-based manner. In fact, in all of our work to date,
we\'ve achieved consensus on every single point, without having to do
any major voting. And that\'s very key, because the only authority, in a
sense, that HITSP has is the fact that every stakeholder has said yes,
this is okay, this is appropriate. So consensus to us is extremely
important.

So you\'ll see throughout the course of February through October, we
have panel meetings, and board meetings, and technical committee
meetings, where the technical committees work on these use cases,
constantly present their work product to the panel, panel reviews,
offers input, offers consensus-based decision-making, and that gets us
to this point of delivery of the finished work in October of each year.

And Secretary Leavitt describes this process as a turn of the crank. We
introduce use cases, we come out with interoperability specifications,
and the country has worked together in between to make sure they meet
all needs of all stakeholders. And he has said he wants three turns of
the crank in his administration. 2006, we\'re done. 2007, has been
selected. 2008, you know, I suspect clinical devices, clinical trials,
genomics. These may very well be the work of 2008. And they would follow
the same kind of timeline you see outlined here.

And then moving on to the next two slides, again, the details are not
important here, I just wanted to give you guys a sense of this is a very
stereotyped schedule. Everything published a year in advance, everyone
knows what are the milestones, what are the meetings, what are exactly
the work products to be done at every stage.

So if that is the process, I wanted to give you some insight into the
structure of HITSP. Who is involved, how are we governed, and what are
our committees. So if you\'d move on to the next slide called HITSP
organization. That would be the ninth slide in the stack.

Ultimately, we report to the Secretary and to AHIC. I serve as the
non-voting chair, so my role is truly a facilitator. I am not allowed to
have an opinion, and that means I support small organizations and large
organizations. I support payers, providers, and patients. I am truly
neutral in this process. John Loonsk is our contact at the Office of the
National Coordinator. The project management team consists of
individuals from subcontractors. ANSI is the lead contractor, HIMSS is a
very, very important participant in this and they oversee the technical
process.

And then we have a series of committees. We have what are called
coordination committees. One group led by Lynne Gilbertson of NCPDP
overviews the standards to determine their objective readiness for use.
We have Steve Lieber from HIMSS overseeing our business planning
activities. Bill Braithwaite coordinating our activities with the
international standards organizations and country-wide activities in the
UK, Canada, Australia, Mexico, and Scandinavia. Because if you have a
personal health record in the United States and then you travel to
Scandinavia, how do we ensure that those personal health records can be
translated or are interoperable?

Very important committee is our coordinating committee with CCHIT,
because CCHIT is truly the effector arm of HITSP. Once we have
adjudicated standards, CCHIT ensures that vendors adopt them, integrate
them into their products, and we have to insure that our work products
are appropriately given time in the industry, so that CCHIT isn\'t
trying to certify products a few months after we have adjudicated
standards. But it\'s a gradual acceptance. Reality is vendors need some
lead time to integrate these standards into their products. And it may
be phased. So in the case of laboratories, for example, it may be that
in 2007, just to give you an example, HL7-2-4, is acceptable. In 2008
it\'s AHL7-2-51, and SNOMED codes. And 2009 some additional standards,
UCOM, and some unique aspects of laboratory workflow. CCHIT and HITSP
work together to achieve that roll-out timeframe, that phased
implementation timeframe.

We are working in the background to make sure there\'s appropriate
50,000-foot thinking about standards. How do we ensure that we
coordinate activities around all the standards development
organizations? How do we ensure there\'s good data models for everything
that we need to exchange in healthcare? That\'s our foundations
committee role.

And how do we ensure that there\'s great integrity to the HITSP process,
and constant refinement? We have a process review committee.

We have our technical committees, and those have been divided into our
care delivery committee, which is really more about what happens in care
delivery settings by clinicians. Consumer empowerment, the
patient-basing standards harmonizations. Population health, which also
includes quality, biosurveillance, all the things that are the secondary
uses of data. We have a cross-technical committee that ensures all three
of these committees learn from each other and have very common processes
and standards across all three. And finally, we believe security and
privacy is foundational. And although HISPC is working on creating an
inventory of all the privacy policies in 34 states and territories, that
there is much work that can be done technically even before those
policies are documented. Audit trails, secure transmission,
authentication between organizations, these sorts of things. So we have
a whole cross-committee group working on security standards while we
await HISPC\'s activity.

This next slide, HITSP officers. I serve as the chair, which means I am
a chief point of contact, so should anyone at AHIC or the working groups
have any issues about process, have any questions, I\'m always available
to you guys to answer any questions. Bill Braithwaite is my backup. Lee
Jones oversees the day-to-day program operations of HITSP, and Michelle
Deane is the communication arm, the secretariat, and will be the person
who sends out communication, receives communication probably from our
membership. And Fran Schrotter from ANSI who is their COO, oversees the
project to make sure that we are following all the best practices in the
standards organization.

Our HITSP technical committees, next slide, just describes to you the
general scope of these three groups. And you\'ll see that each of the
use cases that comes in gets assigned to one of these committees. So
again, last year, population health was biosurveillance; consumer
empowerment, medications, allergies, demographics, and care delivery;
the electronic health record, labs. And this year we\'ll assign the
emergency first responder use case to care delivery, we will assign the
PHR to consumer empowerment, quality to population health.

Next slide, this just gives you all the names of our co-chairs on our
technical committees, and you can see we represent quite a variety of
payer, provider, patient, vendor organizations.

And next slide, our cross-coordination activities. We do have
facilitators that ensure good communication across all these moving
parts.

And finally, my last slide. I\'ve given you all the contact information.
We do have a comprehensive Website, www.HITSP.org. Every document, every
process, every work product, is on that site, and fully accessible
without a password. So you can get to the 1,000 page interoperability
specifications or the minutes of the last technical committee meeting at
the touch of a button. We are reorganizing that Website now that
there\'s so much material on it, to make it slightly easier to navigate.
But I think you\'ll find it\'s a very rich resource. So with that, I am
happy to answer any of your questions and be helpful as you try to solve
the issue of genomics, family history, and personal health records.

**[\>\> Doug Henley:]{.underline}**

John, thank you very much, well done as usual. Questions from the
Workgroup members to John Halamka?

**[\>\> John Glaser:]{.underline}**

John, this is John Glaser. I know we are going to be working on, have
started working on use cases, which sounds like we will send to AHIC,
which in turn will deliberate, and then perhaps send them off to you
all. But we\'re also planning to look at various areas where standards
are needed. I think you give an example on slide 5, which we don\'t need
to go back to. How far down this path should we go, and at what point do
we start intruding, frankly, into the HITSP terrain? Because you could
look at, you know, the family history example, say we need standards
there, and we could go down the path that says, you know, maybe we will
and maybe we won\'t, that HL7 is the right approach here. But again,
where\'s the boundary, or where should the boundary be, between our
activities and those of HITSP?

**[\>\> John Halamka:]{.underline}**

Sure. What would be most useful is to get HITSP use cases. Because we
have, you can see, hundreds of individuals working from standards
organizations, vendor organizations, and other stakeholders to help
actually figure out where gaps may be. And I could tell you, some of the
materials I sent you folks ahead of time were just simple questions I
had asked of some of our technical committee leaders. So what do you
know about HL7, SNOMED, and LOINC activities in the world of family
history and genomics? And I got this wealth of data: here\'s where we
are, here\'s who is working on it here\'s where the gaps are. But a use
case would really empower our folks to get you a much more detailed
response, in those particular realms.

**[\>\> John Glaser:]{.underline}**

So to the degree we discuss standards or people working on standards,
this is sort of incidental material for you all. That\'s really you all
are the people who take, sort of scour the environment for the
standards-setting process and zero in on the appropriate standards.

**[\>\> John Halamka:]{.underline}**

Exactly right.

**[\>\> John Glaser:]{.underline}**

Okay.

**[\>\> Doug Henley:]{.underline}**

Very good direction, great question, John. Other questions from the
Workgroup?

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

John, this is Steve Matteson from Pfizer. Would you have examples of the
use cases that you\'ve used in the past posted out into these Websites?

**[\>\> John Halamka:]{.underline}**

They are all there.

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

Oh, perfect.

**[\>\> John Halamka:]{.underline}**

At HITSP.org you\'ll see our detailed use cases. And these UML diagrams,
as we call it, show actions, actors, and events, how we turn a use case
into these very detailed set of products that we can hang standards
against.

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

Could I just ask a question, do you use any specific tools to manage
those use cases?

**[\>\> John Halamka:]{.underline}**

There are, Sharepoint is of course a collaboration tool that we use to
exchange documents, but I do know that the technical committee chairs
have used some UML modeling tools, and I don\'t know the name of those
tools offhand. But \--

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

That was what I was curious about.

**[\>\> John Halamka:]{.underline}**

And I can certainly get you that. If you send me an e-mail, I can get
you the details of the products.

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

Great, thank you.

**[\>\> Doug Henley:]{.underline}**

Other comments or questions?

**[\>\> Carolyn Clancy:]{.underline}**

John, it\'s Carolyn Clancy. Just in terms of gaps, my question is what
if we develop a use case for which there are no standards in
development?

**[\>\> John Halamka:]{.underline}**

Well, what a great question. And so let\'s look at the CCD example. So
here was this challenge that we had ASTM that had done wonderful work on
clinical content, and HL7 that had done very good work on clinical
document architecture that allowed hospitals that already had spent
years doing HL7 to exchange documents. But you never had a marriage of
the two. Because wouldn\'t it be great if you have
vocabulary-controlled, semantically-interoperable clinical content in an
HL7 wrapper that could be used without ripping and replacing hospital
systems. So we said guys, this is a huge gap. We need resolution now.
And the whole of the HITSP body issued letters of endorsement to HL7 and
ASTM, you know, we are going to set a deadline of April 1, 2007. And if
you have not finished completing a standard that works for everyone, we
will impose an artificial and ugly solution on you. And they did it. And
so that\'s where HITSP can be a very motivating and unifying force to
bring standards to completion, even if they\'re not yet done.

**[\>\> Carolyn Clancy:]{.underline}**

Thank you.

**[\>\> Doug Henley:]{.underline}**

Other comments, questions?

**[\>\> John Glaswer:]{.underline}**

John, this is John Glaser again. I realize you have to be neutral, so
this may be an unfair question. Are there particular use cases in this
plethora of use cases that you would point to us as being really good
examples of what HITSP is looking for in terms of granularity, things
like that?

**[\>\> John Halamka:]{.underline}**

Sure. I will tell you certainly, the EHR laboratory use case was a very
good one to look at. The consumer empowerment use case was actually a
rather tough use case, because it\'s such a moving target. You know,
there\'s a new personal health record that seems to crop up virtually
every day. So take a look at lab, I think that would be a good solid one
for you.

**[\>\> John Glaser:]{.underline}**

Okay.

**[\>\> Greg Downing:]{.underline}**

John, this is Greg Downing, thank you again for that very clear
presentation. One of the areas that we\'re going to be hearing about
next is the incorporation of family history, and the notion that this
group overall felt that leading towards the broader goals of this
activity, that clinical decision support was really the underlying
utility of having genomic information incorporated into electronic
health record. It came up relatively early on in the discussions here
that incorporation of family medical history information complemented
those test results, and in many cases is essential to the interpretation
of those results.

The nature of the vocabularies around these two different areas is very
different in terms of how the information flows, how it\'s captured,
what it\'s used for, and just the vocabularies themselves are quite
different. In shaping and thinking about use cases that would be useful
for HITSP, these are two different species of data, I guess. Do you have
any recommendations as to if a use case was to be developed
incorporating both of these features, how to approach that and what
complications that may invoke?

**[\>\> John Halamka:]{.underline}**

Sure. All of HITSP members believe that semantic interoperability, with
good vocabularies as well as message structure, is extremely important.
And you\'ll see that we have used SNOMED-CT, LOINC, UCUM, a variety of
medication standards, NCPDP, et cetera, in all of our interoperability
specifications. But we also recognize the reality of many systems today
is that unstructured text rules. So what we\'ve had to do in our
interoperability specifications is say we today want at least technical
interoperability. That a human can read whatever clinicians place in
systems, so that that is in fact a great way to start coordination of
care. But wherever possible, we do want to use controlled, structured
text. So that it\'s computable, not just human-readable. And eventually
where we want to get to is process interoperability. Wouldn\'t it be
wonderful if a family history was created in a codified way at Partners
HealthCare, and then a patient who presented to Beth Israel Deaconess
with a given condition was given a specific therapy because we were able
to combine data across organizations, and then business rules fired off
a provider order entry or other system that said go do this. That\'s
where we\'re all headed to.

**[\>\> Carolyn Clancy:]{.underline}**

You\'re starting with the tough one first.

**[\>\> John Halamka:]{.underline}**

Yeah. And so recognizing technical interoperability is where we\'re
starting. Semantic interoperability, where we\'re getting as close as we
can. And process interoperability, we\'re not there yet.

**[\>\> Greg Downing:]{.underline}**

Thank you.

**[\>\> Doug Henley:]{.underline}**

Thanks once again, other comments or questions to John Halamka?

Okay. Well, John, as usual, job well done. Thank you for that great
introduction to HITSP, and particularly the direction in response to
John Glaser\'s comment or question about a focus on the appropriate
construct of use cases. So thanks again for your comments and your
presentation.

**[\>\> John Halamka:]{.underline}**

Folks, I live by Blackberry, so 24/7 if you need anything, you know how
to get me.

**[\>\> Doug Henley:]{.underline}**

All right, sir.

**[\>\> John Halamka:]{.underline}**

Thank you.

**[\>\> Doug Henley:]{.underline}**

That\'s dangerous doing that.

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

I\'ll be working until 2:00 a.m. any night, so that\'s appreciated,
John.

**[\>\> John Halamka:]{.underline}**

You got it. Talk to you folks later, thank you.

**[\>\> Doug Henley:]{.underline}**

At this time I\'ll turn it over to John.

**[\>\> John Glaser:]{.underline}**

Thanks, Doug. Our next speaker is Kevin Hughes, who is a colleague of
mind at Partners HealthCare, Kevin is at the Massachusetts General
Hospital. And as Doug had mentioned in his opening comments, Kevin is
here to talk about a particularly important topic for us all, which is
family history. So Kevin, you\'re on.

**[\>\> Kevin Hughes:]{.underline}**

Great, John, thank you. Thank you again for this opportunity. I want to
go over data standards for family history and what we\'ve been doing
within HL7 to try to make that happen. If I could have the next slide,
please. I can\'t change slides from here, is there someone who changes
them?

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

Yes. There\'s a little bit of a lag, you just keep talking, it will
catch up with you.

**[\>\> Kevin Hughes:]{.underline}**

Very good, that sounds fine. This is a use case we have put together,
and it may be not at the same standard that was talked about earlier,
but basically the problem that we have is that family history gets
entered over and over and over again, and seldom transmits
electronically. So as you see here, a patient can enter data into My
Family Health Portrait, the Surgeon General\'s program. When she\'s done
she prints her data out on paper and brings it to her primary care
physician. The primary care physician dictates that into a chart, the
patient is identified as high risk and referred for mammography and risk
assessment. At mammography, and every mammography center in the country,
family history is collected and put into the film envelope or it\'s
ignored from that point forward. At the risk clinic the patient has
family history keypunched into CAGENE, a risk modeling program,
keypunched again into Progeny, a pedigree drawing program. The clinician
then dictates family history into the chart, and then the clinician
dictates a letter with family history in it. Next slide, please.

So as you do this, the patient is giving her family history over and
over again, the clinicians are putting more and more time into family
history, and just in this very simple scenario that many people have
been through, this is seven different times that family history is
collected and placed into a record, and very seldom in a way that\'s
useful to anybody else. Next slide, please.

So this is the underlying problem that we want to solve. And I think you
all know this already, if your clinic is using more than one system, you
have duplicate data entry, which is a waste of time, it\'s distressing
to the patient, it\'s distressing to the staff. It increases your risk
of error as you put the same data in over and over again. And the
solution we think is a translation program which takes data from one
program, changes it to the format of a second program, and then bring
the data from one place to another, which I think is what all of our
goals would be. Next slide, please.

So this is again where we\'re going. And if you look at a family history
process, or what\'s happening in our clinic, a clinician really has to
record a family history, then has to analyze that family history to look
for patterns of various syndromes, then has to manage that patient, and
hopefully, every time the patient comes back, that data gets updated,
recorded again, goes through the cycle again. Next slide, please.

So these various processes you\'re seeing here can benefit tremendously
from electronic integration of data, but currently most of those
processes are done on paper. And when done on paper, you have to review
the pedigree at the time it\'s generated, or the family history as its
generated. If you don\'t recognize a syndrome immediately, you can\'t go
back and try to find that syndrome later, other than trying to remember
which patient had which paper record that might have that syndrome. And
as we move along and genomics identifies new syndromes, you can only
remember by memory which chart to look in to try to find a family
history that would match this new syndrome. It\'s hard to update,
you\'re constantly redrawing the pedigree, you\'re redrawing the family
history, and you can only share it with those within immediate
proximity. Next slide, please.

So again, I think all of us agree that paper is not really the way to
go. Now, on the other hand, if you do this electronically, and if you do
it with structured data, and in a consistent way, you can collect data
consistently and you can have consistent field names and codes for each
situation. Next slide, please.

And many people, many programs, have put together ways of collecting
this data electronically, including risk analysis software, software
that can take the data and then predict which patients, or generate
hypotheses of which patients may be at risk for genetic mutations. This
is a printout of cancer gene written by Dave Euhus at UT Southwestern
that gives probabilities of BRCA1 or 2 mutations. Next slide, please.

So risk analysis software can help in the analysis phase of that data
gathering. And then there are pedigree drawing programs, this is a
program called Progeny, where when you put the data into the program, it
draws you a pedigree and helps you to visualize what the pattern of
cancers or diseases are in the family, and can help you make the
analysis visually or eyeballing the pedigree to find out who might be at
risk. Next slide, please.

Now, as good as these programs are, they\'re good because they can run
risk algorithms, they can draw pedigrees to make it easier for us to
identify patterns in a family history, they\'re much easier to update
because you just change a field in the program to get a new pedigree.
You can look for high risk patients later in a batch mode, and you can
also search for new syndromes as they\'re discovered. But the problem is
that each of these programs is very time-consuming to use, and so for a
busy clinician to spend three to five to ten minutes per patient to
enter data into these programs is really not feasible at the primary
care level. And in addition, these programs are not standardized across
institutions, or even within institutions, so data gets put in again and
again. Next slide, please.

So while we all want to get a structured family history into the
electronic medical record, we do not want to put it in over and over and
over again. Now, because of the advantages of having structured data,
shown here are seven different programs that have been developed to
collect family history, and use that family history. CAGENE at the top
again is a risk analysis program. My Family Health Portrait is from the
Surgeon General to collect data and bring that to the PCP. Jameslink is
out of Ohio State. Family Healthware is a CDC program. Our Avon Tablet
System is another way of doing this, et cetera. So we\'ve all identified
these things as problems, we\'ve all identified our own software to do
this. Next slide, please.

So all of these can collect family history information, and can collect
some genetic information, and try to use that data. Now, in developing
our HL7 standards, I work with the clinical genomics special interest
group of HL7. We\'ve been working for the last two to three years to
identify how best to develop the standard for transmitting family
history information. So the first thing was just to boil this down to
the minimum data elements needed for each relative, and for the
individual, to transmit family history, and to use it effectively in
these various programs.

Now, what you see at the top is the name of an individual relative, the
identifier for that relative, which is just a randomly selected
identifier each time the patient is brought in, or each relative is
brought. And what\'s called a mother ID and a father ID. And the reason
for these IDs of a mother and father is this is how you reconstitute a
pedigree or relationships at a later date. If I know the mother and
father ID of a cousin, I know whether that cousin is related through a
sister or a brother of the father. So these mother and father IDs are
critical in all of these software programs.

Blood line, being maternal or paternal or unknown. And then clinical
information. What diagnosis does each relative have, and that could be
more than one diagnosis. What\'s the age of diagnosis for each. What\'s
the current status of that relative, alive or dead. The current age or
the age of death. If they had genetic testing, what gene was tested. As
a general result, what was the result. Was it deleterious mutation,
unknown significance, polymorphism, no mutation, et cetera. And the
specific result or the actual sequence. This is the data that we really
need for each of the basic family history programs in order to draw
pedigrees and produce risk analysis, which is of course decision
support.

Now, each of the programs I mentioned collect most if not all of the
data shown here, and each of them collects it differently, which means
that you cannot take data from one program to another, and it\'s why at
many risk clinics the genetic counselor or the nurse punches all this
data into CAGENE and then keypunches it again into Progeny. Next slide,
please.

If you have only two programs that you\'re working with, then a single
translation routine can bring you from one program to the other \-- next
slide, please \-- and it\'s a relatively simple process. When you start
getting into multiple programs, you start to increase tremendously the
number of translation routines that you require. So seven programs shown
here require 21 different translation routines to get the data from each
of the programs to each other program. Next slide, please. And that
number of translation routines increases each time you increase the
number of programs you\'re dealing with. So for these seven programs you
see, there are seven \-- I\'m sorry, 21 separate translators. If you add
an eighth program, that adds seven more translators. A ninth program,
that\'s eight more translators on top of that, et cetera. So as we add
more and more of these individual programs to do family history, we\'re
going to develop a tremendous need for more and more translation
routines, which is just not feasible. Next slide, please.

So the approach that HL7 takes is to create an international standard to
integrate health information, develop standards that permit structured
healthcare information to be exchanged between applications. And the
idea is that HL7 creates a message to go from one computer program to
another. Next slide, please.

So the idea is not to create a standard for electronic health records,
but how to help two separate EHRs interact. So if you look at the
problem we talked about earlier, you have two programs, the Avon system
and the CAGENE system. If you create a common intermediary, you can go
from the Avon system to the HL7 model and then to the CAGENE system, and
each of these can interact in either direction. So you can now take data
from CAGENE to the Avon system through this intermediary. Next slide,
please.

What this means now is that you now only have to make one translation
routine for every program that you want. So as you see on this slide,
the same seven programs would only require seven translation routines,
as long as each program could go in or out of HL7, then you could go
from any program to any other program through HL7, and every time you
add one, two, five more programs, you only need one more translation
routine per program. So the idea is to create an HL7 model or message
that contains a way to transmit all this information correctly that any
other program can interact with, and would carry the right information
to those programs.

Now, having said that in general terms, we\'ve also done this in a pilot
program. We\'ve taken data from our Avon Tablet System, which is a
home-grown system here at Mass General, and we\'re able to take our data
into the HL7 model or out of it. And we\'ve also created translators for
Progeny, for CAGENE, and for My Family Health Portrait, the Surgeon
General\'s program. And can now take data from any of those four
programs and bring it in or out of those four programs.

So the HL7 model we\'ve created is a robust model, is a useful model, is
a model that actually works in clinical care. And I think we\'ve
identified what some of the problems we\'ve \-- we\'ve identified
problems, as well as solutions here, in that as you identify the pieces
of information you want to transmit, you find that several of these
software packages are lacking in some aspect of what you\'re trying to
transmit.

So just as an example, we wanted to bring cancer information into
CAGENE. We have, as you know, possibilities for genetics testing of
unknown significance or deleterious or a benign polymorphism. However,
CAGENE only accepts either deleterious or no mutation. So in working to
make these translators, we\'ve also identified gaps within each program
that we\'re now trying to work with the vendors to repair.

On the other hand, we\'ve also noticed problems in the level of
information that we\'re trying to transmit. And as it was brought up
earlier by Dr. Halamka, we want to use programs or coding systems such
as SNOMED or ICD-9 to transmit information, but we sometimes find that
the level of information we have is not up to the specifics of a coding
system.

So for example, if my patient says that her grandmother had breast
cancer, I don\'t know if that\'s invasive breast cancer or non-invasive
breast cancer. But the ICD-9 coding system forces me to choose between
those two. So we use a different system for that, we use MESH, which
could just say there\'s breast cancer present and not define it as
invasive or non-invasive. On the other hand, we\'re able to use ICD-9
when we know if it\'s invasive or non-invasive cancer. Next slide,
please.

So we have developed a model that we\'re fairly comfortable with, and I
think the storyboard for the future, as Dr. Halamka referred to earlier,
is that a patient could enter data, enter a family health portrait at
home, and then save that data either to a flash drive or e-mail it to
her physician in HL7 format. And alternatively, a patient could enter
data in a waiting room to a tablet, as we use here, or a kiosk system.
And then when the patient sees the PCP, that HL7 message can be uploaded
into an electronic health record or uploaded \-- I\'m sorry, and once
it\'s there, it can be edited by the clinician. You can run decision
support modules looking for high risk, you can refer for high risk to
mammography. And now export that updated family history again to the HL7
message. That HL7 message could be uploaded in mammography to another
reporting system, to their reporting system. At the high risk clinic you
can take that HL7 message and upload into your administrative program
for the clinic. You can edit and expand the family history, you can run
CAGENE and Progeny to get more information and analyses. Those analyses
can become part of your electronic health record, and that data can then
go back to the PCP work and update his records to a more complete family
history.

This is I think the ideal for the future. Where we are now is we can
take the data entered at home by the patient and put it into our HL7
message, we\'ve done that. We can now bring that into the risk clinic
where it goes into our administrative Avon system, where it can then go
to CAGENE and Progeny and can run a risk analysis and draw pedigrees. We
are not yet able to bring it into our electronic health record, but we
are now actively working with the EHR people here under Dr. John Glaser
to try to actually bring it into the EHR as well. Next slide, please.

So while this is where we want to get to in the future, we actually have
the capability with our current HL7 message to do these things. And
again, just as a proof of principle, we have taken My Family Health
Portrait into the HL7 message, taken that into our tablet system, done a
risk analysis by CAGENE, and then drawn a pedigree. All those things
we\'ve now been able to accomplish with the message that we\'ve created.
Next slide, please.

So we know that our system currently works. This is how we\'re currently
using this information. We have data collected either in the breast
imaging department, or in our breast center in the breast surgery area.
All this data goes to a central repository. Within that repository we
identify high risk individuals, we contact those patients where they\'re
brought to the risk clinic. The data is shared with the risk clinic,
both in terms of giving them data to take care of the patient, and then
once the risk clinic is complete to bring that data back to our central
repository where it\'s available to the breast surgeon and to breast
imaging in the future. So this system is currently working for us, and
using HL7 as an intermediary we\'ve been able to use the various
programs we want to use in each area. Next slide, please.

What we want to move beyond in this is to start going outside the
institution, as well. Where again, the patient can use the Surgeon
General\'s model at home, and bring HL7 data into the risk clinic. From
our central repository HL7 messages can be created to other
institutions, where they can use that data, and other institutions can
send us data within the HL7 format. And again, from a piloting point of
view, we\'ve proven that this can be done across programs. We need to
just make that a little bit more robust, and we need to make sure every
other programmer is able to do this. Next slide, please.

So our HL7 message has passed the committee-level ballot within HL7.
It\'s been submitted now for membership-level ballot going, I think in
the next two months will be voted on. When that\'s passed that will
become the ANSI standard for family history transmission. And then we
plan to submit this to the ISO so it becomes the international standard
for transmitting family history. Next slide, please.

So we\'ve gotten fairly far along within this message, and we feel
fairly comfortable that this message works. We believe that all programs
that collect family history should collect structured data and collect
the minimum data set that we\'ve tried to outline here. This allows
decision support, pedigree drawing, search capabilities, and use of new
information and new syndromes as they become available. And we would
like to see all programs become HL7 compatible. If they\'re able to
import or export to HL7, they can then import and export to any other
program that\'s out there that does the same thing. So it allows sharing
between applications and between institutions. This of course does I
think what your group wants to do, decreases duplicate data entry,
increases efficiency, and allows us to better care for our patients.

So I guess just in closing, is we\'ve tried to identify what data
elements we think are necessary for family history. We\'ve identified
several vendors that collect that data in a way that\'s very good. There
are many EHR products out there that do not collect family history in
this way, so that even if we wanted to import or export into them, they
don\'t have the fields or the capability to accept it. So I think making
it more clear to EHR vendors that these fields are very important would
be useful. And if everyone becomes HL7 compatible, this gives us a way
to transfer from one place to another. I can stop there, and entertain
any questions.

**[\>\> John Glaser:]{.underline}**

Kevin, thank you, that was terrific. Any questions, comments?

**[\>\> Janet Warrington:]{.underline}**

I have a question, this is Janet Warrington. Kevin, I like the example
that you gave on the breast cancer with the grandmother and the patient
not knowing specific details, and it made me think of another question.
Is there a patient opt-out feature, so for patients that don\'t have any
family history information, or who choose not to share it, that they
could opt out of participating in this portion of this, and not break
the system?

**[\>\> Kevin Hughes:]{.underline}**

The patient has the option to answer or not answer any question that
they wish. So we certainly cannot force them. We have very few patients
who do not provide the information. But remember, we\'re in a clinic \--
we\'re a clinical center.

**[\>\> Janet Warrington:]{.underline}**

I was thinking of the situation where you have a patient whose parents
were not their biological parents. And then, you know, how do you manage
that? And so could they just simply opt out without sharing too much
personal information?

**[\>\> Kevin Hughes:]{.underline}**

Yes, they can. And basically, we were asked by our breast imaging
service to put in a marker that the patient was adopted, if they wish to
share that information. And the patient then, once you state they\'re
adopted, can either give family history if they have it, or they will
stop being asked what their family history is, because people will know
that they\'re adopted and they don\'t have the information. So yes,
that\'s a feature that we do have.

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

This is Steve Teutsch, I have a question. How do you adjudicate this
when you get inputs from multiple sites which may be done slightly
differently, how do you decide which is the correct one?

**[\>\> Kevin Hughes:]{.underline}**

That\'s a very good question. We are fortunate at this point in time
that most sites don\'t collect anything.

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

That\'s one solution.

**[\>\> Kevin Hughes:]{.underline}**

So at this point in time we\'re kind of the only game in town, and if
anybody collects something electronically it\'s nice and we\'ll try to
use it. I think in the future when this becomes more universal, that
will become a problem. And I think you have to always go back to the
patient and get the patient\'s best estimate of what truth is.

But that\'s going to be a problem, by all means. And it\'s the same
thing for medical history, as well. If a patient says \-- we have
patients who tell us that they do not have cancer, and yet we know from
our tumor registry that they do have cancer. And so do you take the
patient\'s word or the tumor registry\'s word, and how do you put that
in the chart in a way that\'s useful? That\'s a problem we didn\'t have
when we used paper, but that is a problem we have to figure out both for
family history and for medical information in general.

**[\>\> Marc Williams:]{.underline}**

Yeah, this is Marc Williams, Intermountain Health Care. You know, a
comment on the previous answer that Kevin gave, you know, if we really
do get to a truly interoperable system, where we have publicly available
records that can be queried along with the electronic health record, and
we deal with the significant issues of privacy and security, it\'s
certainly possible to build in probabilistic queries that can assign a
degree of reliability to any given answer based on information that
would be available from other sources.

And it\'s something that I think will evolve to help. It raises an
important question about family history, which is there has been limited
research done looking at if we treat a family history question as a
genetic test, applying issues of validity to that. Not to mention the
utility of actually having that information.

To some degree, what Kevin has presented around cancer is probably the
best studied area, particularly breast-ovarian cancer. But for common
disease, family history, which has becoming increasingly a target in
which the focus of the Surgeon General and CDC tool is really around
common disorders, there\'s much less research that\'s been done about
can we trust the answer that\'s been given. For diabetes, the answer is
probably yes. For mental illness the problem is, the answer is almost
certainly no. So it defines a research agenda that needs to be done as
we begin to try and use this information, as well.

I have one question, Kevin, it\'s certainly possible to define
relationships informatically, really down to very fine detail in terms
of issue of adoption, and half-sibs, and all this sort of thing. It
strikes me, though, that with the complicated families that we
frequently encounter, that it is difficult, perhaps, with a patient
interface to really have them understand what constitutes a blood
relationship, and how that relationship should be defined from their
perspective. Could you tell me a little bit about how you\'ve been
approaching that?

**[\>\> Kevin Hughes:]{.underline}**

Sure. Basically, the Surgeon General\'s model is a great way for
patients to put their own information in. But they can make those
mistakes, as Marc has talked about, they can not quite know who their
blood relative is, not quite know who the uncle is, or which cousin is
related through which aunt or uncle. And I think that this is where the
interoperability is most helpful. The patient puts in the data to the
best of their understanding. We can then tweak that data with our system
to add in the half-sib relationships or take out the patients out of the
blood line, working with the patient to try to better define what those
relationships are. So I think it\'s a matter of rather than starting
from scratch with a blank piece of paper or blank computer screen in
front of you, the patient has already given you a lot of the
information, and now you have the chance to fine-tune it.

Now, the other thing is the HL7 message we\'ve created is we hope based
in realty, and the reality is that we don\'t always have all the
information. So if you happen to know that the cousin is the daughter of
the patient\'s aunt, that information can be transmitted using these
mother and father IDs. On the other hand, if you want to put in the HL7
message what\'s normally in a written chart, cousin, breast cancer, you
can transmit that as well. You leave out the mother and father ID, just
put in cousin, breast cancer, underneath. So this message is made to
transmit the highest level granularity that\'s available in many
pedigree and risk analysis programs, that\'s also able to go down to a
much lower level, which is more what we collect in medical charts today,
of very rudimentary family history.

So I think, Marc, both we\'re trying to catch the granularity you\'re
looking for, and trying to enhance it at each step of the way by taking
the data from one step to the next, and growing it each time. And also,
being cognizant of the fact that we don\'t always have good information.

**[\>\> Marc Williams:]{.underline}**

Thanks for that. I also should mention you touched on something that I
think it would be good to be very explicit about this, you know, the
issues that I brought up in my comments earlier, these are not new
issues in terms of using family history data. I mean, these are issues
that we struggle with today in terms of using the collection tools on
paper, or by history, or however. So we\'re not talking about a
situation that\'s going to be any worse than what we currently have. It
just is going to be a little bit more ubiquitous. In other words, it
won\'t just disappear somewhere, it will continue to pop up, which could
impact the way the information is used.

**[\>\> Kevin Hughes:]{.underline}**

And I completely agree with that. And we are actually finding that
problem in that, again, I\'m a clinician, and I have never had a problem
with giving a patient a sheet of paper and saying what\'s your family
history. They write it down, I sign it, put it in the chart, and it\'s
part of the medical record. However, when we\'re trying to take
electronic history from the patient, and put that into the electronic
medical record, the degree of accuracy or perceived accuracy goes up
astronomically, because it\'s now in electronic format. And our EHR
group is very concerned about taking patient data and putting it into an
electronic record. Yet we have done that with paper. So these are
problems we have to figure out and solve, I agree.

**[\>\> John Glaser:]{.underline}**

Other questions for Kevin?

**[\>\> Doug Henley:]{.underline}**

Kevin, this is Doug, Doug Henley. Let\'s \-- I just want to get a sense
of where these various programs that you\'ve mentioned, like Progeny and
so forth, may be going. So let\'s assume that this Workgroup creates a
use case that leads, that gets transmitted to the HIT Standards Panel,
that leads to their, as we heard earlier from John Halamka, leads to
their recommending to AHIC certain standards which allow that use case
to go forward, and one of those standards is in fact your HL7 family
history message, as you\'ve described today. And then that gets
approved, and gets, becomes part of the certification process for EHRs,
and gets implemented, embedded in future programming as part of the
CCHIT process. If we get to that point, which, you know, hopefully
we\'re moving in that direction, does that mean, then, that these other
programs, you know, the Avon Tablet System, the My Family Health
Portrait, et cetera, does that not put pressure on them to conform,
then, to that standard, embedded in the EHR, so that this becomes more
simple over time?

**[\>\> Kevin Hughes:]{.underline}**

Absolutely. And I think that as you, as it becomes \-- it\'s not that
they need to change what they\'re currently doing, because they\'re too
far along to do that. But they need to collect the same information that
we want to transmit, and need to collect it in a way that\'s easily
translatable from their program into an HL7 message and thus into the
EHR. So it will put pressure on these programs to collect their data in
a more uniform manner or more complete manner, but I would say that they
are very far along in doing that.

I think the pressure is going to be more on the EHR groups to produce an
EHR that has places to put this data in where it can be useful. So I
think it\'s more on the EHR side. These programs were created by
individuals literally at various institutions out of frustration for
lack of the ability to get this data where they need it or where they
use it.

The LMR here, our EHR does have a place for family history that can take
this data in this way, but many programs do not. And I\'m often asked as
I show our program, they\'ll say, well, can you bring this into the EHR,
and I\'ll say sure, does the EHR accept it. And the answer is no. So I
think we really have to push the EHR groups to accept this data in a way
that\'s useful. And on the flipside, these programs that were made
specifically for genetic indications really do have the majority of the
data that just need some fine-tuning.

**[\>\> John Glaser:]{.underline}**

Kevin, this is John Glaser. I have two questions, I think they may be
related. One is, the first question, if I were to take the storyboard
that you present of the HL7 future, and we don\'t have to go back to
that slide, is there sort of one generic family history use case? I
mean, you might \-- Progeny might be using all of them, but CAGENE might
be replaced by something else. Or does one really need multiple? And
it\'s related to the second question about how fine-grained the use case
ought to be.

So for example, your question about the patient may not know whether
it\'s invasive or non-invasive breast cancer, that obviously is
important for understanding of the reality of this stuff as one gets
into standards activity. But if a use case is going to provide guidance
there, it ought to \-- it has to get reasonably fine-grained, it seems
to me. I\'m just curious, there may be other members of the working
group that would know this, too. Is there one or multiple, and how
fine-grained should we be in order to be really useful?

**[\>\> Kevin Hughes:]{.underline}**

I think that\'s a great question. I think there are a number of very
good programs out there, and I certainly will put Progeny as somewhat
the industry standard for doing pedigrees. As you say, CAGENE is useful
for the genetic cancer community, but not so useful for the non-cancer
community. And I think My Family Health Portrait and now the CDC model
are both ways for patients to put data at home. I would say that if you
are able to take data from the home situation, with either the CDC or
the Surgeon General\'s model, and take it into an EHR, and have it used
within an EHR to create a Progeny pedigree, I think if you can just go
through those three or four steps you\'ve probably covered most of the
problems you need to deal with.

**[\>\> John Glaser:]{.underline}**

Okay.

**[\>\> Marc Williams:]{.underline}**

I would concur with that. As we\'ve been thinking about this \-- this is
Marc Williams, Intermountain. As we\'ve been thinking about this within
our system, it seems that, you know, there are \-- we\'ve been
visualizing sort of a core family history, which would be something that
might be obtained in the course of a primary care physician visit, where
you would be using a general tool like the Surgeon General\'s tool or
the CDC tool to collect information around a relatively broad group of
disorders.

But that it would also need to be able to interact with what I would
call specialty modules. Because if you go to the ophthalmologist
they\'re going to have very specific family history questions that they
should be asking, which are going to differ significantly than if you
happen to be in the oncologist\'s office. And yet those systems need
to \-- you know, cross-talk to one another. But in terms of the concepts
that are used and the representation of the data using coding systems
such as ICD-9 or SNOMED, you know, those are relatively standard.

Now, as you sort of go to the next level, where you\'re looking to say
well, if we really want to do clinical decision support and risk
stratification, what other information besides family history would be
useful, then you begin to pull from additional sections of the data
warehouse, and then, depending on the specific question that you\'re
asking or the specific scenario, you may be querying very different
places. And so whether you could develop a use case that would sort of
cover everything in that type of a very sophisticated scenario, I\'m not
so sure. But at least to represent family history and how it could be
used, I think that that could be represented probably in a single use
case.

**[\>\> John Glaser:]{.underline}**

Fair enough, Marc, this is John Glaser. Maybe \-- and we\'ll have to,
when we get together, I guess, in March, talk about the scenario that
might be 10 years out, and to what degree we think the country will need
to be in a position where it\'s doing more sophisticated and more
targeting type of family history collection and decision support that we
rely upon. The upside is that perhaps it will be, the downside is that
could be a lot of use cases and scenarios we\'d have to describe.

**[\>\> Marc Williams:]{.underline}**

Yes.

**[\>\> John Glaser:]{.underline}**

Any other questions for Kevin?

**[\>\> Kristin Brenner:]{.underline}**

This is Kristin Brenner, I just have a question. You mentioned briefly
that some of the family history information is potentially capturing
information that is not necessarily genetic, or wholly genetic. Are you
capturing even a greater amount of health information, such as if your
parents smoked or are obese, that really is not necessarily genetic at
all, but could have bearing on your health information?

**[\>\> Kevin Hughes:]{.underline}**

That\'s a very good question. I think we put that out \-- we discussed
those things and decided not to include those in our situation. The
advantage of the HL7 approach is that it\'s XML and it\'s very
extensible, as advertised. So if you say that the patient has a father
and if you say that the father is a smoker, you have captured that
information within the family history. We have not modeled that, but as
long as there\'s a code somewhere out there for smoking, which I\'m sure
there is, I can\'t tell you what it is offhand, as long as that code is
there we could add that code within this system very easily.

**[\>\> Marc Williams:]{.underline}**

The Surgeon General\'s tool collects that type of information for the
individual that is completing the tool to be able to refine their
personal risk assessment, so they have a data representation for it. But
they do not include that for relatives, is my recollection.

**[\>\> Kevin Hughes:]{.underline}**

I think that\'s true, also, but if someone were to collect it, our
message structure would allow it to be transmitted.

**[\>\> John Glaser:]{.underline}**

Other questions for Kevin? Kevin, thank you for taking time to educate
us. Very much appreciate that, and look forward to working with you in
the future on this thing.

**[\>\> Kevin Hughes:]{.underline}**

Thank you very much, John. Thank you.

**[\>\> John Glaser:]{.underline}**

I believe next we have a discussion or overview of the recommendation
use case development process. Is John Loonsk going to deliver this?
John, are you there?

**[\>\> John Loonsk:]{.underline}**

Hi, John.

**[\>\> John Glaser:]{.underline}**

Okay, I wasn\'t sure I heard you on the initial role call. So delighted
to have you, and you\'re on.

**[\>\> John Loonsk:]{.underline}**

Thank you. So I\'m going to give a little bit of an update. The last
time I appeared before this working group I talked about the general
process that we have been following for a number of the national health
IT agenda activities, including taking priorities from the American
Health Information Community, translating those priorities into written
articulations in the format of, in the form of these use cases, and then
having these use cases of the American Health Information Community be
advanced to Health Information Technology Standards Panel, to the
Nationwide Health Information Network activities, to the certification
activities, as well as to other discussions.

At the January meeting of the AHIC, the Community decided upon its next
round of use cases for 2007. So previously they had identified the need
to have an emergency responder EHR use case. That was developed, it went
through two rounds of public comment, and was finalized. So what they
decided in January were the next three use cases that will also be part
of this year\'s cycle.

And I think that John Halamka may have mentioned these earlier, but I am
going to mention them again and talk in a little bit of detail about
them, to give you a sense for what may be included in them. But they are
consumer access to clinical information, medication management, and
quality.

Now, during the meeting Secretary Leavitt also asked, managed to contain
himself from asking that they all be done at the same now, and,
thankfully. And did ask that the next round, those that were not chosen
immediately, were to be worked up as soon as this round, these next
three, were finished.

So we have a time schedule for two rounds of public comment on these
next three: consumer access to clinical information, medication
management and quality. We\'ll involve prototype use case, public
comment on the prototype, detailed use case and public comment on that,
and then them going final in an April timeframe.

At that point we will have been asked to begin to work up this next
round of use cases. And since the work of this working group was not
even on the table at that point, in terms of consideration, I am
presuming, and think I have every reason to assume, that this work can
be considered in that next round to be worked up, as well.

But the other ones that are on the table for that activity, so just to
try to be clear, that starting in an April-May timeframe, we would be
developing and writing up this, use cases in the area of remote
monitoring, remote consultation, public health case reporting, response
management, and referrals of transfer of care. And there was clearly a
hope that over time we can develop additional capacity to do more things
at the same time, in terms of moving forward. If there are opportunities
to do that, then we will have these use cases available. Otherwise, they
would be choices to be used in the next round of activities. So we have
also talked \-- had initial discussions about trying to work together
collaboratively to develop a use case for this activity. And we can talk
more about that, as well.

But first, let me just talk a little bit about the use cases that were
advanced immediately, and allude to some of the things that I think are
relevant to this conversation, as well.

So one of the activities we\'ve tried to advance in the context of this
next step work, is we\'re increasingly trying to modularize some of the
capabilities. So that where that work is applicable, it can be used in
the context of supporting multiple activities. And I think you\'ll see
that there are some common themes in some of these other use cases and
activities that are highly relevant to the work that you all are doing.

But the first one is the emergency responder EHR use case, this has
already been done, it\'s already been published. It is a totally new use
case. It addresses a number of different issues around summary record
exchange. And I think that one of the things that we\'ve seen clearly
coming from this need is that a patient\'s summary record is, if it
hasn\'t already been called for, is clearly called for in the context of
this use case, as a necessary unit of information exchange for the kinds
of activities that are going on.

I should emphasize the fact that these use cases, as they\'re being
advanced from the AHIC, do tend to focus on inter-organizational
information exchange, and relationships, and interactions between
organizations, rather than things that go on just internal to a
particular organization. And I think you heard some reference to that as
messaging in the previous presentation, and what we\'re really talking
about is a lot of the interactions between organizations, and that
that\'s where many of these use cases have focused.

The next one is medication management. Oh, I should say that aside from
the summary record with the emergency responder EHR use case, also
issues around provider authentication, authorization, and credentialing,
also patient identity reconciliation are prominent in that use case.

In the area of medication management, this is a new use case, it was
called for because of a variety of different needs, but also the
importance of medications in clinical care, obviously, but also because,
for example, the certification of electronic health records needs
guidance in this regard. They have gaps in the standards of what they
want to do to certify systems in this area. And so that was one of the
inputs to the prioritization process of the AHIC. It includes activities
such as medication reconciliation, management of pharmacy and allergy
data, monitoring of medications, ordering, transmission, dispensing,
administering, and some degree of clinical decision support. Patient
lookup and matching is a component that is teased out in this area, and
one that has place in a number of different areas, obviously, in terms
of retrieval of other clinical data about a patient, in terms of
supporting clinical care, and potentially secondary uses.

The next two use cases that were approved, they\'re describing as
extensions of existing use cases. So one of the other things that we\'ve
found is that, you know, there\'s a lot of value in the use cases that
have already been done to be applied to new use case areas. And one of
these extensions is the consumer empowerment use case, which we\'re
describing as, I\'m sorry, is a consumer access to clinical information.
And the AHIC continues to prioritize consumer access to their, to
consumer data, or patient data, as a high priority for the activities
they\'re advancing. And this we\'re terming an extension of the consumer
empowerment use case, where some of that around registration data,
medication history, were already in place. But now we\'re talking about
data such as lab results as needed by the patients, conditions, list of
conditions and allergies, health problems, diagnoses codes. There are a
number of important enabling technologies in this regard, including the
management of consumer and provider information, in other words, who is
a provider for what consumer or what patient, comes to the fore.
Consumer access management, access to data, is another area that is
prominent here. PHR portability of data is important here, and clearly
access auditing. All thinking about this in the context or at least in
the context of who has had access to consumer EHR data, who as a
provider has had access to those data.

The final use case, which we\'re terming an extension to the
biosurveillance use case is one around quality. Some of the related
Workgroup issues and priorities in this regard include dealing with a
core set of inpatient and ambulatory care measures. It\'s going to start
small, that\'s been the guidance that the AHIC has advanced. The
importance of clinician access to these data, not to think of this as
reporting on clinicians, but to think of this as also having a huge
component of getting clinicians information about where they stand in a
prominent way relative to their practices and behaviors, that\'s very
prominent here. It has a reporting component to it, as well. Some of the
enabling technologies that are emphasized here include data sharing
rights and responsibilities. This is one that I think has, will have
significant import in terms of the activities of this working group,
where we\'re talking about needs for secondary use of data at times, and
who can access them, in what context, with what control, data sharing
rights and responsibilities, the storage and management of those data
sets. And it also has an element around augmenting clinical data. So
most of the work that had been done before in biosurveillance,
biosurveillance was strictly focused on using extant clinical care data
or theoretically extant clinical care data to do public health purposes.
So using EHR data to help public health. Whereas here, also in other
contexts, there\'s a need to initiate additional information
accumulation at certain times in a work flow for a clinician or a
support staff. Classic example is that some of the quality measures may
not immediately be existent in the EHR, but may need to be supplemented
at the right point in time by basically form completion of certain data.
This is an enabling technology that has been, has needs in many
different areas. And then issues around how do you get the right
questions to that point, and how do you standardize the information for
subsequent exchange after it\'s been recorded.

So that\'s a really brief run-through, and there\'s a lot of detail to
these. The AHIC had over 120 different priorities and issues that it was
working and processing in the context of this activity. So there\'s a
lot that they\'ve been, that the working groups have been feeding it to
try to do. We tried to optimize the ways in which those priorities and
issues were clumped or clustered so that they could, as many could be
done in as coherent a way possible in the next steps of the use case
process. And this is, what I\'ve just relayed to you is the process that
now exists. So that was a really quick run-through, I\'d be happy to try
to answer any questions that anyone may have relative to it, or talk
about follow-on activities and subjects, as well.

**[\>\> John Glaser:]{.underline}**

Any questions for John? Thank you, sir.

**[\>\> Marc Williams:]{.underline}**

This is Marc Williams at Intermountain. I\'m intrigued by the extension
to existing use cases. Thinking again from the perspective of our
Workgroup, and looking at what you\'ve done in terms of medication
management, looking at patient safety issues, clinical decision support,
it strikes me that this would be a place where there are some early case
examples where pharmacogenomic information could potentially be used to
extend medication management use case. The example would be a patient
with leukemia who is going to be treated, say, with azathioprine, where
for most people now looking at the TMPT gene for a polymorphism that
predisposes to aplastic anemia is done.

So the question I have for you is how do you sort of cue up to get an
extension of an existing use case, and how are those prioritized?

**[\>\> John Loonsk:]{.underline}**

A couple comments in that regard. One is I think it is very helpful to
be thinking along the lines of where can aspects and products that are
already in the queue be usable, and leveraged to support the work that
you\'re talking about here. I think that\'s a great line of thinking.

In terms of the specific of clinical decision support, I really should
qualify that relative to this context as this is really, in these
initial steps is going to have to be very rudimentary, given the status
of the infrastructure for clinical decision support in most electronic
health records nationally. If you think about this, you know, what this
is practically saying in terms of medication management, some might not
even think of as full clinical decision \-- it\'s certainly not full
clinical decision support, some might not even want to call it clinical
decision support, if you\'re talking about getting allergy information
or getting, you know, possible drug-drug interaction information, and
making it available in the context of ordering. You know, I think it
qualifies, but it\'s pretty rudimentary in some respects compared to the
grand vision of clinical decision support that some may have.

In terms of the prioritization, you know, what we\'ve been working from
is the prioritization that the AHIC working group feeds the AHIC, and
then the AHIC feeds back. I think that in looking forward, in terms of
thinking about how do you get your material on to this, it clearly is in
the importance of prioritizing, making sure that the AHIC fully
understands the importance of what you\'re articulating, and what those
priorities mean. Clearly, you haven\'t had much chance to do that yet,
but you\'re still early in that stage.

I do want to take a minute, though, to also contextualize some of what
is happening here from the standpoint of what HITSP does, and what this
overall process is doing. So we have a number of different issues going
on here with standards. I mean, some of it is having standards
available, which fundamentally is not a HITSP issue. It\'s an SDO issue.

There\'s the issue of standards adoption in technology, which, you know,
you can see as the promise down the line, when you get through this
whole cycle and you get to certification of systems to ensure that a
standard is involved, but it really goes beyond that to just the
methodology for how those standards are implemented at times in EHRs and
whatnot. And I don\'t mean to be discouraging, at all, but, you know,
having gone through this whole cycle once, when it gets around to CCHIT
there\'s a heavy consideration for what\'s existing in electronic health
records now, and what the industry will tolerate in terms of pushing
that envelope, et cetera. So it\'s not a simple equation of just saying
we need these standards, and everyone should use them, clearly. And I
know you don\'t think that, but some people who have looked at this
process, you know, have thought of it that way.

So the standards adoption issue is one that\'s \-- you know, is a tricky
one. We have, on the basis of what the national agenda is doing, really
two levers in that regard. One is certification and the other is the
federal use of these standards in terms of the executive order, and both
of those things can only accommodate a certain amount, I think. We\'re
trying to parallel them in terms of the outcomes of these activities,
but it\'s just a little sobering in terms of, you know, and I think
it\'s critical in terms of thinking about, well, what\'s the strategic
end goal here, and how do you effect that goal, and what can this
apparatus do to help with that? So just some other comments on the
prioritization, there.

**[\>\> John Glaser:]{.underline}**

Other questions for John?

**[\>\> Reed Tuckson:]{.underline}**

This is Reed Tuckson. Not necessarily a question only for John, but I
just wonder, is there a place we can go to get a glossary of all the use
cases that are floating around now?

**[\>\> John Loonsk:]{.underline}**

There is, and we would also just be happy to e-mail them out. We can
share them with the staff, and they can e-mail them out. Or e-mail the
links out to you, so you don\'t have to go get them. But we will be
happy to do that.

**[\>\> Reed Tuckson:]{.underline}**

Terrific, and finally on that point, is there a sense, has anyone taken
a stand after you sort of looked at this glossary or this bibliography
of use cases in terms of sort of, or is this part of the challenge, that
you are explicitly asking us to do now, is to see what\'s missing?
Which, what are the applicabilities of these use cases, are we seeing
things for which people really are not focused, or is it more of trying
to make sure that we can get a general sense as we listen to these very
excellent presentations of what it\'s going to take to actually
implement this vision, given the opportunities that AHIC presents to us?

**[\>\> John Loonsk:]{.underline}**

Well, to be quite honest, having gone through one round of use cases,
there\'s a lot missing. And the issue is almost, you know, it\'s what is
there, versus what isn\'t there, to be, you know, be somewhat flip.
There\'s a lot missing. What we did introduce in the last \-- this
second round in the prioritization effort was try to get feedback from
some of the other processes to try to identify priorities. So for
example, HITSP said, you know, gave feedback to the AHIC and said we see
these gaps in standards as being important to consider in the next
round. CCHIT came back and said we see needs for medication management
and transfers of care in priorities. And I anticipate that that sort of
feedback cycle, and clearly, the working groups all gave input into what
the priorities are for the next rounds, and I would think that those
processes would continue, if not expand, in the next round, as well.

**[\>\> Reed Tuckson:]{.underline}**

Thank you.

**[\>\> John Glaser:]{.underline}**

Any other questions for John? John, I\'ve got a couple, or just a couple
comments. One is regarding Reed\'s comment. I think we ought to send out
or at least link people to all the use cases, probably also target folks
to a subset of those that we think would be good models for our own
efforts to do this. I suspect there\'s probably also work in the spirit
of extensions. And to Marc\'s point, is that we point out, in addition
to our own use case development, areas of other use cases for which
there could be an extension that would leverage the work that we\'re
doing. And so the point on medication management is a good one, and
there may be other examples of that.

John, I\'m just curious, make sure I understand the sequence here. So we
come up with a prototype, if I got the terminology correct, of the use
case, we send that out for comment, handle the comments, and at that
point send it off to AHIC. So there\'s really four stages here, roughly
speaking.

**[\>\> John Loonsk:]{.underline}**

John? Just to reiterate, the approach that has been operative to this
point has been that AHIC working groups identify priorities, that the
Office of the National Coordinator endeavors to implement those
priorities in prototype use, what we call prototype use cases \--

**[\>\> John Glaser:]{.underline}**

Okay, I\'m sorry. Okay.

**[\>\> John Loonsk:]{.underline}**

\-- which are then put out for public comment. And then produce detailed
use cases, which have another round of public comment and a full
dispositioning of all comments in that regard. Those then really feed
the rest of these agenda activities, such as HITSP, and the NHIN, as
well, \--

**[\>\> John Glaser:]{.underline}**

Okay.

**[\>\> John Loonsk:]{.underline}**

\-- and other things like that. And I think it is important to think
about the NHIN in this regard, in terms of particularly some of the
architectural issues about where data are available, how health
networking can support the kinds of activities you\'re talking about. So
there are, you know, the first thing that comes to mind is standards and
standards harmonization. But there are architecture issues here as well,
and information flow issues that are important in this regard as well as
others.

**[\>\> John Glaser:]{.underline}**

So we conclude our work, we throw it into the mix for prioritization,
and we may or may not go radio silent for a period of time. We may not
be high priority, frankly.

**[\>\> John Loonsk:]{.underline}**

I think it\'s fair to say that this working group, by virtue of its
existence, should generate a use case to be considered in the next
round, alongside the ones that were not prioritized in this recent
January event.

So what I would commit to is that just as soon as we see our way clear
of these existing use cases, these three, and that\'s right now
scheduled for mid-April, that we would like to very much team with you,
to help create a use case in this area that would build on the work
that\'s already been done, be integratable into that overall construct,
but still address the high priority activities here that I think should
emphasize, you know, again, some of the themes I mentioned before,
interchange between organizations is a high priority component.

You can get it a lot that way, but, you know, you don\'t necessarily
want to focus on thinking about what\'s happening inside of a particular
organization, because that has not really been the domain that this has
been working, and there are a lot of complexities there, such as what\'s
the role of mapping or data translation, and can we really mandate that
an organization use internally certain standards, or can we really only
mandate that they use certain standards for exchanging information.

**[\>\> John Glaser:]{.underline}**

I think, John, and mindful of our time here, because we still need to
hear from Greg, I think for me, anyway, what would be helpful as we
craft the use cases is a couple of things. Above and beyond the access
to the bibliography of them and perhaps certain targeted ones, one is,
is the reiteration of the criteria that you\'ve mentioned that would
sort of boost the priority of this, so to speak. I don\'t think we ought
to distort the use case to purely cater to priorities, but we ought to
be quite mindful of them, otherwise we run some risk of fouling in the
basement for long periods of time. So that would be useful, and again,
you\'ve mentioned some of these, and as we go forward we ought to keep
those in mind.

The second thing which would be helpful to me, anyway, I\'m not sure I
know exactly what we mean when we say enabling technologies. I don\'t
necessarily need to you respond now, but one is what\'s the definition
of that? And the second, sort of related to that, is presumably over the
increased number of use cases there\'s been this growing list of
enabling technologies. And so rather than recreate or re-label certain
things as we pick things that perhaps other groups have identified as
being essential to the work that they\'re doing here.

And the other thing is not quite clear to me here is when we say related
Workgroup priorities and issues, whether those are elements of the use
case, or whether those things are things that we will mention in a use
case, but require work and elaboration which will exceed the scope that
we\'re embarked upon. So I don\'t know if all of that made sense, but to
the degree that a use case has got a conceptual structure of high
priority elements that it needs to emphasize, enabling technologies it
needs to point out, and sort of collateral or related activities, is we
make sure we know what the meaning of all these pieces are and quite how
to approach them.

**[\>\> John Loonsk:]{.underline}**

And we\'d be glad to work with you in an ongoing way on those.

**[\>\> John Glaser:]{.underline}**

I know you would, and I\'m glad to hear you say it again. I appreciate
that. Other questions for John? Doug, why don\'t I turn it back over to
you to lead us, you and Greg, on this next topic.

**[\>\> Doug Henley:]{.underline}**

Thanks, John. As we look at the March 12th meeting upcoming, as John and
I talked about it with the ONC staff, we anticipate a meeting from like
9:00 to 3:00 on that Monday. And the first couple of hours will probably
be devoted to some of these same discussions that we\'ve just had about
our important focus on creating one or more use cases, the priority of
that, how do we get that hooked into the AHIC process, and then relying
on the ONC staff to come up with the wording for that, and so forth.

But importantly, we\'ve learned from the example of the previous
Workgroups that early, as Workgroups assemble themselves, as we have
done, early in the process, trying to have a session that\'s focused on
visioning and further work plan development. So I\'ll turn it over now
to Greg Downing, to give us some thoughts and ideas about that as we
look to the March 12th meeting. Greg?

**[\>\> Greg Downing:]{.underline}**

Thanks, Doug. This is somewhat reminiscent of an exercise that we went
through here in the early days, of developing a strategy for the
Secretary's personalized health care initiative overall, I think what
we\'ll discuss with you here and hopefully frame better for the March
12th meeting or a segment of it, is basically captured as a visioning
exercise about what is really intended for the specific aspects that
this Workgroup is charged as, their draft charges, anyway, what are the
near-term and longer-term realities that one could either experience
now, in their current state of the development, and where we\'re trying
to get to, for various activities and functionalities of the content
that this information is intended to deliver.

And just to digress for a moment, the exercise that we engaged in at an
agency head level really brought together fairly interesting dialogue
about what we saw from very different perspectives, the state of the
science today, and where it\'s likely going to be in 10 or 15 years,
relative to the types of information that\'s available, and how people
will use it. And it was that strange sense of the person you sat next
to, you thought you really knew was seeing something very different in
terms of an image that emerged for our five or 10 years out, than what
we thought they may say. And so I think that one of the structures that
we think might be useful for this exercise, for this working group, is
to go through this exercise to identify some common characteristics. So
if you met the animal on the street one day you would know what to call
it, sort of thing.

And so we\'ve been thinking here about what kinds of tools we can use to
help present a structure that we develop as a group, that six months
down the line, or communicating the work of this group to others, that
we have a tool handy that sort of describes the characteristics of the
very complicated beast. And so that\'s just a general notion of what
we\'re trying to do. Some others here in the room have had some
experience of how other Workgroups have developed these, and how
they\'ve importantly used them downstream in their group\'s activities.
And I\'ve asked them to comment on this in the meeting today.

When I, when we started working on this Workgroup several months ago,
this notion of at what stage of the development of the Workgroup\'s
activities would a visioning exercise come up. We kind of punted this
for awhile to see how the dialogue was going and what kind of progress
was being made, and we think that the staging of this visioning exercise
we hope is at an appropriate time point where there\'s enough common
understanding of the challenges, to an extent that this kind of crafting
a vision would be useful for the group long-term. And we think that this
is probably about right, given the inputs from some of the others.

Kristin is here and has been working with other folks in ONC and with
some of the other members of other working groups to characterize the
status of what we\'ve developed as a template, and hopefully that might
be of some use, and we want to have a discussion with you as to what
information ahead of the March 12th meeting might be useful in how this
is set up. So if it\'s all right with you, Doug, I\'m going to turn this
over to Kristin.

**[\>\> Doug Henley:]{.underline}**

Sure, just one question, Greg. Do we anticipate that this part of the
meeting on the 12th of March will be facilitated? By some external
individuals, or whatever?

**[\>\> Greg Downing:]{.underline}**

I think they have in the past, and that was in our discussion. I don\'t
have a definitive answer for you, but we\'ll certainly clarify that
today.

**[\>\> Doug Henley:]{.underline}**

Okay, Kristin.

**[\>\> Kristin Brinner:]{.underline}**

All right, so to facilitate this we\'re going to be looking at
essentially the broad charge that will help us for the visioning
exercise, to articulate the likely changes that were going to have to
occur in the health system as it evolves into our future ideal state.

So each state of change that we identify is going to be articulated
based on things like adoption of technology, changes in delivery,
interactions between patients and the health system, that sort of stuff.
And how the evolved information is going to help us achieve our end
goals. So at the March meeting for the visioning process, we\'re going
to discuss and agree on what\'s the desirable end state. So like in
2014, what the state of the system is going to look like based on our
broad charges.

And just to remind you, our broad charges are to encourage the adoption
of clinical, useful, interoperable genetic information, analytical
tools, in electronic health records to support clinical decision making.

So we\'re going to have to figure out what our current state is, what
the mid-state is going to be, and then how we\'re going to get to this
end final state. And so we\'re going to have to identify what types of
behavior actions are going to be needed to achieve this.

So the initial state for this visioning exercise is going to be informed
by the testimony we have to date, and then the expertise of the many
thought leaders that are members of this working group. So we\'ll be
shortly sending out a draft visioning matrix that we\'ve been
developing, and it\'s a matrix that has the current, mid-state, and end
state, and then across those different states we\'re defining different
types information management that are required. And so that will be
there from the patient\'s perspective, from the provider\'s perspective,
and also potentially from a research perspective.

So again, we\'ve been working on the preliminary framework of this, and
we\'re thinking that for the patient\'s perspective the things that
might be important to the patient are the personal health record and the
family history information. In terms of the provider\'s perspective, the
important aspects could include genetic test information or clinical
decision support. And from the research perspective, that could include
both public health and basic research. So we\'re going to need to be
able to define the current, mid-state, and end state from each of these
perspectives.

And so some of the work we\'ve been doing is just to try and do an
initial environmental scan of what\'s out there and what\'s available
for each of these different perspectives. And we\'ve been filling in
this matrix, and what\'s going to be a large part of the visioning
exercise in March it\'s going to be your work in terms of defining what
the end state is, and how that\'s going to help achieve the broad charge
for the working group.

And so the Quality and Consumer Empowerment groups have already gone
through this, and there are aspects of their process that might be
helpful to us. So we could potentially send out their visioning matrix,
so you can get an idea of what they\'ve done. But again, ours will look
pretty different because we have different perspectives and different
things we\'re going to be addressing.

And so also, one thing, that we don\'t want to start with a blank matrix
at the March meeting, because I think that would be kind of chaotic, and
maybe not that useful. So maybe after the meeting, if there are people
that would like to work with me to begin to fill in what the current
state is, and what the end state should be for these broad perspectives,
that would be very helpful. And that will give people time to reflect on
that, and then can discuss it, use it as a starting point for the
visioning exercise in March.

**[\>\> Doug Henley:]{.underline}**

Any questions for Greg or Kristin at this point?

**[\>\> Carolyn Clancy:]{.underline}**

I would just make a comment that on the Quality Workgroup we found this
very, very helpful. I\'d also say we ran into a challenge which I\'d
just mention to folks as a heads up ahead of time: it is very hard to
predict timeframe. So we had some struggles trying to figure out what
was mid- and what was longer-term. But that really ultimately did not
diminish it, in fact we ended up making a summary working from this kind
of matrix that distilled it a little bit more. But I found it to be very
helpful.

**[\>\> John Glaser:]{.underline}**

Carolyn, can you comment how this contributes to the use case
development, or \-- some of these aspects are in parallel, obviously,
but their utility of this exercise that facilitates the use case
development?

**[\>\> Carolyn Clancy:]{.underline}**

I think in our case, on some level the \-- our specific charge was so
close to a use case, or these kind of opening sentences of a use case,
that I can\'t say it helped in that regard.

It certainly helped us expand what were the nuances and what we wanted
to be part of it. So for example, our specific charge in the Quality
Workgroup is that certified electronic health records will include the
functionality of reporting on quality. Well, the visioning and lots of
other activities made us realize that being able to report in the past,
it\'s better if it\'s a month ago instead of 18 months. But that isn\'t
actually all that helpful if you\'re not also thinking about real-time
clinical decision support, and so forth. So that very much helped us in
that regard.

**[\>\> Doug Henley:]{.underline}**

Carolyn, thank you for both the insight as well as a degree of caution
about timelines. Your being around the table with us probably will help
us in this process when we get to it on March the 12th, so thanks for
that.

**[\>\> Janet Warrington:]{.underline}**

I have a question. This is Janet Warrington at Affymetrix.

**[\>\> Doug Henley:]{.underline}**

Go ahead, Janet.

**[\>\> Janet Warrington:]{.underline}**

So I\'m a little fuzzy on this, I\'ve never been through one of these
visioning experiences, so bear with me here. I understand trying to
figure this out and project it from the patient and the provider
perspective. I\'m a little bit fuzzy on research, why research is
included in this. Or that if you\'re including research, it seems then
that there\'s a gap between research and the patient and the provider.
And in fact I think nationally we\'re all struggling with that gap. So
does research also include the developer, the person, the groups that
are doing test development and drug development, and actually creating
the tools? Or is research really the upstream R&D discovery research?

**[\>\> Doug Henley:]{.underline}**

Greg, your thoughts on that?

**[\>\> Kristin Brinner:]{.underline}**

Well, this is Kristin. I think both of those could potentially be
important. I think initially in terms of the actual genetic tests, it\'s
going to be the development and validation of those tests that\'s going
to be really important. So that information I think is going to be
necessary in terms of saying well, if you get this genetic test, how
important is that for your information, how much can you rely on it, and
how much do you need other evidence to make clinical decisions?

**[\>\> Janet Warrington:]{.underline}**

So it\'s research and development.

**[\>\> Kristin Brinner:]{.underline}**

Yeah. We can, you know, none of this is set in stone. If you think
there\'s a more appropriate term for the perspective, of course that\'s
something we\'ll discuss and be willing to change.

**[\>\> Janet Warrington:]{.underline}**

That\'s very helpful, thank you.

**[\>\> Doug Henley:]{.underline}**

Any other comments? All right, John, to you for public comment, and then
adjournment.

**[\>\> John Glaser:]{.underline}**

Fair enough. So let me just see if there are any folks who have been
listening in from the public who have questions or comments you\'d like
us to hear.

**[\>\> Jennifer Macellaro:]{.underline}**

This is Jennifer, I just put a slide up. If anyone has already dialed
in, they just need to dial star 1.

**[\>\> John Glasser:]{.underline}**

Okay, thank you, Jennifer. Any questions, comments?

**[\>\> Greg Downing:]{.underline}**

John and Doug, this is Greg. I\'d just like to thank you both again.
We\'re headed into a fairly rapid timeframe in between meetings here,
and I think for all of the members that have joined today, we\'re very
appreciative of the copious input that we\'ve had along the way, here.
And to those who can join on the 12th, I think the face-to-face
interactions, I think if at all possible, would be very valuable. And
please send us comments in leading up to this, that we\'ll get you
details about facilitation of the meeting and give you as much structure
as we can to come to this well in advance. So on our behalf, we really
appreciate all of your efforts in getting us to this point.

**[\>\> John Glaser:]{.underline}**

And I know Doug and I are, Greg, back at you, as they say. Nicely done
on the part of the ONC staff. We both appreciate people spending their
time and busy lives on this phone call and the discussions to come. I
think it will be a remarkably interesting time, and particularly with
Carolyn\'s background on prior experiences, this should be fun and very,
very interesting. So again, thank you all.

I don\'t know if there\'s any last minute comments or questions before
we adjourn, and send you back to whatever you were doing before this
call.

**[\>\> Jennifer Macellaro]{.underline}:**

I don\'t have anyone on the phone today.

**[\>\> Campbell Gardett:]{.underline}**

Greg?

**[\>\> John Glaswer:]{.underline}**

Anything else before we adjourn?

**[\>\> Campbell Gardett:]{.underline}**

Can you hear me, Greg?

**[\>\> Greg Downing:]{.underline}**

I\'m sorry?

**[\>\> Campbell Gardett:]{.underline}**

Hi, this is Campbell Gardett. Greg, I don\'t know, did you mention the
March 23rd event, do you want to tell people about that?

**[\>\> Greg Downing:]{.underline}**

I think you just did. Why don\'t you go ahead.

**[\>\> Campbell Gardett:]{.underline}**

Well, the Secretary is going to speak at a meeting, annual meeting of
the Personalized Medicine

Coalition, on March the 23rd. So that will be kind of a landmark
launching point for us. Just wanted people to know about it.

**[\>\> Sheila Walcoff:]{.underline}**

And this is Sheila Walcoff, I just wanted to reiterate that more
information will be going out on that shortly, but I think it would be,
if people are able to attend that, a great opportunity to hear from the
Secretary directly on his interests, and very strong support of the work
that we\'re doing.

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

Terrific.

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

Thank you.

**[\>\> John Glaser:]{.underline}**

Any other comments, information? Well, Doug, if it\'s okay with you, how
about we adjourn these folks and look forward to our next conversation,
and particularly look forward to seeing as many of you as we can on
March 12th.

**[\>\> Doug Henley:]{.underline}**

Great.

**[\>\> John Glaser:]{.underline}**

Thank you all.