William Knaus: So I want to give you acknowledgements.
What is it?
It's a EMR that provides access.
And the key word is access.
All we want to do is to be allowed in.
Once we're in, we don't ask the EMR vendor to do anything else.
We provide the capabilities that we've heard about today and that are illustrated on this
slide.
Now, we've heard and we've seen in the previous presentations, you can do a lot of these things,
the collection transfer integration, the delivery of support, but some of the things like the
patient empowerment, the better understanding, the family social networking -- these are
things which are really not done well within EMRs.
And we think it's better if we think about bringing applications from the Internet into
an EMR to do that.
So, we have developed a relationship.
We got permission from Epic.
In March next year, Epic's 2010 release will enable Health Heritage.
Anyone who buys Epic's 2010 release will automatically be able to, if they desire, to turn on this
application, which is external to Epic but which has a door into Epic.
What are the principles of this system?
It attains a limited amount of essential data from the primary sources.
We started with family history and cancer risk assessment because you'll see we are
funded by the NCI, but we plan to go, obviously, beyond that.
We understand what the data represents.
We input the data in a way to either new or existing support tools.
We deliver it in ways that people can understand it, and then we constantly monitor and improve
it.
We've heard this throughout this meeting today.
This is what clinicians want.
This is what consumers want.
As we said, we are supported by the National Cancer Institute in this initial release,
so we concentrated on all the common cancers and the syndromes that are associated with
that, linking family history to these cancers.
And the nice thing about that is this family history also serves as the foundation, as
you all know, for genomic medicine beyond cancer and in all the other specialties.
So let's look very briefly at each of these principles.
We obtained a limited amount of essential data from the various primary sources, including
EMRs.
So with our Epic agreement, what we're able to do is we're able to go into the Epic EMR,
pull out medical, surgical, family history, laboratory data, and we're able to pull that
into our application, and we're able to return to Epic risk results and recommendations and
pedigrees to the physicians and to the patients who are using My Chart which is the tethered
PHR which is associated with Epic.
There's a single sign-on.
A patient activates this service.
This is a patient-oriented decision support application because we think you need to involve
patients from the very beginning.
They sign onto their My Chart aspect of Epic.
They are automatically registered then into Health Heritage.
They have to go to Health Heritage and say that they want to use it.
They request from Health Heritage the ability to pull their medical history into their chart
from Epic, their documented medical history, when they had cancer if they had cancer, the
age and the type that it was, if they had a colonoscopy, how many polyps did they have
during that colonoscopy.
All that information is pulled into their medical record.
And then we encourage them to say, okay, let's go to their family members and have them do
the same thing.
And in the process, we will create an electronic family tree.
So we have a family tree which is populated with data from the primary sources to the
record, authentic data, and which is integrated in the comprehensive way.
That's always been a barrier.
We have system interconnectivity.
We -- providers access -- can access Health Heritage from Hyperspace within the menu or
toolbar within their Epic system.
And they can see both provider and patient contact.
So there's transparency across the different systems.
Data exchange -- what are we doing?
We are moving from Epic data which is in their problem list, their medical history, their
patient demographics.
We're moving data which is in textual format, path reports, operative reports, and we're
taking those results and we're moving them into Health Heritage to populate an individual's
personal medical history.
We are then returning to Epic, which in HL7 message a narrative text containing what the
recommendations are.
And we're depositing that as a test result into Epic that the clinician can look at directly.
How do we know what we have when we pull this data from Epic?
And this is a very important, I think, concept.
We initially took the information that we needed to do family history and risk assessment
in those cancer syndromes, and we mapped them to UMLS SNOMED concepts.
Then we took what is a constant roadblock in this field, which is Epic has a problem
list or a diagnostic list which is maintained by a separate vendor.
And it's a proprietary system that has no relationship to anything in the world.
So, you automatically say, "What am I going to do with this huge diagnostic master file
that is linked to nothing?"
Well, what you do is you map it to SNOMED.
And that capability is increasingly there.
And then what we did is we used the NCBO BioPortal to look at the parents, those SNOMED codes
who are in the Epic diagnostic file that were also needed to be in Health Heritage.
We identified 4,700, so that now when we make a web service call into Epic and ask for this
information, and if one of those SNOMED codes that we're looking for is present, then we'll
set the attribute that we need in a decision support system of Health Heritage to present.
So we've overcome this barrier.
And increasingly, being creative, you can go into systems that have proprietary data
formats that are not standardized and you're able to achieve understanding of what that
data is.
Now, we input that data into existing or newly designed decision support tools.
We heard that decision support tools are not used.
There are thousands of them out there in paper that are not used because they're not connected
into the system.
In many cases, it's not necessary to design new ones.
We just want people to use the existing ones with the appropriate data.
For our purposes, we have a very good existing one, the NCCN guidelines.
There are hundreds of pages of very detailed, wonderfully precise guidelines that are completely
unusable by a human being because they're so long and they're so detailed.
So what we did is we made them computer friendly.
We took and we developed decision trees based on the current literature -- we just didn't
use NCCN.
We updated it where we thought was appropriate, although it keeps itself updated really, really,
very, very well.
And we did decision trees for all of the specific cancers and all the specific syndromes.
This is -- this is a substantial undertaking.
Fortunately, it only needs to be done once, but this is just the top of a decision tree
here, that actually if you would print it out, it would go about 16 feet long in order
to take all the different permutations and possibilities into it.
But what it does is it automates it.
You don't have to go to those hundreds of pages of guidelines.
It automatically takes the data that we've collected.
It puts it through the NCCN process.
And it comes out with a specific risk and recommendations.
And it delivers the output in ways that can be understood, stored, and easily shared by
consumers and clinicians in trusted ways.
This is something else that we've heard from a lot of people, that they want to be able
to do.
So, after we process the system, we collect the information from individuals and from
their family members with sufficient precision to be able to do a risk assessment and recommendation.
We can put people into risk stratification.
And we're trying to look at both ends of the spectrum.
We're trying to recognize that there are many millions of individuals, who because of their
individual patient characteristics really don't need routine screening with the frequency
with which it is currently being done in this country.
And we're trying to suggest to some of those individuals that there may be the ability
to reduce the frequency of their screening safely.
At the other end, we want to make very sure that we identify very early and very soon
those individuals who, indeed, because of biological or hereditary predispositions,
are at extremely high risk for developing problems.
And they are identified early in the process, frequently through family-based structures
and analysis of the family history, and that they're given the appropriate advice early
on to be able to access the services that they need.
We present that report about what they should do to the patient, and then we ask the patient
whether they want that report to go to their clinician, and which clinician they want it
to go to.
It's a very important process of patient control.
It's not how things are traditionally done.
Traditionally done, test results show up in EMRs, and the doctor decides when the patient
can see it, or it defaults to having the patient see it after a few days.
We think this is patient information.
It's their family.
It's their family information.
After they know what it's -- the NCCN recommends for them, then they decide who they want to
send it to and that test result then goes to the clinician.
They have a number of links that they can go to when they receive that result.
They -- we also are building in crowd sourcing, which is trying to link them to sites like
PatientsLikeMe where they can exchange some of their information and data and get some
input beyond their specific family structure.
And again, everything that the patient sees, and including a more sophisticated provider
report, can be accessed by the clinician.
It's -- the print is too small for you to see, but there's a link on this page in Epic
for them directly to go to the Health Heritage, the gene -- genome electronic medical record.
So, we're obviously constantly monitoring the use and impact of this as we roll it out
into communities.
We've already done the initial clinical trial, which looked at the performance of our risk
algorithms and recommendations versus an expert genetic team and a genetic counselor collecting
information.
So we have people for whom that was done in a very separate process, and then we applied
our Health Heritage.
And we demonstrated that we were as good as that process.
So we think we have clinical validity.
We're now going to test vigorously for clinical utility by our first implementation.
It's at North Shore University Health Systems in Chicago, a very sophisticated system which
has had Epic for a long time.
But we hope then to go into other Epic sites.
We hope to go beyond Epic.
We're developing a relationship with Ancestry.com so that we can actually think about soon going
into paper-based offices and extracting information from paper forms, which, as we all know, the
majority of physician's offices in this country are still paper-based.
So we think there's a great future for using EMRs as a source of information, but not relying
on them as the way to build decision support.
Thank you.
[applause]
Male Speaker: Questions?
Male Speaker: So, Bill, going back to the family history
information, you indicated the sharing platform that you have -- can you -- are you reliant
on the other relatives providing information or does the Health Heritage consume a more
traditional patient-entered family history?
And a subset of that question is does the Health Heritage support consumption of other
tools that run --
William Knaus: Yes --
Male Speaker: -- on the current AHIC --
William Knaus: Yeah, we link to the Surgeon General's, for
example, and the -- a person could enter history themselves.
And the system has, you know, annotation where they, you know, did this information come
from the EMR directly, was it entered by the patient?
Every family member has to give permission for their information to be transferred to
their other family member.
It's like Facebook.
You have to friend someone to share information.
It's the same concept.
So, yes, we are able to take information from additional sources.
And the other thing that we've done is we allow patients to meta tag data.
We don't allow them to change any of the information in their medical record, but if they have
a diagnosis or they see a problem that appears in their record by virtue of its being transferred
to us and they say, "You know what?
Yeah, they made that diagnosis a couple of years ago, but nothing ever really happened
with that."
And there can be this little meta tag that sits beside that note.
And the clinician can decide to do what they want with that, but at least when someone
looks at it, there's some annotation from the patient.
We think that's also a very -- going to be a very positive way to help improve the quality
of the data in these EMRs.
Female Speaker: I may have missed this or just need clarification.
You said that once you develop a report with a risk assessment, it goes directly to the
patient.
William Knaus: Yes.
Female Speaker: And then the patient decides if they want
it sent back to, like, a physician.
William Knaus: They're -- if they want it to go to their
primary care physician, their OB/GYN.
Who do they want it to go to?
Female Speaker: So, in the Epic chart, does -- did you just
say, like, does some sort of notification go back at all?
William Knaus: Yes.
Female Speaker: Okay.
Or, or does the -- so notification will go back to the physician that this has been done
and they're at high risk.
Or does the physician have to go through the process into --
William Knaus: No, no, the physician gets a specific report
that tells them this is what they are, this is the recommendations that need to be done.
It's very directive.
Female Speaker: Only after the person says I want it to go
to them?
William Knaus: Only after the patient authorizes that to
pass over to their provider.
Female Speaker: And if they don't authorize it at all, you've
extracted the data from Epic.
Nothing goes back to Epic.
William Knaus: It sits -- it sits in Epic, but it sits in
My Chart.
It sits in the personal health record of Epic.
It doesn't sit in the clinician's component of Epic.
The patient has to authorize that it go to that clinician.
Female Speaker: Is there, like, a legal liability issue from
the physician's perspective?
William Knaus: This is the patient's information.
And one thing you have to realize is once the information's extracted from an EMR and
it goes to an external application, it's your information.
It's on your desktop.
It's yours.
You own it.
You control it.
Female Speaker: So, but if they have that information -- it's
from Epic and the physician has looked at Epic and not put it together themselves, are
you opening up a door for a liability issue that the physician did not recognize?
Like if time goes on and the patient does not say, "I want this to go back" --
William Knaus: We hope that the communication, the two-way
communication that sets up, that the physician knows their patient is a register for Health
Heritage.
They know that they've done this.
And we hope that there's two-way communication that gets set up there.
But again, we think that as we move forward, the concept of patient control over their
information is going to be increasingly important.
Thank you.
Male Speaker: Okay, we're out of time, so --