American Health Information Community

Personalized Healthcare Workgroup Meeting #6

Thursday, June 7, 2007

**Disclaimer**

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

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

Okay, we\'re ready to get started.

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

Thank you, Jennifer, and welcome, everybody, to the 6th meeting of the
Personalized Healthcare Workgroup. As a FACA committee we\'re operating
in the public. The minutes will be made available on the AHIC Website
following the meeting. And also the public will have an opportunity to
make a comment at the end of the meeting.

Let me just remind members to please introduce yourself prior to
speaking, and also when you\'re not using your telephone, if you could
mute it, please, for \-- it helps reduce the static.

Let\'s let Jennifer introduce the members on the telephone and then
we\'ll go around the room and introduce the people here.

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

Sure. On the phone today we have Mollie Ullman-Cullere from the Harvard
Partners Center for Genetics and Genomics. Armando Oliva from the FDA.
Doug Henley from the American Academy of Family Physicians. Lisa Rovin
from the FDA. Kathy Hudson from Johns Hopkins. Betsy Humphreys from the
National Library of Medicine. Sandy Aronson, from Harvard Partners.
Beryl Crossley from Quest Diagnostics. Jean Slutsky from AHRQ. Marc
Williams from Intermountain Healthcare. Mark Rothstein from the
University of Louisville. John Glaser just joined us from Partners
HealthCare. And Grant Woods from Intermountain Healthcare. Did I miss
anyone on the phone? Okay.

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

Great. And here in the room we have \--

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

Kristin Brinner.

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

Greg Feero.

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

Alan Guttmacher.

**\
[\>\> Mary Beth Bigley:]{.underline}**

Mary Beth Bigley.

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

Becky Fisher.

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

Paul Cusenza.

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

Sumitra Muralidhar, here on behalf of Kupersmith from the VA.

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

And thank you and I think I\'ll turn it over to the chairs, doctors
Glaser and Henley.

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

Thank you, Judy, and welcome, everyone, for those on the phone as well
as those participating in person in D.C.. Thanks for your continued
commitment of time to this important effort. We hope today to not only
with the first couple presentations to provide you with some additional
background information that helps inform our decision-making process as
we go forward, but also to hear from the excellent work done thus far by
two of our subgroups and obviously get into some action items from the
Workgroup that will be hopefully moving forward for the AHIC
consideration on July the 31st. On behalf of John Glaser and myself,
again welcome, everyone, and John, any comments that you have as we
begin?

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

None at all, Doug, let\'s fire away.

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

All righty. First on the list is approval of our minutes from the May
15, 2007 meeting that we had. So I would ask anyone now if they have any
comments, objections, or additions or edits to those minutes.

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

This is Betsy Humphreys.

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

Okay, Betsy.

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

I found a couple of slight errors, like the American College of
Pathologists is really the College of American Pathologists, so I\'ll
e-mail those to Kristin.

I did have one question about what is meant at the top of Page 2 when it
refers to characterization of the validity and utility of use of family
medical history in making medical decisions. And I wondered whether,
what we meant by that as longer term goal. Is it characterization of the
validity or determination of that? I mean, are we going to measure it or
are we going to evaluate whether there currently is some, or the extent
to which it is there?

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

Point well made. Let me ask the staff and/or John if they have any
comments about \-- or the Workgroup for that matter about the word
determination versus characterization.

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

My sense is determination is a better word.

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

Yes.

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

This is Kristin. We should double-check in our priorities. I don\'t know
if we were so prescriptive as to say either characterization or
description. It might have just been broadly information on the validity
and utility of the information. We can double-check back in the
priorities because I think we do have the phrase there, and correct it
based on the priorities document.

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

I may bring this up again when we discuss the proposed letter, because I
do have a question as to whether this is a research \--

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

I think it\'s talking about infrastructure incentives to use PHRs,
personal health records to, and the health record I think you would
characterize it, not determine the validity. I think it\'s probably
written correctly as it\'s currently phrased.

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

I just pulled up the priorities and I have them in front of me now and I
think the way that I have it in my priority document was inclusion of
information that describes the analytical validity, clinical validity,
and clinical utility of genetic and genomic tests in the EHR. We can
correct it to read that way if people feel that\'s appropriate.

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

That was the genetic and genomic testing, Kristin, that you just
referred to. How about the family medical history part?

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

Separate clause, saying it\'s the utility of use of the family medical
history, and I think that\'s probably looking at the longer term
direction where as time progresses at one point we may have more
information in genetics, but certainly family history will always be
important.

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

In the priorities it also reads characterization of the validity and
utility of use of family medical history in making clinical decisions.
So it does read that way.

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

Okay.

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

It will probably come up when we\'re going over the recommendation
letter because I still am not sure whether we actually have to do R and
D to prove this. We all know it, but the question is do we actually have
a lot of data about how this actually happens and how it actually
affects care and primary care now? And I looked for those papers and I
couldn\'t find them.

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

I think \-- and didn\'t \-- this is Lisa at FDA \-- didn\'t some of the
distinction come from the discussion about the scope of this working
group being getting the information needed by clinicians into the EHR,
but not actually making the background determination itself?

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

Correct.

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

This is Marc Williams. I mean, I think that it\'s fair to say that
there\'s not a lot of data but there are some data around this, CDC\'s
work in conjunction with Maren Scheuner I think has definitely
demonstrated certain areas where family history can be used at the very
least for risk stratification and there\'s some data that\'s currently
in a manuscript preparation from Utah Health Family Tree looking at
changes in health behaviors related to family history information or
from the Utah family health tree project. There are some data that are
out there but it\'s not a terribly robust data set.

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

Well, it seems like I\'m hearing more consensus that we leave the second
line at the top of Page 2 as it is, consistent with our previous work.
And then when we get to our last item on the agenda about the letter to
the Secretary, perhaps we could have some additional discussion then
relative to that content.

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

Sounds fine to me, thank you.

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

If you\'ll let us know about those other edits as well, Betsy.

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

I just e-mailed them.

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

All right. Any other comments on the minutes from May the 15th? All
right, hearing none, we will consider those approved. And we will then
move on to a presentation by Andrea Ferreira-Gonzalez about laboratory
work flow automation at the Virginia Commonwealth University. Andrea?

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

Thank you so much. Thank you for allowing me to share some of our
experiences in these areas of genetic test in the last actually 15
years. Could I have the next slide, please? Next slide?

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

There may be a slight delay. You can just continue and it will advance.

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

Before we start talking specifically about the testing that we are
currently doing in our laboratory and how we managing the workflow of
information, let me give you a little background about our institution.
The Virginia Commonwealth University Health System is composed of three
different entities. The Medical College of Virginia Hospital, the
physician practice, and the medical school. The MCV Hospital has over
21,000 \-- 31,000 admissions a year, and about \-- a little bit less
than 200,000 patient days, and average daily census has increased
recently to 550. We are a tertiary care level 1 trauma facility with a
very large core of faculty physicians and we cover over 200 different
medical specialties. We are located in Richmond, Virginia, which is the
capital of Virginia, and we are an inner city hospital with about 25
percent of indigent care patients that attend our institution. Next
slide.

The molecular diagnostics laboratory, it is housed, or it's actually
part of the department of pathology, which has an academic function and
a clinical support function. And we have here a picture of parts of the
laboratory to just show you some of the instrumentation that we
currently have. Next slide.

The laboratory, it is part of the department of pathology and we have
two faculty working, myself and Dr. Dumur, which has been, devoted
significant of our time to expression arrays and we have a variety of
different individuals working in our laboratory that have either
clinical functions or either translation of research, or assay
validation. We also have the tissue acquisition system for the cancer
genomics project in our institution. We have about 6,400 square feet of
space dedicated to molecular diagnostics. Our area, our laboratory is
more of a comprehensive or core laboratory that encompasses not only
genetic and oncology testing but also infectious disease. Next slide.

I have shown here the test menu that we have. And the reason that I
wanted to show you the test menu is to actually show you the differences
of testing that are currently available at laboratories like ours. We
have a number of tests that use kits, IBD-manufactured kits, that have
been either FDA approved or cleared, and go from a number of those for
infectious disease but we also have for genetics and for oncology like
Her2-neu by Fish or the Factor V Leiden and Factor II Polymorphisms. We
also have a good mixture of researchers-only kits that we currently use
for different research projects in the institution. Next slide.

But I would say it's a large amount of testing that we also do, it\'s
part of laboratory developed testing that either we completely develop
in-house or we actually acquire what\'s called Analyte Specific Reagents
that we put together into the test to have an in-house developed assay.

As you can see here our testing is divided in four different areas. We
have infectious disease and mainly the infectious disease is to support
the transplant program. Now, the solid organ transplant program and the
bone marrow transplant program that we currently have, very active
programs at VCU Health System. We also have for oncology/hematology and
it has (inaudible) a different tests and technology that we use. And
then human genetics and identity testing. Next slide.

In this slide I\'m going to show you some of the test utilization over
the years at the Virginia Commonwealth University. I joined the faculty
at VCU in 1995 and started doing testing in this institution. You can
see very dramatically from this graph there has been a continuous
increase in the utilization of this technology. And I think this is not
only in our institution but nationwide. As you see the growth from 1995,
we were only doing hepatitis C viral load, to 2006 the last bar, there
has been significant increases. But as the increases have not been only
in the amount of testing that we do in a particular test, but we have
continued to grow in the complexity in the, meaning that there are a
large number of different tests that now we\'re offering, with not very
high volume but still add to the entire volume of the laboratory.

As you can see, the number of bars with different colors start to show
up in 2001 and then continue to increase over the years. And this past
year we had a significant increase that has pushed us to work with
automated nucleic acid extractors and other kinds of instrumentation to
be able to cope with some of the volume that we are perceiving. But I
think the last bar, the 2006, is very striking to see the amount and the
number of and different colors we have which represent different
testing. With that in mind, each of the different bars and different
color represents a challenge, too.

And if we go to the next slide, I have actually extracted the testing
that we do for inherited disorders and oncology. And we\'ve also seen
that increase in the last year and here it\'s even more dramatic the
number of different colors that we see over the years. Again, each of
the different tests that we have here will represent a challenge not
only to maintain the quality but also to manage the information of the
work flow through the laboratory. Next slide.

So as we go through the growth, which have been very difficult for us to
cope with, we have to start looking at venues or ways to move the
information in an electronic form through the laboratory. In this slide
here, what we have, it\'s a pictorial of the process of testing from the
drawing the specimen from a patient, you have a tube of blood in your
left-hand side, to actually posting the results of the report into
Cerner PathNet on the right side. As you can see, there\'s a significant
amount of steps that occur through the entire testing process. And on
top of the different steps there are a number of different platforms. As
you can see, there are different kinds instrumentation, the nucleic acid
extraction that is shown by the little columns in the lower part of the
slides shows the manual extraction versus the top one which is automatic
extraction, and then during amplification and detection there are very
number of different platforms that can be used. And this is only just
representation only three of we currently have available to us. What I
wanted to show you is the differences of output of the data that we have
to handle. And then what do we do after that. Next slide.

What I would like to go over, as we speak, we discuss some of the
genetic testing in the laboratory, is exactly what information is it
that we need to move and how actually occurs throughout the laboratory.
And I chose a very simple example and we\'re very fortunate to have the
next speaker, Michelle, that is actually going to talk a little more
complicated issues, which is sequencing. But I think there\'s some
commonalties in some of the issues we have for the very basic SNP,
single nucleotide polymorphism detection to a more complex testing such
as sequencing.

Why don\'t we walk through the Factor V Leiden and where we\'re going to
detect a single nucleotide polymorphism through melting curve analysis.
And you can see in the diagram that I have diagrammed the different
steps of the testing process. From sample collection, and after sample
collection it moves into the laboratory and then the different steps in
the laboratory that you have to do nucleic acid extraction, to
amplification, data analysis and you can see the melting curve analysis
which are the curves in the middle of the slide. And then interpretation
of that data and how we report it. I think what is important to see or
discuss also for this group is the amount of data interaction. In our
case, we go, use data transfer from either our informatics system,
Cerner PathNet, to our molecular diagnostics Access database, which is a
laboratory-developed database that allows to work or capture all the
information necessary for the testing, and how we create flat files that
then can be uploaded into the instruments and how we extract the data
from the instruments in the form of flat file, that then we manipulate
through macros in different formats to then be put back into the patient
report and then moving to the electronic medical record. Next slide.

**\
**So as you can see, there\'s a number of interactions that we have
through the flat file interfaces. In our institution we have Cerner
Millennium for the electronic medical record, for the pharmacy,
radiology, and the laboratory information system. So what we decided to
do at that point is actually interact with PathNet Helix through the HL7
interface that will down load specific information into our
laboratory-developed Access database to be able to handle the volume of
work and the complexity. So as the specimens are drawn and brought into
the central processing of the laboratory, and information is
electronically captured through the Cerner product, once the tubes of
specimens are bar code read into our area or laboratory, a file is
created that extracts demographic information on the test ordering
information that is brought from the Cerner down to our molecular
diagnostics database. And again, it's through an HL7 interface. The
issue that we also work with, that is a major disadvantage is that we
return the information back to Cerner to be put in the electronic
medical record of the patient as a block text which creates significant
problems down the road. Next slide.

As we go through the testing process I\'ll show you how we actually
download that information. And in here, we have accessed a particular
specimen by reading the bar code and creating the file and that file
will automatically populate into our Access database and you can see how
the information is transferred. There are major issues with this
transfer sometimes in whereas it doesn\'t work or there are problems
with the data that gets corrupted and creates major problems trying to
bring that information into our own database. Next slide.

Our Access database also allows us to create work sheets that organize
our testing and as you can see here we can do queries to our database to
select. In this case we\'re going to discuss Factor V Leiden and we can
select how many patients that have outstanding testing that needs to be
done to start creating work sheets for the technologists to start
working. Next slide.

As it creates these work sheets for the technologies, we can print up
work sheets so the technologist can go to the freezer, refrigerator pull
the specimen, but also creates a text file with information that will be
also uploaded into the nucleic acid extractor to actually know where to
put each of the different patient specimens, and so forth. Next slide.

This work sheet also allows the technologist to have a little protocol
but here we start capturing quality control data. The MagnaPure lots in
the technology doing and so forth. After the extraction of nucleic acid,
we also have to load the carousels and in your right-hand side of the
diagram here you have a picture of a LightCycler, which is an instrument
that we currently use in the laboratory, and in front of the round
instrument there\'s a round carousel and that\'s where we actually put
the tubes. We have to know after we have extracted the nucleic acid,
where do we gonna put each patient in that carousel? So we again create
a flat file that is taken out of the Excel \-- of the database to be
able to keep track of where the patient is located throughout the entire
testing process. Next slide.

It is important to mention that when we design our entire work flow
informatics system that we actually use as a template to know minimum
information that we needed to capture, we looked at the College of
American Pathologist's general checklist and the College of American
Pathologist's Molecular Pathology checklist to make sure that we were
capturing the minimum amount of information required when the CAP was
coming to do our biannual inspections to be certified that compliance
was clear.

After the samples are put in the instruments there\'s data that is
generated in the instruments and here you can see a file and I hope you
can clearly see some of the information in this file. The instrument
puts out a melting curve analysis and you can see that diagram with the
curves and that diagram actually can extract melting temperature peaks
that then we can use for the interpretation of the test, and that\'s the
data that you have in your left-hand side corner. In there you\'re going
to have the name of the patient that first of all is the capillary or
tube where the patient is located, the name of the patient and you can
see the identifier. And then you have an area but also you have it
melting temperature, TM number one, and then you have area two and TM
number two. These peaks allow us to know the patient is our homozygous
normal, heterozygous or homozygous abnormal for these particular single
nucleotide polymorphisms. Next slide.

This data then is extracted out of the instruments with flat files that
then we can upload into our database through the use of Excel. In Excel
we have developed some macros that allow us to put that information in
that particular specific file, or column. As you can see in this file,
you have the first column again the capillary that the patient was
placed, the DNA number, the identifier that we have here, and so forth.
Then you have the melting temperatures in the last, before to the last
one column, you can see two sets of temperature. And we have a macro
that identified if you have two different set of temperatures, and if it
falls within a specific window of different temperatures, we can desire
an interpretation, either you have evidence of Factor V Leiden or you
don\'t or heterozygous and so forth. Next slide.

This is actually uploaded into our Access database and once uploaded
into our Access database it allows to us create a message, a block
message \-- next slide.

Block message, we bring the file into and then it will populate a
specific patient information into the Access database and then we fire
back to Cerner a block message through HL7 that allows to populate these
into the particular location of the electronic medical record. We also
have specific log-in security to make sure the proper people know how to
do that. Next slide.

And after that data goes back to the electronic medical record, you can
actually go back and pull the report and after clicking a specific
result for that particular patient it will open up a window and show a
more descriptive final report for that particular patient. Next slide.

One of the major challenges that we\'ve seen in the last year is our
continuous growth. Not only our continuous growth but also the amount of
number of different tests that we\'re bringing into the laboratory. As
you can imagine, Access database is something very primitive and not
very stable. So we needed to find something more stable for us to
continue to work and expand our testing and also to capture quality
control information within all the database that we are working with, in
the same place. So we started an agreement with Cerner to be a better
partner to look at some of their product, specifically Millennium Helix,
which is a solution for molecular diagnostics and working in partnership
with them to try to customize it for some of our current needs and maybe
needs for other laboratories. So we started a Helix implementation
program about a year ago and where we spend a fair amount of time doing
the design and that\'s where we have actually invested most of our time.
And then developing what we call the order catalog. And here when we
developed the order catalog, we use the clinical bio-ontology concept to
start mapping those concepts to our order catalog. Can we go to the next
slide?

And we heard from previous presentation the last meeting about the
clinical bio-ontology, two major features that were very important for
us in this Helix Millennium were scientific notation, that is important
not only for infectious disease but also for oncology. In the case of
monitoring patients, receiving (inaudible) for chronic (inaudible)
leukemia treatment where actually we have a numeric value with
scientific notation that we need to bring back to the clinician.

In here we have a diagram of the Millennium Helix solution and here what
is diagrammed is that this solution, it\'s composed of three different
modules. The module one is a protocol and this one allows us to document
work flow organization, quality control, and actually to document a
little bit of the raw data. Through the use of this protocol tool, we
can actually generate flat files that we can extract the information to
make work lists or even directly upload that flat file into the
instrument. And at the same time as we generate the data from the
instrument, we can also create the same type of flat file that can be
uploaded back into this protocol, and that allow us for this process of
documentation. The next two, which are the enter genetic findings allow
us to start producing results that would allow us to generate or create
reports. And depending upon the type we do, we will use the enter
genetic findings to automatically generate a report that then will be
interfaced to the Cerner electronic medical record. Or in the case of
more complex testing, for example, such as sequencing, you can actually
use the third tool, which is the case integration.

During the using of the protocol tool, we can have a little bit of
interpretation started. But once we finish the protocol, data is moving
to the enter genetic findings, we can develop template reports where
values can be brought in, which could be numeric or text interpretation
that then would allow to us generate the report and go back to the
electronic medical record. On the other hand, when we need a little bit
more involved interpretation of that particular data, and more specific
to each of the cases, you can use the case integration where you can
also have a template-based but you also report these results. Next
slide.

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

Andrea, this is Doug Henley. I wanted to give you a heads up about time.
We have about six minutes left and I want people to have a chance for
some Q and A if possible. Just a quick heads up.

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

Okay, next slide. We have already discussed the clinical bio-ontology at
a previous meeting but I just wanted to give you a quick view of what
the clinical bio-ontology looks like. You\'re going to have \-- next
slide.

You\'re going to have a table here where you\'re going to have the
nucleic acid variant. The next column is the amino acid variant and the
third one is actually how we map to the orderable concept. This becomes
very important because we have specific nomenclature, standard
nomenclature to identify what we actually test. But we can display to
the clinician the orderable concept that they can actually relate to. We
started to put some information of the nucleotide variants that we are
trying to interface with the clinician and they don\'t really understand
the nomenclature. So it\'s very important to work with something that
they actually understand. Next slide.

Let me give you a overview, what will the process be when we bring Helix
Cerner. Once you do the order of the test \-- next slide \-- you can see
here that you can electronically order any of the tests and you can even
add some information about the clinical condition once a specimen is
collected and brought back to the laboratory and through the use of
unified case manager, one can start managing all the testing
information. In here you can see two patients that are described here
and you can see that the Factor 5 Leiden has been ordered and describe
the number of steps that need to be done. Next slide.

As you can see, there are some of the concepts that are more dark than
the other ones. It means they are prerequisite to the next step. The way
we can handle the work flow is through the generation of work lists, and
\-- next slide \-- you can see we select patient that need to be
extracted for the Factor V Leiden and after we have selected those \--
next slide \-- we can create a protocol. And this protocol will bring
the specific patient that we want to do or run in the laboratory. Next
slide.

And as we create the protocol, you can see here a little different
patient and as you select those patients it will create what's called an
output container and this in the lower part of the slide. And you also
start capturing, in the same mode, quality control data such as catalog
\-- I\'m sorry. QC, expiration dates, lot numbers of the different
reagents. As we create this output containers \-- next slide \-- it will
allow to us create files, flat files that we can export out to the
different instrument that we need to use. And in this case we\'re
extracting not only Factor V Leiden but three other tests at the same
time. And then we\'ll be able to match the tests down the road. You can
see here an example \-- next slide \-- the file been created to be
exported to the instrument. And then how that actually creates also a
document that the technologist can print out and bring to the
refrigerator or the specimens. Next slide.

And as they go throughout instrument, again, the same process, the
protocol is finished and you can put all the quality control information
and also the DNA number that allows for long-term storage. Next slide.

And after we do that, we complete the protocol and we need to move to
the next protocol, which is the amplification and where we also need to
document what are we going to do. And again we create work sheet or work
list in this case Factor V Leiden we have already selected two patients
we want to do. Next slide.

As we selected these two patients, again we will select which of the
patients need to be amplified and we can start capturing the information
in here. Notice on the upper right part of the screen that there\'s an
area for comment, I don\'t know if you can read that clearly but that
information goes across a different protocols, if you want information
needed for interpretation like the sample was (inaudible) as it came
through, that information will go across protocols which is the
important for some of the interpretation down the road. Next slide.

As we selected which patients will be amplified we create a spreadsheet
and the spreadsheet will contain all the information that will be used
to create a flat file to be uploaded into the LightCycle instrument.
Next slide.

As we go through that extraction of the file, and then we actually
amplification, we will extract similar files I showed you earlier and
that file is uploaded into Cerner here \-- next slide \-- populating the
different areas of the particular work sheets that we will use for very
early resulting and very early interpretation of the results. You can
see here now that the patient information is still there in the bottom
part of the slide, but now we have melting temperatures, peaks for each
of the two peak areas, and we have a little bit of a genotype. We have
areas to look at the QC, as the last column shows, that we can look at
the raw data and accept or not that they have passed the QC. It\'s a way
to document everything in the single place. Next slide.

Once this is done, the protocol is finished \-- next slide \-- and
everything has passed QC, then we bring this into enter genetic findings
where we do the final interpretation and it can be, the review can be
done by different individuals and actually get ready for release to the
electronic medical record and you can see here that we have again the
concept for the Factor V Leiden and we have the raw data information
there and the interpretation of that data. Next slide.

We also \-- this is showing you a little bit of information of how the
data is actually looked at in the, when you explode the field of the no
evidence of Factor V Leiden for that particular patient it will actually
explode and show you more specifics about what nucleotide and what
technology has been used \-- next slide \-- which is very important for
the clinician to know exactly what are the limitations of the test. And
then that information is verified by different individuals and goes back
\-- next slide \-- to the electronic medical record where the clinicians
or the health care provider could actually see the data. You can see
here in a flow sheet and where you have the particular patient for that
particular encounter you can see that we\'ve done the result and you can
click on that evidence and again it will explode and give you more
information about it. Next slide.

This is showing you about that. So I think at this point I will finish.
And maybe there\'s some questions, I will be happy to entertain those.

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

Thanks, Andrea, very much. I\'m impressed by the earlier slide that
showed the huge volume increase that you\'ve experienced in the last
four to five years as well as the complexity. Questions from the
Workgroup to Andrea? Comments or observations?

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

Hi, Andrea, this is Steve Matteson from Pfizer. The work that you\'re
doing, is it specific SNPs that you\'re looking at or a whole genome
scan?

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

Like I said, this example is very simple testing. An FDA cleared
product, for the Factor V Leiden, single SNP.

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

Okay.

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

This is the basic, basic testing and we still are trying to find ways to
capture that data electronically. As you can see, we cannot directly
interface with the instrument to move that data. So as we go in the next
presentation which is a lot more complex type of testing and that where
we are hoping to be very near future, we still need to address very
basic issues.

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

Yes.

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

Some of them are common to the different system but it\'s still they\'re
very basic questions.

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

It's the electronic capture of that information from the instrumentation
that\'s the bottleneck at this point in time.

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

Because I will say as you start importing and exporting flat files and
there\'s some corruption of the files and sometimes you don\'t realize
that there are corruptions of the files. If we can move into the
instruments, of the manufacturers of the instruments can accept HL7, for
example, and where you can do a direct interface with those instruments,
will be much better served.

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

Yes.

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

Thank you.

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

Other comments or questions?

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

This is Armando Oliva, FDA. It's still not clear to me, exactly clear to
me that that final report on your last slide, how does the provider
actually access that report? Do they have to \-- is that report
incorporated into the electronic health record? Or does the provider
have to log on to a separate system? And \--

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

Yeah, I mean that\'s a very good question.

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

And is the report itself a text field or any of the \-- or any aspects
of the report actually coded?

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

Well, when you saw the flow sheet, actually when you go to the
electronic medical record, there are, you can see the laboratory results
for patient and when you log in to that particular patient from anywhere
in the hospital and the clinics through the electronic medical record,
you can actually access that flow sheet that I just showed you. And when
you see the encounter, and where there was a specimen collected for
Factor V Leiden, and when we put the results up, it says that we have a
very succinct result which says, for example, no evidence, or
heterozygous, or homozygous for the Factor V Leiden. When you double
click on that particular square, then the final report with all the text
comes out. So this, there\'s \-- part of that there is a text but
there\'s also the particular field that it\'s a field that can be used
to run different scripts \--

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

So the \-- so if I understand you correctly, the result is incorporated
into the electronic health record and the name of the test and the
result being negative are coded and then there\'s another free text
field that contains the details?

**\
[\>\> Andrea Ferreira-Gonzalez:]{.underline}**

That\'s correct.

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

Okay, thank you.

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

Sounds like somebody put us on hold and we\'re getting some Muzak music.
But Andrea, thank you very much for your presentation. Excellent work.
Let\'s go now to our next presentation about sequencing-based genetic
test and Mollie Ullman-Cullere is going to give that presentation for
us. I think we have the slide show up on the screen. Mollie?

**\
[\>\> Mollie Ullman-Cullere:]{.underline}**

Yes, thank you. I am from the Harvard Partners Center for Genetics and
Genomics and I\'m going to talk about sequencing-based tests and this is
another category on your genetic testing matrix that was passed out
earlier, and like the previous speaker I\'m going to be addressing
laboratory automation and how we structure the results and send it into
our electronic medical record. Next slide.

Partners HealthCare is actually \-- has many assets, including a large
network of physicians and patients. This is augmented with training and
education programs as well as rich informatics infrastructure and a
discovery engine that feeds discovery into clinical care. Next slide,
please.

Harvard Partners for Genetics and Genomics is actually a joint venture
between Harvard Medical School and Partners HealthCare and led by Raju
Kucherlapati. Our mission is to transform medicine through the
application of genetics and genomics and our I-team is actually a joint
venture between HPCGG and PIS, with the collaboration with Hewlett
Packard. Next slide.

A closer look into our laboratory, we have a number of expert areas for
which our clinical lab is able to leverage as tests go into a clinical
offering. So for instance, I\'m going to speak about sequencing-based
tests today, but we also do genotyping-based tests as well. Next slide.

And here you see the laboratory for molecular medicine and how it will
leverage the infrastructure that currently supports both research and
then, as they move into a clinical offering, clinical environment as
well. Next slide.

If we look at common practice in the molecular diagnostic laboratory,
typically a patient sample arrives in the molecular diagnostic lab and
quite quickly it\'s translated into highly structured electronic
representation. And then as this data is summarized and translated by
the genetic counselor and geneticist to the clinician, you have a
transmission to the medical record that actually loses this structure
and it\'s organized inefficiently and is not leveragable by clinical
decision support. This was our laboratory a couple of years ago, until
we started working closely with them, and I\'ll be talking through those
results. Next slide, please.

Let\'s look at our analytical laboratory flow. First we show that on the
left-hand side you have the patient, the patient may have one or more
specimens that are submitted to the laboratory. And one or more genes
might be sequenced, comprising one or more regions of the amplification.
For some of our more complicated tests, this might mean a resulting of
400 trace files that might be needed to be worked on iteratively as you
might have some files that don\'t pass QA/QC analysis or you\'ve
identified a variant that needs reconfirmation. So if we look at a
patient that is going to be tested for EGFR for pharmacogenomic
guidance, when they have non-small-cell lung cancer, then a cancer
biopsy as well as a blood sample will be sent to the laboratory. So we
have one patient, two specimens, each is a specimen which will be
sequenced for one of their genes. If a variant is identified in the
cancer specimen, a comparison will be done between the genetic results
on the cancer tissue as well as the blood sample to determine if it was
an acquired or inherited mutation. Next slide.

And as we move into our clinical infrastructure as you see here, we now
have the sample coming into the laboratory and being processed through
the testing environment, incorporation and integration with instruments,
a pickup of those trace files, that are available then to be fed into
the bioinformatics pipeline. Reviews are supported, as I mentioned
earlier, this is an iterative process, the results are sent into the
genetic \-- the geneticist who does prepare the report. The report is
sent through our messaging systems and into the electronic medical
record. Next slide, please.

Let\'s take a look at this laboratory process. On your genetics testing
matrix, again, this will be the analytical portion. Here if you could
imagine the complexity of managing this work flow through electronic
data files that might be managed in file and folder structures where
only naming conventions help you manage the work flow through the
system, you can see the complexity in get the right results to the \--
the right results for the right patient to the right clinician in a rich
structure that they can be leveragable is really an insurmountable task.
In working with the laboratory we designed a system to work with this
process. Next slide, please.

I\'ll be taking you through several screens to show the major concepts
of this system. Here you have the case management system and this has
the cases and the tests that are going to be performed on the patient,
we keep track of the stage and laboratory work flow in processing and in
particular really how many portions of those sequenced regions are still
left to receive results on. Next slide, please.

Because our testing process can take a number of weeks for the very
complicated large tests, we do also provide internal security for the
masking of patient identifiers if the sample is being viewed by the
sequencing experts, where if it\'s being used, viewed by a clinical
technician, those patient identifiers are present. Next slide, please.

Here\'s a view where we are actually configuring the instruments, and in
this case it\'s a 3730. It would be nice if these instruments did have a
nice API for which to configure this. However, we are able to do it
through the automatic generation of the configuration files, and
subsequent upload of the raw data from the instrument into our system.
Next slide, please.

We not only have support for a semi-automated sequence analysis for
identifying trace files that might need to be run due to QA/QC issues,
but also identification of files that have a variant for a particular
attention to be paid there. Additionally, our system does need to
support a manual review process for the trace, so that\'s this slide you
see here. Next slide, please.

And finally, this slide presents an overview of the functionality that
we found important in collaborating with our geneticists, functionality
that they\'ve expressed needs to be present in the systems. And as you
see here, our automated sequence analysis is an ongoing process. Next
slide, please.

And now as we move into the post-analytical phase, we see right here
it\'s the creation of the report and preparing the structure to be sent
to electronic medical record. Next slide, please.

We have here a genetic test report. And as you can see here, we\'ve
essentially taken this textual content that does have repeated
formatting, and areas represented where a reader or expert might be able
to identify standards that would exist in the clinical community like
gene nomenclature and the like. So what we\'ve done is we've actually
coded the test, coded the indications, the indication class, and we\'ve
structured the DNA variants according to nomenclature standards, coded
the overall interpretation and link this to methodology as well as
coding references we hope to be able to leverage through further
integrations in the future. Next slide, please.

And here\'s a screen where you actually see that the results of variants
identified have been communicated into our reporting system. A lookup
has been done in the knowledge base and the clinical significance of
those variants is displayed. If this happens to have changed, this is
editable by correcting in the knowledge base at the time of reporting
but again structure is maintained and the benefit of that curation is
leveragable for all future reportings on that variant. We also have
default interpretations of the textual content that will be loaded and
associated at the time of reporting. This is freely editable by the
geneticist, as it does not impart structure that will be leveraged by
clinical decision support, but is simply the textual portion of the
report. Next slide, please.

As you see here, when we\'ve generated the report and inserted it into
our reporting system \-- or inserted it into the system that will send
it in a HL7 message to the electronic medical record, the geneticist is
able to view both the textual report through one tab or by flipping to
the note section. They\'re also able to view in a human-friendly
readable format, the structured results as you see displayed here. Next
slide, please.

Here in our reporting system we\'ve found, or the geneticists have
actually determined, that it\'s extremely value to believe collect
statistics on reporting. Here you see that although this is from our
testing system, so the data is not accurate, we are able to collect the
frequency of times that the variant has been reported through our
laboratory. This starts to give indication as prevalence in the
population, as well as linkage to previous reports or reports going out
for when that variant was reported. So for instance, if the variant was
reported a year ago, and the geneticist would like to look at that
previous report to derive information from the interpretation, they\'re
able to do that. And when the report is displayed, it\'s actually in
de-identified fashion, protecting again the patient confidentiality.
Next slide, please.

Very important in our process both for efficiency and data integrity, is
the co-creation or simultaneous creation of both the human readable and
the computer readable elements. Next slide, please.

And you see here a summary of the functionality that the geneticists
have communicated to us that it\'s very important in the system and for
which we have built this out. Next slide, please.

Let\'s take a look at what this, what these results look like in the
electronic medical record. Next slide.

First let\'s examine some of the complexity of information in the
medical record, and the necessity to appropriately tag and annotate
these results so that when they\'re consumed by both the clinician or a
clinical decision support rule that they\'re used appropriately. On the
left-hand side as you see going down, we are going to be having a large
variety of different genetics-based tests going into the medical record.
These will vary from identified variants to named alleles or actually
copy number changes and larger chromosomal changes as well. Along the
bottom you can have a test, let's say a B RAFT test done on a person\'s
germ line sample or blood, and this will give an indication for if
they\'ve inherited syndrome or you could do a B RAFT test on cancer
tissue and this would give an indication to pharmacogenomic guidance
along the tumor. As well as prenatal results, often are still sent on to
the maternal medical record. Along the right-hand side we see different
testing contexts. Again, you can run a diagnostic test on an individual
to determine if they do have the disease or condition. You can also run
a carrier test on the mother. There one copy in a recessively inherited
condition would be sufficient to have, to need particular clinical
guidance and care moving forward in terms of family planning, where with
a diagnostic test it would take two copies for that mutation. And again
the pharmacogenomic context. Next slide, please.

And here you see our longitudinal medical record at Partners HealthCare.
The drop-down selecting the genetic summary table \-- next slide \--
will result in the display of the Partners patient genetic profile. Next
slide, please.

And we\'ve also been able to validate the robustness of our genetic
structure going into the system by having a clinical decision support
rule leveraging this data. Here you see a decision support rule that is
triggered during the ordering of TARCEVA, or Tyrosine Kinase Inhibitor,
for an individual with non-small-cell lung cancer. If that individual
has an EGFR, or epidermal growth factor receptor test, in their genetic
summary where the clinical outcome or interpretation was a resistant
mutation, then this alert would be presented to the clinician and it\'s
a drug genetic intervention. Next slide, please.

Here\'s a list of some of the data standards used to send our structured
results into the medical record. We\'re using the HL7 clinical genomics
model. We're also working with LOINC to hopefully extend their models to
be able to codify these tests in our medical records, that\'s going to
be very efficient for interoperability within our system. We\'re
leveraging the HUGO gene nomenclature for naming of genes and the Human
Genome Variation Society nomenclature for the naming of variants. We\'re
hoping to be able to work with SNOMED in the future as they\'re just now
looking at genetics and extending their terminology to support it. Also,
the national center \-- the National Cancer Institute and their
ontologies which are particularly of interest there would be on our
overall results or interpretation, as well as the clinical significance
of the variant. Other references we hope to leverage in the future would
be genetest.org, if this could be extended and programmatically
accessible and more comprehensive, as well as some of the work going on
at NCBI, and their databases, in particular the clinical reference
sequences. Next slide, please.

Now, this is a summary slide that really captures some of the database
needs that we\'ve had to build within our system to support this
infrastructure. And it was in hopes to communicate it to the larger
community that it would, that these databases are of value and they are
costly to curate, so if it could be made publicly available or a
national center could curate databases like these, then the larger
clinical community could benefit and genetics would be less costly to
implement in an EMR. And we have the clinical reference sequences, as I
already mentioned, as well as the genetic testing catalog. And also a
variant knowledge base. And this knowledge base would have the variants
and their clinical significance, as well as definitions of alleles and
haplotypes. Next slide, please.

At Partners HealthCare we\'re looking to extend our incorporation of
genetic, structured genetic information into our medical record. The use
case I just showed you was sending results from our laboratory in
molecular medicine into our medical record but we realize that it\'s
very important to be able to connect to Genzyme Genetics and Quest and
all the other laboratories to be able to get those structured genetics
in, and we\'re starting to think about this here. And the number of
interfaces that would need to be developed can get quite ungainly as
described here. And it doesn\'t scale well. Next slide, please.

So could we build a VariantWire-type gateway that would solve this
scalability problem and have one interface into each system and a
gateway that would help with data translation, if that needs to be done,
as we might have a number of standards we have to deal with in this
space or that one institution needs to receive the data in a particular
format. Next slide, please.

And, any questions?

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

Very good, thanks very much. Great presentation. Questions from the
Workgroup?

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

Mollie, have you seen any nomenclature issues between, say, where
LOINC's at and where SNOMED, as you mentioned SNOMED is now doing more
definitions of genetic tests. Is there any consistency issues?

**\
[\>\> Mollie Ullman-Cullere:]{.underline}**

SNOMED as of a month ago was just now forming a committee to look at
genetics. So they don\'t yet have a rich nomenclature to support that.
We are very much looking forward to that incorporation and being able to
leverage it. LOINC, currently its guidelines are supportive of more of
the PCR-based tests, sort of 1990s type of genetic testing. We\'re
working with them and to extend those guidelines to support
sequencing-based tests and genotyping-based tests and again, as I
mentioned, very much looking forward to that because the rest of our
clinical environment leverages LOINC and we were wanting to have that
consistency there. Let me, NCVI, or, pardon me, NCI, we\'re hoping that
we could get coded ontologies for overall results, so for instance,
responsive, resistant, low metabolizer, high metabolizer. If these could
be coded, the data would have greater flexibility within clinical
algorithms and have greater consistency and display to the clinician.

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

Thank you.

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

Other comments? Okay, well, Mollie thank you so much.

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

We have one more comment from the room here.

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

I have a question. Do you have a process of informed consent for
patients entering into this?

**\
[\>\> Mollie Ullman-Cullere:]{.underline}**

Yes, we do. And that\'s been looked at very carefully and as the
political and social environment changes, we revisit that on a regular
basis and in fact we\'re just revisiting that now.

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

Good point. Okay. Thanks very much, and let's move on. John, I\'ll turn
the meeting over to you at this point.

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

Thanks, Doug and I\'d like to add my thanks to Andrea and Mollie for
some very nice work and some very nice presentations. We\'re at the next
several items zeroing on the recommendations that we will deliver to
AHIC on the 31st, and we\'re going to begin that by, through a
discussion of the test matrix that is of genetic and genomic tests.
Beryl, are you ready to lead us in that discussion?

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

Yes, I am.

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

Terrific.

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

Okay. Thank you. Good afternoon, everyone. My name is Beryl Crossley, as
you know, and I work in computational biology and bioinformatics for
genetics R and D at Quest Diagnostics. And in that role I support the
new assay development, our esoteric business unit here in San Juan
Capistrano in California and I also manage our LIMS management for our
large operational labs, so I was very interested in the last two
presentations looking and comparing with the differences between our
LIMS and that which you have.

So I\'d like first of all to thank my colleagues within the Workgroup
for their superlative input over the past couple of weeks. I\'ll give a
short description of the findings that we\'ve created to date and the
activities of our genetic/genomic test subgroup concentrated on
documentation of the information requirements for genetic testing as a
prelude to generating recommendations and as the output of that we
submitted a matrix for your review and discussion this afternoon.

And broadly we defined molecular genetics and cytogenetic testing as
analysis performed on human DNA, RNA, or chromosomes in order to detect
inheritable or acquired genotypes, mutations, or carrier types. And we
defined biochemical genetics as the analysis of proteins, protein
components, and certain metabolites used to detect inborn errors of
metabolism or heritable genotypes or mutations for clinical purposes. We
did not include ancillary tests which may be performed in support of a
genetic diagnosis, for example, a CBC in the evaluation of a heritable
anemia, since this would encompass almost all of laboratory analysis and
we wanted to scope particularly for the genetic testing that we
described.

And for the matrix we identified several broad categories of genetic
testing determined by type and methodology and our examples being
(inaudible) analysis, carrier typing, full genome sequencing, single
point mutations or (inaudible) analysis, epigenetics, protein
dysfunction, et cetera. And you can review the list of major categories
on Page 1 of the document we distributed and then we subdivided the
information into the major phases of the analytical process, including
the pre-analytic, the analytic, and the post-analytic phases which were
discussed earlier today.

For each category of genetic testing we then documented the information
requirements in support of each phase, the pre-, the analytic, and the
post-analytic. In pre-analytic testing, for example, we identified the
requirements for family history and ethnicity for SNP analysis for
certain diagnostic conditions and gene sequencing, or for treatment
history and the analysis for an acquired or somatic genetic disease. For
the analytic phase we documented the high-level methodologies which will
determine the format of the data output for each category of genetic
testing. In the post-analytic phase we identified the information
requirements in support of clinical treatment, including the data to
support interpretive algorithms, and references to the literature.

Then, after developing the basic matrix, Kristin and Lauren extracted
the data elements for each of the pre-analytic and post-analytic phases
which were common to all of the categories of genetic testing within
those phases. And they listed those common elements at the beginning of
the matrix. And what you see in front of you is the final product of
that matrix.

And our goal and our aim was to collaborate with HITSP to identify
existing standards for information within the categories outlined, for
example, known standards for patient demographics. At that point we\'ll
be able to identify where gaps exist between the information
requirements and current documented standards and will then be able to
propose recommendations for use case development.

And as a group, together, we identified several open issues for
discussion. Our identification of the distinct phases for the analytical
process raises the issue of the distinct nature of the data
repositories, analytical data including laboratory instrument data is
likely to be distinct from and owned by different organizations from the
pre-analytic and post-analytic data. The group recognized also the
importance of strong links between those data repositories to verify the
unique nature of each patient's data and the importance of a standard
communication protocol such as HL7 between data repositories and the
need for security across all communication.

Regarding the identification of existing standards for data sets and a
collaboration with HITSP for documenting the gaps that exist between
existing standards and the data requirements needs, our group felt we
were under-represented and we would recommend getting additional
expertise in this area. Collectively as a group we felt that our
combined knowledge of existing standards was not complete and so our
recommendation is to improve upon that by including additional expertise
with regard to existing HITSP standards.

The group also discussed the creation of a national repository of
clinical significance which would be accessible to clinicians and
alleviating the need for individual organizations to curate their own
data which we considered might be cost prohibitive for a lot of smaller
organizations and the value and importance of a very large data
repository we think would be a very great benefit.

The group also recognized that interpretative algorithms are dynamic and
we discussed the logistics of updating interpretation of past results
based on new information and how to convey these updates to clinicians
should an interpretive algorithm change and that may result in
additional data of a past result that a physician may have received.
That would provide with, him with additional updated information based
on changes to interpretation and changes to increased enhancements in
knowledge. So at that point I\'d like to open this for discussion to, of
the points and of the matrix that we prepared for the genetic/genomic
test subgroup.

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

Questions for Beryl?

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

This is Kristin, I just wanted to comment briefly. At the beginning we
had a little struggle as to the best way to frame the discussion and
following the suggestion from Betsy, that this began the process of
generating this matrix and it began with each subgroup member basically
identified one type of output and we felt that focusing on the output
rather than the technology would give us a broader scope of what we were
looking at. And that was what generated the scenarios at the back of the
matrix, and we can then pull the granular levels of information to
describe the specific needs and I was very pleasantly surprised to see
that probably about 90 percent of the information needs could be
described in some kind of common information need, especially when you
looked at the pre- and the post-analytical phases of genetic testing. So
we have identified certain aspects that will need different types of
standards but I think it was a very useful exercise for the subgroup.

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

Other comments, questions? Beryl, I think this is terrific, and Greg,
Kristin, this is sort of a question for you: the appearance would be
there\'s a fairly iterative process with HITSP on the standards of we,
given this matrix, the collapsing into a common set and the
identification of unique sets, et cetera, that there is a mapping of
standards, identification of gaps, working on standards, and maybe this
shows my limited understanding of how the Workgroups interact with
HITSP. This seems to be more iterative than most. Is that true?

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

That\'s absolutely true and we actually had John Loonsk join us on our
subgroup call yesterday to discuss options and this basically \-- this
subgroup can identify the people with the necessary standards expertise
to help us do the gap analysis, and it will be a very \-- we wouldn\'t
even necessarily have to go through HITSP. If we felt like there was the
appropriate SDO, that just hadn\'t moved into a certain area we
identified, we could speak with them and John said that he would help us
facilitate those interactions through HITSP as necessary, but it would
be a highly iterative process.

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

This would be in a way, maybe it\'s probably a correct way to do it but
a nontraditional recommendation. We\'re recommending going into this
iterative process that won\'t lead to, right off the bat, use cases.
That\'s along the way.

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

And it\'s possible though use cases would not even need to be developed,
but using past use cases such as the lab EHR and interoperability use
case specification that a whole new use case wouldn\'t even need to be
developed but that remains to be seen. It would be a different process
than has previously been used, I think.

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

Less linear and less prescriptive, perhaps, than some of the others.

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

This is Greg. I think that, as you know, AHIC will be going through some
metamorphoses of its own \--

\[music\]

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

You guys must be having fun in DC, all that dancing going on.

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

There\'s a symphony next door. We have trouble with them from time to
time. But this is the kind of iterative that you see more of, with more
highly integrated kinds of data and I think we are continuing to walk
that through with ONC here as to not break so much with the traditional
pathways to certification and adoption, but again building on an area
where there\'s a lot of evolution and iterative changes in the
technology and the types of data being reported that there needs to be
more of a continuity and not necessarily having to reinvent the whole
cycle each time and so I think that this has prompted some new thinking
within ONC and as the new model for the standards process becomes
unfolding I think this might be a good case example that we bring
forward, as to how to do this in an iterative fashion.

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

Good. The other question I had is on some of the other recommendations
of the group, for example dealing with issues such as the change that
will occur over time in the interpretive algorithms or the utility of
national repositories of findings, et cetera. I presume, too, that we
would incorporate whatever refinements need to be made along those ideas
as part of the recommendations, and again, different than the
designation of use cases. These are areas that require further
exploration.

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

Yes, that\'s accurate.

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

Okay. With a perhaps unclear response on the part of AHIC about how that
would be done, perhaps waiting for our suggestions about how that might
be done.

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

I think that\'s true. And as other Workgroups have done in the past,
that their recommendations don\'t deal specifically with use cases or
standards exclusively, that other areas may blend into policy or
reimbursement strategy, so forth. I think the onus is on us that if the
recommendations are being made pertinent to more specificity for the
family history areas that we\'ll be talking about, that we have close
communications and dialogues with the organizations to which these
responsibilities are going to be assigned. And I think there\'s a lot
more work to be done in this area, but they may be as general as saying
that the further exploratory work by certain organizations would be done
in a certain timeframe, for example, would be, I think we would
recognize to be important for the whole community and the visibility
aspect, I think we\'ll still have to hear from AHIC about that and often
the tendency has been for these kinds of recommendations to be placed
back on federal agencies themselves.

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

So we may in a position and depending upon how much further along the
Workgroup gets, fairly general in July, to do some homework and
discussions through the course of the summer and perhaps use part of our
time as we get into September to refine some of these recommendations
that are not specifically dealing with standards.

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

Well, I think, I mean it depends how the work goes, but I think we could
present recommendations that are just a new group or identify the need
for some kind of gap analysis for the different standards, the different
information needs and the standards for those. That could be the nature
of the recommendation. And then that would be continuing the work of the
subgroup, potentially forming a new group that has the real expertise in
the standards development or standards identification, but that would be
a type of recommendation we could make.

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

But a recommendation dealing with the fact that interpretive algorithms
will evolve over time and perhaps quite rapidly and in great volume, and
that that has to be \-- see if there\'s some high leverage national way
of addressing that, that might be a fairly general observation and
conclusion that should be dealt with. The specifics of how we deal with
it or who might deal with it, et cetera, we could place the onus on us
to come back at some future point with AHIC or whatever its successor is
to be clear about that, and engage in that kind of conversation when we
get together in September or on other conference calls.

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

I think that\'s correct. I did want to come back, I think it is going to
be important to have some recommendations addressing use case
development in this area. I think we have to work that out yet but given
sort of the timeframe and how AHIC is currently working with HITSP in
the development of use cases, I think there\'s clear interest on aspects
of genetic tests in use case development. It may take a number of
different flavors in terms of having extensions from other use cases but
I do think they\'re looking, or anticipating from us, I should say, some
recommendation to that use case development process.

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

And something that\'s going to be iterative.

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

Yes.

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

Well, I guess if I'm listening correctly that means sometime in the next
six weeks we\'re going to propose certain use cases? That AHIC would
prioritize?

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

The main thing we would have to do, we first have to recommend that AHIC
take personalized healthcare out of the priority for use case
development. That would be the primary recommendation. And we may not
want \-- it depends. We may not want to actually specify what the exact
title or what exact information would be contained in that use case.
Family history would be one aspect. Genetic tests may be a aspect of
that larger use case, but the nature of the use case we are to propose,
we wouldn\'t necessarily \--

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

Okay, terrific.

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

I think we are going to continue to have very close dialogue with John
and the notion at least as we\'re thinking about it currently is for
there to be close coordination between this proposed gaps analysis group
with HITSP and so that there, we'll have to invent this conduit somehow,
but the reference group here becomes a utility for HITSP\'s continued
work.

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

Okay.

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

It sort of replaces in my mind the analogy of the CHI reports initially
were done as a state of the standards kind of process as I understood
it. This kind of action updates that in an actionable way that's more
real-time in terms of the states of development for different type of
analytes and the terminology used to describe them.

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

I don\'t mean to hog the conversation. Let me see if there\'s any other
comments or questions about the conversation that just occurred, for
Beryl and the group.

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

I have a question. I have two questions, actually. Is this document
final?

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

No.

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

You're still working on it.

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

It will probably remain a working document for much of its lifetime. We
will be constantly \--

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

Do you want our comments?

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

Yeah, if people have specific comments, please send them to me and
Lauren and we\'d be happy to incorporate them and include them in the
next subgroup conversation.

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

And then the use case that we\'re doing on newborn screening, I mean the
environmental scan we\'re doing on newborn screening, will that be part
of this process? Or separated \--

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

Well, that\'s not something we have discussed extensively within this
Workgroup so far. I think we could potentially define it broadly enough
that that would be one aspect of it, I just don\'t know if in terms of
the recommendations for July 31, if we\'ll be specifically addressing
the area of newborn screening.

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

I think we\'ve discussed with ONC that, and hope to bring up to the
co-chairs when we think we have this framed accurately enough, a
discussion that has been ongoing relative to infrastructure. This stands
beyond electronic health records, but messaging and other aspects of
newborn metabolic and genetic screens, the state mandated tests, that we
believe there\'s an opportunity to bring forward to this Workgroup a
potential area of further development and discussion within the
Workgroup, but we want to make sure we\'ve got that button-holed before
it comes up. That potentially could be an issue for the September
meeting if AHIC, if it needs to come to AHIC.

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

Timeframe of July \--

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

Other questions, comments? Beryl, thank you again, and your group, very
nice piece of work.

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

My pleasure.

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

And Alan and Marc, you guys ready?

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

Yes. This is Marc, and I\'m going to be presenting. The family history
group created a strawman that was an attempt to be comprehensive with
regards to both short and long-term issues around family history. Given
the response that you\'re going to kind of hear that we\'ve gotten,
perhaps we should have changed it from a straw man to chum. Not from the
sense of a buddy but the stuff of bait that\'s dropped over the side of
a ship and attracted sharks.

\[laughter\]

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

Friendly sharks, I\'m sure.

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

Very friendly, actually very friendly sharks. The inevitable question
that came at the end of the last presentation, we\'ll start with this
one. This is definitely a work in progress, so \-- and I also want to
thank all of the members of our working group for their contributions,
it was really quite a pleasure to take credit for all the work that they
put into this.

The key points that I want to make on behalf of the group is that family
history is already in broad use in clinical care, but its use and
maximizing its utility is being hampered by several different factors.
These include a lack of consistency of elements collected, in other
words what diseases do we collect against, age of onset, degree of
relatedness, how many generations of information do you get, those sorts
of things. The storage currently is in free text which prevents the use
of coded data elements that can be used for analysis and decision
support. So much as we heard in Molly\'s presentation, a big step
forward for them was to move from a free text genetic laboratory report
to a report that not only contains free text but has structured elements
they can do analysis on.

Lack of time and reimbursement for providers to collect the data, which
brings up the possibility of alternative solutions that might be able to
work around that.

And then limited dissemination of information and guidelines on how to
actually use family history risk for stratification and most importantly
to modify and personalize patient care. There are emerging efforts to
collect standardized family history information that can be stored in a
coded manner to support risk stratification. At our last meeting we
heard a presentation from Kevin Hughes about how he\'s doing this within
an electronic health record environment. And the Surgeon General\'s tool
which is a, would be more of a patient-centered or a PHR application,
has aspects of how this might occur within a PHR, although currently
that tool is not storing the data in a coded fashion, although it\'s
using that information for analysis. We also have a Utah Health Family
Tree Project that does this using a health interface.

And I think the most important point is that even with the emergence of
genomics, family history is going to remain important to direct care,
because in addition to capturing familial genetic information it also
captures shared environment and cultural impacts that alter expression
of genomic elements, and genomic scanning will never be able to capture
these elements. So I don\'t think we can subscribe to the view that once
we understand the genome that we\'ll be able to reduce everything to
that level.

So based on those key points, we generated our path and I just want to
briefly talk about the recommendations and why we came up with those and
some of the comments we\'ve already received.

The first recommendation was that we really did think we needed to
develop a use case around family history. We did receive a comment from
ONC with a concern that perhaps the family history use case might be
restrictive, and the question was raised whether we should build a
family history component into a larger use case as an element. And as I
thought about that, it certainly would be possible that we could take
family history and integrate it into other use cases from other
Workgroups and in fact I would encourage us doing that. In fact, I would
encourage us to taking advantage to put that information in any of the
use cases that would seem to be appropriate for that. But I think that
family history is in some sense the foundation of personalized medicine
and if we really have ownership of the idea of personalized medicine in
our Workgroup then I think it would be difficult to abrogate ownership
of having a use case that's fundamental to our Workgroup. So to kind of
turn the comment on its \-- and look at it from the other direction, I
think that the family history use case ultimately could become a
template that could be used by other Workgroups to address the specific
family history that is relevant to their area. And the reason that I
would propose that is that the concepts in family history that would
need to be represented and coded such as family relationships and those
sorts of things would be invariant across all the different
applications.

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

Marc, could I just \-- this is Betsy. Can somebody in the room tell me
whether we\'ve actually got anybody who, in another use case that is
actually dealing with medical history taking in general? Of which I
always considered family history was a subset.

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

Kristin or Greg, can you address that?

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

I don\'t believe that has but I would need to double-check with ONC.

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

Okay, well, I guess my feeling is if no one is addressing the medical
history in general, then if we did something that was focused on this
then it could later become a module in the other thing. But if somebody
is actually focusing on that right now, then it seems like maybe we
should be collaborating with them.

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

This is Doug. Certainly the AHIC has not considered any use cases to
date that include a significant focus on medical history nor family
history.

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

Okay, thank you. So that is not part of any of these general EHR ones
because they\'ve been focused on other more narrow subsets of the EHR?

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

Correct.

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

That\'s correct.

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

Thank you.

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

There was a discussion in the Chronic Care Workgroup of this about a
year ago, maybe nine months ago. But it did not make their priorities
list to come forward. And so that\'s one of the areas that we were kind
of encouraged by them to continue to work on.

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

The ONC rationale for collapsing it was, and it\'s fine for them to just
reduce their effort. Is there other rationale?

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

The most recent discussions have been collapsing within the context of
the genetic test. I think more broadly in terms of \-- we have had prior
discussions that I think John addressed in one of our first calls, was
the extending this from one of the existing use cases, they did a more
thorough analysis, as I understand it, looking at that and then came
back to us with the recommendation, or their recommendation anyway was
to focus on a personalized healthcare use case development process.

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

I would think that our genetic tests belong more in the lab test area
than the personal health record does. I mean, than the family history
does.

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

I think Greg, I\'d keep it separate. And I appreciate John\'s rationale.
I think Betsy points out that there may be better ways of thinking about
collapsing it if collapsing were to occur.

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

Yeah, that point was raised on the call yesterday and I think that
spawned us to do a lot more thinking. We clearly see that as an issue.

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

Okay.

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

But we\'re going to be talking \-- we haven\'t had a chance to talk with
John since yesterday\'s meeting but I think the rationale for that was
pretty clear.

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

This is Sumitra Muralidhar from the VA. I was just wondering if the
clinical decision support, would that be a good medium that you could
tie in family medical history? (inaudible) in that area?

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

Fortunate I guess that the chair of the clinical decision support team
is actually leading this discussion, and looking at some of the road map
materials that were developed for that. We certainly \-- the use case in
the front of that that ties in both family history and medical genetic
tests. I think that\'s going to be further down the road and John,
expecting you to jump in here, but I think certainly we see that the
utility of having the electronic health record standards for family
medical history and genetic tests is a precursor to some extent to
developing these tools and integration of them.

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

I'm capable of taking subtle and not so subtle hints. I think with the
clinical decision support conversation we had several weeks ago, one of
the tasks that we have as a group is to come up with some use cases
involving decision support so that the folks working on decision support
can understand the types of analyses and support that we might be
envisioning as being relevant to our particular area and they can factor
that in along with other decision support targeted and specific use
cases they get from other Workgroups to look at their framework and
approach, et cetera. I think it\'s a reasonable idea for them to pursue.
I think it is an idea that we ought to take up with a little bit more
energy in the fall but not necessarily right now because we have
obviously some stuff for the end of July to put together.

I also do think that the decision support use case and analysis is
separate from the both capture and structuring and interoperability of
data. So I think it\'s a reasonable point to collapse them. I\'d keep
them separate for the time being, largely because it will be easier to
track the various groups that are paying attention. The decision support
Workgroup on one side, AHIC and HITSP on the other side. And I think the
sort of discussions surrounding them are different enough \-- anyway, I
would just keep them separate for the time being. My sort of gut on this
is, and again Greg, you guys can follow up with John, let\'s keep them
separate for the time being, and we\'ll see whether we get other
guidance from ONC. But I would do that for right now.

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

I think we concur here. Thank you.

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

Sure. Marc, sorry for the interruption.

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

No, that\'s fine. And I should have started with the caveat that I am
really completely dependent on those of that you have been heavily
involved in all of the AHIC activities to really make sure that we\'re
going in the right direction here because while I think the concepts
that we\'re talking about are very important, it\'s almost impossible
for me to put them in the context of all the other work that\'s being
done. And we would certainly be amenable to exploring different ways to
do this as long as we\'re addressing the key points.

**\
**Drilling down, one of the things that will almost certainly change in
the next iteration of this is that some of the subrecommendations under
for example 2.1, where we recommend the use case, reading through those,
you'll realize that 2.1.1 and 2.1.2 may not technically be
recommendations. 2.1.1 really is more of an inventory, if you will, of
different groups that are currently, have examples of electronic health
records or personal health records, as well as an inventory of some of
the current family history tools that are available. And the point there
is more to just say that there are some things that are in existence
that we certainly want to be cognizant of as we look to develop ways to
perhaps develop and implement a use case. And 2.1.2 really is more of a
list of things that we would think would be desirable elements that,
from a functional perspective that would need to be done, which, you
know, relates to developing standardization of data terms,
interoperability, security issues, and then the issue of being able to
interact with other modules that would support clinical decision support
and risk assessment.

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

I actually like them as recommendations, Marc. Greg and Kristin, are
there reasons we wouldn\'t do this?

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

This is Greg. I\'m not privy to the feedback or comments that you've
been getting. Maybe I\'m behind in my e-mail.

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

This is Kristin. We received a number of comments back from the DOD and
the VA yesterday, so we didn\'t have much time to react to them. But I
think there was just some concern about being too descriptive and
locking people into things that end up costing them a lot of money. So
we just need to continue the conversations with them to make sure that
they\'re framed correctly and appropriately to mean it\'s more of a
discussion and an interaction then we\'re saying you need to get these
resources to this IT project. So we just need to continue that
conversation with them.

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

I was going to make that specific comment at the end of the
presentation, but I think that we have solicited comments from all of
the different entities that have been listed here and have been getting
back a lot of different comments. I think anyone would recognize that a
lot of the entities that are listed here are really not under the direct
scope of the Secretary of DHHS. We\'ve got Veterans\' Administration,
Department of Defense, and other groups that are working along similar
lines but are certainly not directly answerable to DHHS. And one of the
other comments that was, that we tried to represent here but which also
came back from a number of the reviewers, was that we really need to
pull in a lot of private sector people here and then we get into even
more complicated ideas about how do you incent, encourage, or compel
people to participate in this type of activity, the concern being that
if we use only governmental entities will this be looked upon as a sort
of a federal standard that is going to be imposed on others and would
that in fact be looked upon as being a negative rather than a positive.

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

Marc, this is Greg. To address your first point about the other federal.
non-HHS federal agencies. Those that are included here also have members
represented on AHIC, and they have, at the outset of this being a
Workgroup, expressed interest in working in these specific areas. So
that\'s one of the connections, and albeit that the Secretary of HHS
doesn\'t have authority, presumably those that are at the table for AHIC
do.

And then the second point I don\'t have any comments on.

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

And again I want to be \-- I think the idea and maybe it would be, I
think it would be a good idea to have commercial or civilian or
nonfederal, non-government organizations involved in a process like
this, and I think one could perhaps soften the language. On the other
hand, this is a fairly early and formative time for this kind of
application and this kind of technology, it's not a bad idea to get some
of the major players at the table and start talking about how to evolve
towards standards and models and things like that. So again, it\'s a bit
different from we, here\'s a use case, HITSP go figure it out. We may be
ready for a use case. But this may need a little bit more work before
it\'s truly ready for a lot of standards work because the feature
function on a wide variety of the issues may be a little fluid, not as
well understood, and all over the map to a degree. I think you could say
that this is an area, unlike the (inaudible) of moving a chemistry
result from point A to Point B where there\'s perhaps some utility to
having a discussion along these lines before we start plastering
standards all over kingdom come.

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

John, this is Betsy. I really agree with that. And one of the things
that I was trying to get at before at the wrong time in terms of that
issue of characterization, what I\'m concerned about and maybe Doug and
you and others in the group know all about this, but what I can\'t find
is a description of a lot of any type of agreement or even a lot of
literature around the issue of how family history is effectively
collected in the primary care environment now and how it is effectively
used and integrated into workflow in primary care. And therefore it
seems to me that whatever is done here, is going to need a lot of
on-the-ground iterations so we don\'t come up with a standard for things
that will not be collected well or be integratable into clinical
workflow.

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

Yeah, and \--

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

See, maybe I\'ve got that all wrong, but \--

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

I hear you. I agree.

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

I think that that is an important point. Again, I would look at it from
a slightly different perspective. And one is that the building of the
nomenclature of relationships will need to be done no matter what
information is collected.

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

I would agree about that. I agree. I think there are pieces of this that
are more standardizable now than for example \-- I don\'t know, I just
really feel that if we\'re going to talk about use cases, we have to
have, know a little bit more about how it\'s going to be used in a
clinical workflow.

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

Well, again, I think that there are plenty of examples that could be
used for a use case for family history that we really know. If we want
to look at an example like breast/ovarian cancer or colorectal cancer,
they\'re very well agreed upon issues around how family history should
be used either to identify individuals who should undergo testing or for
individuals that should have modified surveillance, those sorts of
things. So I think there are examples that could be, that everybody
would agree with that you could build a use case around.

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

And I\'m not arguing that we know where the family history is really
useful. I just, I haven\'t been able to find a lot of stuff describing
how we\'ve effectively built into clinical workflow in primary care in a
widespread way the use of these things that we know something about.

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

I think that\'s a very salient point and actually, I did the same
literature search that you probably did, and it is amazing that as much
work done about what diseases are people collecting and how are they
collecting it, no one has asked the question about how do primary care
physicians actual use the information. So we\'re actually doing a
research study in our group right now to try to address that question at
least from a qualitative perspective.

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

I think we saw at our first face-to-face meeting with one of the
presenters that came to us then, gave some background information, that
some of the research that has been done on that is that the collection
is certainly not on par with where it should be in the primary care
setting. So your point is well made, Betsy, that the last thing we want
to do is \-- even if we create the best expression of family history in
an EHR, if it\'s not functional to the workflow of the docs in everyday
practice, it will be inhibitory in terms of its use. So we do need to
pay attention to that. And hopefully between the work we do, the
standards that HIT Standards Panel addresses, and then implementation of
all that through the certification process, we can have the right people
at the table to address workflow at the same time as structure.

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

I even was going to say we might want to consider whether we actually,
whether we actually need a recommendation around this point that in fact
we need to do, you know, we need some more R and D around this issue.
I\'m happy that Marc is doing some, that\'s great.

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

This is Alan Guttmacher. I would certainly agree with that point. Often
of course this is an argument that whenever we do, we should make sure
that we are all intellectually honest and say that something that is
going to incorporate family history, like an electronic health record,
needs to be dynamic, because none of us know what the true ultimate
answers are today. The other thing to mention is, it\'s not a sure thing
yet but we are optimistic that there will be an NIH state of the science
conference on this exact issue, that is the use of family history. Over
the next 18 months or so.

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

Alan, this is Jean Slutsky. I think we\'re actually doing an evidence
report for that consensus conference.

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

No, you\'re not doing it for that one yet because it hasn\'t actually
been decided upon.

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

Oh, okay. I know we\'re doing one on family history.

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

Right, that\'s for the CDC.

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

Okay.

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

This would be an even larger warrant than that.

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

So this is Mark Rothstein. If it\'s okay for me to jump in at this
point, I\'m very concerned about these recommendations because they
don\'t indicate at any place the importance of privacy concerns in
family history. Family history is much information that can be described
as highly sensitive, things like misattributed paternity, child abuse
and neglect, family members who have committed suicide or have substance
abuse problems, et cetera. Family history may be highly relevant in some
of the cases that were discussed, such as the oncologic cases, but not
every physician is going to be able to make effective use of family
history. If you go to have your sprained ankle treated, the fact that
there\'s misattributed paternity in your family is not going to affect
your treatment one way or the other. And that suggests to me that
patients need control over the elements of their health records
including the element of family history. And I think it\'s a very
complicated issue and our recommendation for broader use of family
histories without any limitations on disclosures, both within healthcare
settings and to third parties who may request medical records such as
employers and life insurers and the like, I think really undermines the
viability of the recommendations that we\'re contemplating.

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

I think fair. A couple of thoughts here. One is, listening to the
discussion and looking at the documents it seems to me there are four
recommendations that are in play here. One is, Mark, to your point and
others, there are some areas where standards could be developed because
there\'s presumably enough known about the challenges and the utility of
relationships, for example, and so we can have a recommendation around a
use case which is really targeted to help flesh out portions. That\'s
sort of recommendation number one.

Recommendation two is on the other hand there's a great deal that's not
known about the form, function, or whatever of these and that a
gathering of players from both the government and non-government sectors
to talk about, that\'s particularly an emerging aspect both of family
history and personal health record, that we would recommend that that
occur, to see if we can arrive at a consensus set of capabilities,
requirements, and stuff like that.

The third is, and is covered under a couple of the later bullets, and
Betsy to your point, is that we would encourage demonstrations,
evaluations, and research to understand both the clinical utility but
also the impact of these kinds of systems on the provider workflow and
on sort of patient ability to use them.

And Mark, fourth, to your point, is that it is very important that we
assess and make further recommendations regarding the privacy of the
data contained within these because these have very complicated sequelae
that we may not fully understand, and regarding the fourth one, that one
of the things we may recommend to AHIC is that we, this Workgroup, take
that topic on as one of the things that we would like to address in the
months ahead. I do think it would be very important that we get a
privacy one in there because of the complicated nature of family
histories.

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

This is Marc. I\'d like to respond a little bit more specifically to
that. You know, we\'re not talking about adding anything over and above
what is already represented in any medical record on family history. All
of the points that were raised are already present in family history.
The issue is repackaging. So I guess the question that I would have is
it the repackaging of that information that would enhance the privacy
concern? Because we\'re not talking about identifying relatives, we\'re
talking about from the perspective of personally identifying a relative,
who that person is. And if that information is already present, it\'s
already being used by third-party payers, in fact they\'re specifically
requesting that information when you fill out health or life insurance,
you\'re asked to provide family history information. So is there
something about repackaging the information so it could be used to
improve the healthcare of the patient that makes the privacy concerns
much greater than they currently are?

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

Yes. The current health record system is characterized by fragmentation.
And even though some data elements may exist in health records, if
someone has their health records in 18 different places, their family
history may not be included in all 18 places, and probably isn\'t to any
great detail in all those 18 places. If you have an interoperable
network and now have the capability of getting all the data from all the
18 record sources that an individual has, now it raises much greater
privacy issues, not just with regard to family history but with regard
to everything else. So when individuals request information, physicians
or non-physicians, it\'s not clear that they need everything that\'s in
everybody\'s medical record and one of the things that\'s being very
carefully debated both within the Department and elsewhere, is the
degree to which individuals should be able to control what is collected
in the widely available medical record, and to what degree they should
have controls over those disclosures.

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

I think it would be prudent for us to look at the privacy ramifications
of this and given the new sort of media for bringing this stuff together
and so both on this family history but also on the genetic and genomic
test. So I think that\'s worth examination. And I frankly believe the
\-- and again, we\'ll shut up and see what the rest of the folks think
\-- worth a recommendation.

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

John, this is Doug. On the issue of privacy and security, while I think
it\'s important for the Workgroup to have the discussion and for us
perhaps to have a recommendation related to that, let\'s not forget that
there is an AHIC Workgroup on Confidentiality, Privacy, and Security. So
there\'s another big group working on this plethora of issues in toto
and so either we perhaps can simply refer it to them for their action,
or we can develop some additional thoughts and recommendations that
either go straight to AHIC or go straight to the other Workgroup that
eventually come back to the AHIC.

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

Fair enough, Doug. My bias is that we have some time on this thing and
that our recommendations go to that other Workgroup for incorporation
into their (inaudible).

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

This is Deven McGraw, and I\'m also on that other Workgroup. So I think
it would actually be very helpful to have this group, the Personalized
Healthcare Workgroup, consider what might be different or special about
family history or genetic information that requires considerations above
and beyond those we are already contemplating for the, for EHRs and
PHRs, for other types of medical data.

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

Good point.

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

Other comments, reactions? Marc, we\'re still trying to get you through
this document.

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

I think we\'re pretty well through it. I mean, most of the points that
are being made are ones that we were hoping to come up with. And again,
we\'re in the process of refining, trying to improve this. We have more
comments from other groups that we\'re expecting to come in. The
recommendations under 2.2 I think are really more targets of opportunity
where we know activities are taking place, where we\'re sort of raising
the possibility of saying think about this in the context of some of the
capabilities that you have. So from my perspective, I think I\'ve pretty
well covered what I wanted to cover unless people have other questions.

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

Other questions for Marc?

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

This is Betsy. It\'s not a question but just a comment. That when you
put this together, think about the order of things, because for example,
as I was reading all of this, I was saying to myself, but we don\'t know
how these things are being used. We need to figure this out. And then
that seemed to finally come up in recommendation 2.2.6. The order of it
struck, you know, we were defining everything up front and I\'m saying
but do we know how people really use these things, or could. And then
the thing that got at that particular point was the last on the list.

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

I have a question. This is Greg Feero. To what extent can we (inaudible)
the thoughts of this group to leverage our conversation at the NIH, the
OMAR, regarding the need for a conference on family history?

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

Do you want to handle this one?

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

This is Alan. Would it be unfair for us to, if we\'re going to be
talking with the folks at OMAR, I believe it's next week, to say that
the AHIC group on Personalized Healthcare agrees that there\'s a
relative lack of information in this area and it would be useful to pull
together in a comprehensive way what information is currently available
and to look at what are the opportunities and needs for information in
the relatively near future. And this is an important thing to
understand. I don\'t know that we need a formal vote but we would want
to carry the sense of this group that that was the case.

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

I think that makes a world of sense to me.

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

Great, well, we will take your unofficial \--

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

There you go. And Marc Williams, the thing I might do, you have lots of
feedback here. One last sort of comment to you. Again, my own personal
one. I might remove recommendations 2.2.2, through 2.2.5. We\'re
probably a little too fine grained and targeted there. 2.2.6, 2.2.1 is
to be fused with that \-- the first one and the sixth one could be fused
in a manner regarding the impact analysis and demonstrations and stuff
like that.

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

All right.

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

This is Kristin. You know, we have families, our family history subgroup
call scheduled for next week or the following week and we definitely are
planning on making the necessary changes based on this conversation and
the subgroup will continue to work through the draft and when we get it
in a more refined state we will send it to the group for additional
comments.

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

Perfect, thank you. Other questions, comments for Marc and Alan?

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

This is Sumitra Muralidhar. I just had one comment. And that is as you
rework some of these recommendations, timeline also I think is
important. I think the VA felt that the (inaudible) to accomplish a lot.
It seems a bit unreal.

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

We will also continue to interact with anyone that would be affected by
these, VA, DoD, IHS, make sure that they have, they\'re comfortable with
them before we advance them as well.

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

I would, just to the point for both John and Marc and Doug. We\'ve had
just \-- this is my experience, a little unusual to have such
interaction and positive reactions. I think that to a large extent these
recommendations were driven by the visioning exercise and perhaps
without having had that, these ideas and notions of federal agencies
working together at this level. So I don\'t think our efforts to sort of
modify these recommendations should be lessening the importance of that.
But to actually sort of salute, if you will, the team work where people
recognize there\'s a fair amount of value. There\'s been just an
overwhelming amount of enthusiasm of partners that haven\'t heretofore
really worked together on such an issue. So we don\'t want to \-- (audio
disruption) \-- diminish that capability.

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

Well said, Greg.

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

Uh-huh.

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

Anything else?

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

This is Greg again. So that \-- we won\'t actually be convening this
Workgroup again before July 31st. So I think what we\'ll do is, what
I\'m hearing is that the Workgroups, the two subgroups will continue to
refine these, but that will be, will require that the Workgroup members
themselves be poised and ready to be interactive when the final
recommendations from these Workgroups come forward.

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

Yeah, this is Kristin. In terms of the timeline, we need to have the
recommendations in almost final format several weeks before the AHIC
meeting because it has to go through a process within ONC and HHS as
well. So we will work very hard to make sure we have something to get to
you by the latest the end of June in a pretty finalized format so we can
get your comments back and make sure we have a couple rounds to make
sure that everyone\'s comments are incorporated in what we send in
advance to ONC and the AHIC.

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

That feedback would be helpful to John and I when we make the
presentations on July 31st.

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

Terrific. Marc and Alan, thank you. And Doug, you want to take on the
action item portion of this?

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

I think we\'ve already done it, unless I\'ve missed something. All the
feedback that we\'ve had in the past 20 minutes or so, I think relates
to the document that likely will go, be headed towards AHIC for that
presentation on July the 31st, John. Unless Kristin and Greg have any
other thoughts, I think we\'ve pretty well done our work for that, the
action item component of this phone call, unless I\'m missing something.

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

This is Greg. And not to divert things a little bit, but I\'ve still
been thinking a little bit about Mark Rothstein\'s comments on this, and
behind the scenes our group has been working across all of the agencies
in HHS, and this issue has come up about the family history and the
specificity and concerns about these privacy issues around this. I think
we\'re gathering some further evidence and information about this,
particularly from the mental health agencies, and I think that once we
sort of get past this first phase, we would like to delve a little bit
more into depth about these issues that have sensitive family concerns
about individuals and family history as a component of that. So I think
we\'re still internally here, the staff still has a lot of learning to
do in these areas, and I don\'t want to minimize, walk away from this
meeting today minimizing those concerns. I think we\'ve certainly talked
with some of the leadership at NIH, those that are involved in the
behavioral areas. SAMHSA, FDA, IHS, and others and this is an area that
I think we want to do something internally around this to help provide
more information to this Workgroup and perhaps beyond AHIC to deal with
some of these aspects. And to some degree these could be great
inhibitors to people who could benefit most by, in our estimation, the
electronic health information, and what we see as a fine balance between
enabling as well as inhibiting. And we concur with the emphasis on this,
and I don\'t want that, this Workgroup or others to think that we\'re
avoiding or dodging that issue.

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

Well, I think it\'s a good idea to just add a placeholder as we
discussed, to some degree, in the recommendations that go forward to
AHIC. So it serves as a recognition of the importance of the issues.

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

Remember that at our first comments, our first presentation to AHIC,
that we had four areas of focus, and confidentiality and privacy and
security was one of those four. So let it be said that we do view it as
important. And we will get to it and make note of it.

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

This is Greg Feero, just one additional comment. Sort of bubbling up
from the grassroots, too, one of the groups developing standards for the
CCR around family history, essentially everyone that was on the
committee developing that draft standard thought that we needed to have
an ability to state that some elements of family history were only going
to be conditionally shared. And that that was part of what we felt
should be the structure of gathering the family history.

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

Thanks, Greg.

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

Yeah, and this is Marc. I think that as I\'ve heard the context of this
conversation, I think that as long as we are addressing this sort of
across the board with the implications of what an ideal electronic
health record will have in terms of both benefits and harms relating to
various aspects of medical care and privacy, I think that that\'s fine.
And I certainly have no objections to including that. But I also want to
make sure that we don\'t necessarily automatically buy in to the genetic
exceptionalism that somehow this information carries much higher risk
associated with it than other aspects of information.

In some sense, as I thought about Mark\'s comments, I\'m thinking, well,
geez, as the practices in a system that has a very integrated healthcare
electronic health record, the implication of the comment is that we are
actually at increased liability for privacy because we actually have an
integrated record since our major barrier for privacy disclosure seems
to be fragmentation. I don\'t think that\'s a good long-term strategy.

\[laughter\]

**\
**So I think it just needs to be taken in context and not treated as
exceptional.

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

How about if we preserve this conversation for now for this fall and get
back into this topic? Although I appreciate the various perspectives.
And Doug \-- I didn\'t mean to drop the conversation to a grinding halt.
I'm quite capable of doing that, both social and professional settings.

\[laughter\]

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

This is Betsy. I just have to say that the piece of this which is this
kind of information, which is unlike any other information, is the fact
that some of it may be incorrect because people don\'t actually know who
their parents and grandparents were. And then there is the issues of
other types of stigma or problems that that can cause when \-- so it
isn\'t the same as other information.

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

Well, except there\'s lots of errors in medical information when one
gives one\'s own medical history. The errors may not be as great as when
you give your mother\'s medical history, but there\'s not all that
perfect either. So \--

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

Ready for public comment, John?

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

I think that would be \--

\[laughter\]

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

I\'m staying out of this conversation.

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

See if anybody is there who has a question.

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

Jennifer?

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

Yes, I\'ve just put the slide up. There\'s a number for anyone who has
been listening over the Web to call in. If you\'ve been listening over
the phone you just need to press star 1 to alert the operator, and
there\'s an e-mail address on the slide if anyone would like to write in
comments after the meeting. I'll check back with you in about a minute.

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

While we\'re waiting for that, I want to commend our presenters and our
Workgroup or subworkgroup chairs. Some really nice work was presented
and discussed today and nicely done. So thank you.

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

Ditto to that. And to our continued great staff.

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

Absolutely right. Without whom nothing would happen. If it would happen,
it wouldn\'t be at the high quality it currently is.

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

Nobody? Jennifer?

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

I don\'t have anyone calling in yet, no.

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

Okay. It\'s been about a minute. I think we\'re released. What an
efficient meeting. Thank you.

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

Thank you. Are we all set, Doug?

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

I think we are.

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

Thank you all.

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

Thank you, everybody.

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

Have a good rest of the week and weekend.

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

Thank you, everyone.

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

Thank you.

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

Bye-bye.