American Health Information Community

Biosurveillance Data Steering Group #6

Thursday, September 14, 2006

**Disclaimer**

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

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

We will start off with the roll call and get on with it.

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

Okay, then, I will begin with a roll call for today\'s Biosurveillance
Data Steering Group meeting. On the phone today we have our co-chairs,
Art Davidson from the Denver Public Health Department. And Marty
LaVenture from the Minnesota Department of Health. Additionally, we have
Eileen Koski from Quest Diagnostics, Incorporated. Bill Stephens from
Southwest Center for Advanced Public Health Practice. Also on the phone,
Paula Soper. from NACCHO. And Office of the National Coordinator today
we have Scott Holter, Judy Sparrow, and Laura Conn. Is there anybody
I\'ve missed?

Okay, I think that\'s it for the roll call, and just quickly again for
members of the Workgroup who are on the phone, keep your phone muted
when you\'re not speaking. And then when you do have something to say,
please make sure you identify yourself first so everybody following
along on the Web and the telephone knows who is speaking. And if you\'re
looking at the Webcast, please don\'t touch any of the controls to
change the slides.

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

Okay. Well, welcome, everybody. I think the first thing that we need to
go over are the summaries and from July 26th and August 8th. I have not
received any comments from anybody, so I think we need \-- are there any
comments on the phone?

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

No, I think \-- I went through some of them to prepare the functional
area document, and I don\'t have any comments. I just was pulling out
things from those. I don\'t know that there\'s anything that I have to
say.

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

They seem fine.

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

Yep.

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

So is this \-- we just keep this on the agenda?

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

Just, I\'d like, I guess, a motion to carry them forward as our official
minutes from the group, so as chairs I think you need to ask for a
motion and we\'ll carry it forward.

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

I see. Okay. So is there a motion to carry these minutes forward as our
official minutes?

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

So moved.

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

Is there a second?

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

I second it.

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

Okay. Is there any opposition? Shall we call this unanimous? Because I
can\'t count hands.

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

It\'s fine.

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

Good.

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

Great, so we can take this one off the agenda and hopefully the next
meeting will be able to look at the 18th and the 5th summaries ; is that
right, Scott?

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

Correct, I have the 18th in my hand and we\'ll probably send it out
tomorrow. And I believe Perry Smith just joined us.

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

Yes, I did.

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

Hi, Perry.

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

Hi.

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

Hi, Perry.

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

Hi.

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

So let\'s see. I don\'t think there\'s much discussion about this.
Perry, we just went over accepting as the official minutes for our
group, the summaries that were sent out for July 26 and August 8, and we
approved these as our official minutes, and we\'re just waiting for the
next series to come in for us to review and then approve for the 18th of
August, our in-person meeting and then the last telephone call on the
5th.

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

That sounds good. Apologize for being late. I was running late from
another meeting.

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

Glad to have you.

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

Yep.

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

Okay. So next on our agenda is the preconditions document. That was in
the package that Scott sent out earlier this morning. And I think \--
how many of you had a chance to look this over from the last meeting?
This is a little bit different than the prior one. I\'ve tried to get it
as close to final as possible. I want to draw your attention to a couple
of areas. Firstly, has everybody got a copy?

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

Yes.

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

Okay.

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

Yes.

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

So everybody I assume has got a copy. If not, please speak up.

In the first three bullets have not changed much, except in the third
bullet it used to say with minimal new data entry by a clinician or
facility. And I have changed that with essentially no new clinician
and/or facility effort to do any data entry.

So that\'s a slight change from before, and I think as we get to
describing how we\'re going to collect some of the information that
might be in the HAvBED, this may need to be revisited. But at this point
I made it more restrictive with essentially no new clinician or facility
effort.

Any comments on that?

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

Yeah, this is Laura. You\'ve said data entry, but I\'m worried that this
says no new effort. And there could be effort on the facility to
mobilize the data that\'s already available in electronic form.

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

Okay, so you\'d want \-- that allows them to say mobilize, okay.

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

So you could maybe just make it more specifically say no new data entry.

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

Yeah, I would agree with Laura. When it said minimal effort, I mean the
idea originally had been that we were going after the low-hanging fruit
of already electronically enabled data. But when you change this to
essentially no effort, that data, maybe it\'s electronically enabled.
That doesn\'t mean it\'s readily available in the form we want it in.

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

Okay, I hear that. I\'ll go ahead and change that. I think after I had
changed it, I started thinking back to this HAvBED standard that\'s
being proposed as part of the HITSP document, I don\'t know how many of
you have seen that, but have is in there and I know were Ed on the call,
he would probably speak up about this, and try and understand, do we
think that an institution will be responsible for entering summary data
at the end of a day or whatever period.

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

Since I\'m on the HITSP I can address that a little bit.

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

Go ahead, Eileen.

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

That came up with respect to a great many items during our meeting last
week, and the position that HITSP is taking at the moment is they\'re
not really looking in terms of implementation, but just sort of thinking
of a future state, what should the standards be. Future, they\'re
thinking relatively near-term future, not 20 years from now, but even
so, they\'re not thinking in terms of real immediate implementation
issues. And they recognize that that \-- there may be considerable
barriers to some folks actually entering and making some of that data
available so this is kind of an ideal case at this point.

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

Okay. I\'ll try to reword this a little bit based on your comments and
those from Laura so that we capture those two thoughts. Thank you.

In the next \-- are there any other comments about 3?

In the next bullet, I took away the wording we developed on an early
call, and now refer the reader to a functional area matrix and just call
out the areas of the titles, rather than the wording we had earlier. I
thought we wanted it to be consistent between the document that we have
been building on functional areas. Which is based on a Laura Conn
article and then call out those areas that were selected after
deliberation by the entire group. So I don\'t know if anybody has any
comment about that. Okay, no comments. That\'s good.

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

I\'m sorry, this is Perry.

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

Yes?

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

Just a question. So you have \-- you took out the old number 4?

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

No, I just changed the A, B, and C.

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

I must have a different version. Okay.

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

Do you have today\'s version, Perry?

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

Yes, I do. I see it. They got renumbered. Never mind. I\'m with you.

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

I wanted them to be in sequence.

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

Yes, that\'s fine. I\'m with you now. Okay.

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

You can all read these through and comment on them. I want to point out
number 8, which is a new one. And it has to do with some of the
discussion we\'re going to have a little later today. It says
information transmission from data sources will require some filtering.
And that\'s one of the topics for today. Precisely what method. And
here\'s an example of receive everything except X, and that should be
italicized. Versus a specific listing of everything desired, should be
determined. I don\'t think we figured that out.

The purpose and principles of filtering, e.g., limited to specific
conditions, the avoidance of confidential information disclosure or the
public health evidence to support filtering should be explicitly
developed. So this precondition was one that came out of a discussion
that Marty, Laura, Scott, Kelly, and I had yesterday in preparation for
today\'s call. So I don\'t consider this in any way final, and you all
may comment on this, but we\'re now trying to insert something about
more specific about filtering beyond what had been in point 7, which was
already on your list from the last time.

Marty, any comments?

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

No, I think that captures the intent as we discussed the notion of
filtering, we thought there are some things we can resolve now, but
there are some principles or assumptions we\'re going to have to make in
our recommendation, and this is our first attempt to try to capture
that. As we move forward with some comments and recommendations around
the concept of filtering.

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

This is Perry. I think in general this is a good idea to include. My
immediate reaction or comment would be in the second sentence precisely
what method should be determined, I think a method of filtering as being
the \-- how we go about \-- the mechanism of how it gets done. I\'m
wondering if there\'s a different word, because I think what is meant
here is how will we specify what should be filtered out. Is that what
the intent is here?

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

Yes. So maybe there\'s another word than method.

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

Okay, I\'ll take that and go ahead and try to work on it and revise this
based on specify how will we specify. I\'ll try to work that through
there.

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

And this is Eileen. The one other point that I would make, and I\'ve
said this before and that when you look at item 5, that says will not
exceed 24 hours before reporting, every time we add a function or a
process on to this, such as a filtering process, that poses a potential
for delaying transmission of data. Because it increases the amount of
time the data has to be worked on at the originating source. So I think
we always have to be cognizant of the impact we\'re having.

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

Yes, and I think we\'ll have a fair amount of time to talk about
feasibility of some of these things later on in the call. But you\'re
right, each \-- I mean, we would assume that the filtering is automated.
But \--

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

But automated doesn\'t mean instantaneous.

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

So is the concept here \-- this is Marty \-- in number 8, what I\'m
hearing, if imposing or approach is to filtering, if it\'s not a method,
but precisely what approach is taken, may affect or could potentially
affect the timeliness of the reporting?

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

Correct.

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

Okay.

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

You know, and I\'m not saying \-- suggesting you change something, but I
think it\'s something we have to be mindful of.

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

Right.

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

Good point.

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

Any other comments? Okay. You know, the rest of these have not changed
that much, although I don\'t know what is the last version that you all
saw. I cannot remember. Scott, Marty, and I have been working on this,
and the last one where we had comments \-- and Perry sent me some
comments \-- or sent the three of us some comments, maybe about a week
ago, and it was on an earlier version where the idea of the
multi-jurisdictional concept was all kind of rolled up into one big
precondition. So the numbers 10, 11, and 12 have now been sort of
separated out from a prior version, which I think is the last one that
you all had seen. So maybe I should just allow you to read through
those. Those were pretty much embedded, almost a paragraph.

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

This is Scott. I think we have Lynn Steele on the phone also, and Kelly
has just joined us.

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

Okay.

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

Hello.

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

Terrific. Thanks for joining us.

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

Hi, ladies. We\'re going through the preconditions document, and we\'re
just kind of reviewing the changes that have been made. We\'re now
focusing \-- I hope you both have copies of the preconditions document
\--

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

Yeah, we\'re all set on this end, thanks.

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

Great. And we\'re now focusing on points 10 to 12.

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

Thank you.

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

Art, this is Eileen. There\'s a typo in number 9. It should be have
access. Minor, but \--

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

We\'ll take typos, too.

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

I think these are really well-written.

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

Okay, we\'re trying to get pretty crisp about this so we can present
this to the committee and the work group. So thank you. And a lot of
this \-- these points tend to \-- 10 to 12 really come from the NACCHO
document, so Paula, if you have any comments about that, feel free to
chime in.

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

Okay.

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

It looks good to me. Art, this is Eileen. I have a concern about item
13.

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

Okay. Where it says information will be shared in real time with
clinical providers. What do you mean exactly by real time? Because
presumably the public health agencies are going to want to review stuff
before they send it out. And so \-- and up above we haven\'t even talked
about really real-time. We\'ve talked about kind of near-real-time, so I
find the concept of real-time here a little bit overreaching.

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

What I would \-- near \-- would near-real-time be better?

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

Yeah.

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

Okay, that\'s easy. I think this was Ed\'s point that we really need to
be giving some of this information back. And it came out, I was reading
through some earlier notes, and \--

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

This is Ed. I am on the line now, I\'m sorry I joined late. I got my
time zones goofed up. The other thing you could do is say the system
will enable information from public health agencies to be shared in
near-real-time with clinical providers. Because I don\'t think we\'re
really specifying how that will occur.

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

Okay. So that\'s stepping back a little bit. We\'ll just say will enable
rather than will be shared.

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

Yeah, I think so at this point.

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

Okay.

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

Okay. Any other comments?

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

Yeah, this is Perry. In number 10, all jurisdictions capable of
receiving data should simultaneously have access to timely data. Is the
\-- obviously, I think that\'s a good idea, but the question in my mind,
is what this says, is the intent of this to mean that all jurisdictions
will have access to the same and all \-- and complete data that everyone
else is getting access to? This gets into the cross jurisdiction sharing
of data, which is a kind of a mess right now, I think, nationally, and
statewide. But I\'m not sure if we\'re going on record and saying that
all the data is equally accessible to everybody.

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

Actually, no. It\'s not saying that. It\'s just saying that if I\'m
capable, I should be able to receive the data I\'m legislatively or if
in some regulatory sense allowed to receive. Item 15.

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

15?

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

Or you could say capable of and authorized to receiving data.

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

Okay.

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

Yeah.

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

Okay. Because 15 really \--

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

Yeah, I see it now \--

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

The issue about who is authorized to see what parts. For instance, in
your state or in your county, where you might live, someone in your
county may have access to PHI, but CDC does not routinely receive PHI.

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

Maybe the place to put it for readability is all authorized
jurisdictions capable of receiving data.

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

Okay.

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

This is Marty. Maybe just organizationally we could move it closer to
the 10, 11, and 12.

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

So moving 15 up?

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

Yes.

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

Okay, so Perry, were you saying all authorized jurisdictions \-- you
weren\'t trying to change 15, you were trying to change number 10,
right?

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

Clarifying 10, that\'s right.

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

Thank you.

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

Correct.

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

But now we\'ll move that number 15 up to 11.

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

Uh-huh.

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

Okay. Any other comments on any of the others? I think the others were
pretty close to where we were. And I\'ll work on revising this and
getting it out to everybody, in the next couple of days. If there are no
other comments.

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

Looking good.

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

Okay. We started out, I went back over our documents, I think we had two
or three preconditions. We\'re now up to 16. So I think we\'ve really
made some progress in defining what we\'re doing. Should we move on to
the next area?

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

I think so.

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

So are there people on the line now to testify, or are we going to be
just reviewing the documents that were submitted? Scott, do you know?

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

Well, no one is going to give any oral testimony as far as I know right
now. I\'ve sent out six additional late entries this morning, along with
the three that were previously in. I see that we have Dr. Hinrichs on
the phone, too?

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

Correct. Hello, everyone.

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

Welcome. So I think those are, you know \-- all those encompass. Those
are for review and I think we just need to \-- any thoughts about the
oral testimony that we received last week, or last meeting, excuse me?

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

I thought they were helpful \-- I\'ve been working on that functional
area matrix. Clue in to some of those issues, we\'ll probably get some
time to talk about that a little later. But I thought they were both
helpful comments from both Farzad, and Shawn. They\'ll play right into
our discussion around feasibility today. I think \-- we really need some
guidance about this, and they were helpful.

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

This is Marty. I agree. And I think both the oral testimony and the
written have helped \-- get more specific and concrete in several areas.
I think our challenge would seem to be hearing it is one thing. Is there
a particular modifications or changes in our thinking in some way that
we would need to consider based upon these comments. Do we understand
their comments, I guess is the first question.

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

This is Eileen. You mean the new comments or ones that were made last
week?

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

I think either one. I think last week for sure and this week as well.
This is Marty.

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

And this is Steve. Is the one from Jason DuBois, the one we\'re saying
is new?

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

Yes. You should have received that in the package today. Was that in the
first package?

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

Yes, that was in the official package this morning, and then the six
that were sent additionally were an e-mail that was given to me about 15
minutes before the meeting. So I quickly wanted to get that out and we
have three officially on record. Jason DuBois from ACLA. We have an
entry from Tarrant, from Bill Stephens. And Ron Kasowski, I\'m sorry if
I\'m pronouncing that wrong, from Baylor Health Care System.

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

That\'s right, you pronounced it right.

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

This is Perry. We\'re having a fire drill and I have to evacuate the
building for a few minutes.

\[Laughter\]

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

So I should be back in a few minutes. My apologies.

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

We wish you well.

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

It\'s raining outside, too.

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

Oh, man.

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

Okay, I\'ll see you.

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

We had ours this morning.

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

I\'ll be back, though, I expect.

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

I guess the question I have \--

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

Has everybody had a chance to open up the document from this morning
from Jason DuBois?

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

Yes, I have. It has some very interesting points.

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

Yeah, I think that was a very helpful one as well.

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

I wasn\'t quite sure. This may get to some of the point you were making,
Eileen, about would the laboratories be reporting directly \-- or will
the places like the hospitals that receive those reports be reporting
those lab results?

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

That\'s certainly a question. I mean right now with respect to
reportable conditions we are required to report directly to health
agencies, as well as the clinician or hospital or whoever receives the
report. It\'s not an either/or situation. It\'s both. We pretty much
assume the same would be true now. And again, remembering that is
another processing step if you say you send it from the originating
source and somebody else and they would be required to report, keeping
in mind that we start out with this premise that we\'re trying to get
data quickly, that again is something else that would delay, I would
assume by a minimum of 24 hours.

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

Right.

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

Secondary transmission of that data.

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

Right. I think my concern is that so you anonymize at the level of the
lab.

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

Today we do lab.

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

No, today we do not.

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

In the last paragraph of this document, from Jason DuBois, he talks
about \-- at least \-- hold on a second. I\'m trying to \--

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

Anonymization would be a new step, because normally laboratories are
reporting data. Whether they\'re reporting it to a public health agency
or they\'re reporting it to a client, normally it goes with full
identifiers, because most compliance regulatory reporting requires
patient identifiers.

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

But my point is \-- yeah, I know it\'s a new step. My point is this.
That you anonymize at the lab and you want to link that up with some
clinical data, and the anonymization process from a hospital may result
in a different unique identifier.

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

You got it.

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

So how do we \-- how do we take data from a lab and link it up? I don\'t
know whether that\'s really \--

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

The only way you can do that is if another entity is created that first
accepts all of the identifiers from all of the different submitting
sources, reconciles them into some sort of MPI. Short of something like
that eventual no ability whatsoever to link records to each other that
come from different sources or even within a source in many cases. An
organization, I don\'t know that this is true of 100 percent of labs,
but I certainly know it\'s true of us and we represent a big percentage
of the clinical testing in the United States, we have no medical record
number.

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

Right.

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

Our primary interaction is with the ordering physician, not the patient.
So we track the orders, not the patients. So we don\'t have same number
from the patient. Even if the patient had five records once it was
anonymized or Pseudonymized, you\'d have five different numbers.

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

Does this have implications what \-- whether we should be asking the
labs to provide this? Let me ask Lynn this. If the lab said they would
give you the data to CDC, would this fit into the model you\'re using to
analyze the data? I guess I don\'t clearly know what you mean.

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

So a patient could go to three different institutions, have tests done
at those three different institutions by one lab, and there would be no
way to say that\'s the same patient based on laboratory feeding data to
Biosense?

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

That\'s correct.

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

So \--

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

Biosense doesn\'t have an identifier that can cross across healthcare
facilities.

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

Right, but we\'re saying that the lab is now receiving data from \-- or
specimens from a variety of sources. Would it be \-- even be valuable to
you?

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

This is Steve. One comment here is \-- it depends upon this level of
anonymization. The laboratory itself knows where those specimens are
coming from and who they\'re coming from. We not only have the name but
we also require something \-- some other second identifier like birth
date, et cetera. But are you talking about what we \-- when we pass it
on to the next level of reporting agency. Is that where you\'re saying
\-- that\'s where you would lose connection?

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

Right, at the point where you create the anonymized identifier before
you transfer the data on.

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

I just want to make sure it was understood that the laboratory very much
could determine that the same test on the same patient.

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

Well, depending upon your volume, not necessarily easily.

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

Well, yes and no. Again, what\'s automated and what can be.

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

Right, exactly.

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

And then back to the issue of what\'s required in the order. And
unfortunately, many large laboratories can\'t require the patient
address, or some other feature that helps us identify who that
individual is. But again, it could require that, or that is something we
could move towards.

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

Just to give you idea, just \-- and this is just for informational
purposes. We get patient address on about 65 percent of our orders. We
have \--

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

But a study. In fact, it\'s good for this whole group to hear that,
because again, what we then get called back on from to say the health
department state or county, whatever it is, if we can\'t supply that
address to them, and we can\'t necessarily even sometimes supply who the
ordering physician; then they don\'t know what to do to follow up and
who to talk to on that.

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

Right, all we know, in the 35 percent of the cases where we don\'t have
a patient address, we always do know the location of the originating
order. But as Steve said, it may not be the level of the physician
because the originating order may have come from a hospital.

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

Right.

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

So they twist our arms and say you\'re required to come up with that
information. We can\'t come up with it sometimes.

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

Yeah, nor can we.

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

So then let\'s also look \-- so this lab test that goes to Quest and
goes back to a primary care or in-patient setting, something like that,
where the test was first ordered, will they be reporting the results as
well? Will there be duplicate reporting?

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

From what I understand, that\'s the way it works today. At least that\'s
what\'s required. I think what is \-- and I don\'t work in the public
health department, so I can\'t say this for a fact. The but I\'ve been
told from a number of people that in fact they don\'t get the level of
reporting from individual clinicians that they would hope for. But it\'s
very difficult to enforce because there\'s no way to really know for
sure whether or not people are reporting.

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

Well, I can say from a public health point of view, I mean this happens
all the time. I know we don\'t get complete reporting, but that\'s why
we have a disease investigator and someone who is going to work the case
and un-duplicate what appear to be two cases. And all that\'s worked
out. But that\'s a lot of intervention. We\'re talking about a data feed
to CDC, so what will be the use if there\'s repeat reporting of the same
case with different anonymized unique identifiers? I mean, isn\'t that
actually creating a problem for analysis?

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

Yes, because at this point in time, I mean it might be that eventually
you could come up with a mathematical adjustment, you know, for what the
average repeat rate would be, but it would be a long time before you
would have an update to do it on a disease-specific basis. Because the
repeat rate would certainly be different for different diseases.

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

Well, I think keep going with your logic, because it leads to the
ultimate saying we\'ve got to have some way of knowing how to
de-duplicate.

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

Right, and obviously one of the things that was discussed in the HITSP
was this concept of the anonymization service that would take in the
actual patient identifiers and churn out a single unified anonymized
identifier and therefore people could link it. But the service is a
wholly theoretical, you know, entity. I mean, there is no agency or
other entity that I\'m aware of stepping up to say we\'ll be happy to
handle this effort. And there also were concerns from a regulatory
standpoint that if you did that, particularly if you did it on a
national basis, you would effectively be creating a national patient
identifier, even though it was technically, it would be a national
patient identifier and because there\'s been legislative resistance to
doing \-- to creating such a thing, we\'re not sure if that would come
under attack for being a kind of a back door approach to creating a
national patient identifier.

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

This is Lynn Steele. That\'s right of the we can\'t have a national
identifier. That\'s been made clear. I guess if we could, we would use
Social Security numbers, right?

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

Yep.

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

From the perspective of BioSense, it really is a bit complicated in
looking at \-- and thinking about the strategy for getting lab data. The
way BioSense is planning to handle receipt of lab data and the analysis
of that data, is to really look at the data streams that come from the
clinical setting, hospitals, outpatients, data, emergency departments.
Separately from the commercial laboratory data. Meaning we know that
many of the healthcare facilities will outsource some of their lab
tests. That data will come, hopefully will come as part of the BioSense
data feed and that data is analyzed on a facility level. So to look for,
you know, specific characteristics of that data at the facility level.

It will be a different analysis to look at real-time results from the
commercial laboratory. We know there will be some redundancy in that the
same data may be reported in a jurisdiction from \-- directly from a
commercial lab, as is coming through the hospital IT system.

But from a biosurveillance system and information perspective to inform
public health that something is going on, to prompt investigation, we
think that\'s okay.

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

This is Ed. I just want to emphasize that because if you\'re trending it
over time, presumably that duplication percentage going to be relatively
constant. So it should trend out over time and still show your spikes.

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

Correct. That\'s what we think, too.

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

So is this yet again another precondition that we need to state as we
sort of look at this and say that there should be a separation of
facility versus laboratory data analysis? I mean, is that \--

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

No, I didn\'t mean to imply that at all. We\'re getting laboratory data
and laboratory results from healthcare facilities. But because so many
of the healthcare facilities outsource some of their laboratory tests,
and those come \-- you know, those will just come as results on a
jurisdictional basis, they\'re really not equivalent data sets.

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

I hear what you\'re saying.

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

All right, I just \--

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

I didn\'t say it right. But I hear what you\'re saying. There may be lab
data from a hospital facility that\'s reported that could be integrated
with all the utilization data as well. And \--

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

The clinical data. And the other information that would help you
interpret events.

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

Okay. So maybe we need to consider that, to call that out. Because I
think the early part of this conversation where Eileen and I were kind
of going back and forth, I think there was \-- it was not clear that was
an expectation of the analytic process. At least maybe we need to make
that clearer. You knew, it Lynn. So thank you for explaining that.

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

I just think whoever pointed it out, because we can\'t have an
identifier that followed the patient for many, many reasons. We just
have to come up with a solution that is workable to provide as much
information to local public health as possible.

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

And encourage them and be smart about how they interpret it.

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

Correct, we have to develop that expertise. I think we all do.

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

Lynn, are you saying that what you hope to get out of BioSense is the
\-- to determine or find something that should spark interest or
concern, and then you\'ll go back and you alert the local area or local
responsibility to look into it?

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

We alert them or they are also looking at their data and we help them
interpret it, right? I mean, if we\'re talking about simultaneous access
to data. But yes, then investigation is local and just as someone
already said, you can get notification that something is going on, or
reportable disease from the hospital, or the clinician providing care.
You could also have that same case identified to you by a lab report. In
some cases they\'re going to be redundant. And I think what we\'re
saying is BioSense and biosurveillance systems will also have some of
that redundancy. But again if the purpose is to help interpret the
beginning of an event or to identify additional cases that need
investigation, that redundancy can be accepted.

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

And I would suspect that today most public health departments recognize
that if a condition is verified or diagnosis is made on basis of a
laboratory test, and it\'s a reportable condition, they probably are in
fact getting it from more than one place, and they probably do factor
that into their analyses now.

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

Well, it gets down to really human intervention. Someone has to look at
the case.

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

Uh-huh.

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

Just \-- and I don\'t know that we\'ll have that person power. At least
not in the first pass. Maybe once there\'s a spike I\'m sure there will
be plenty of human intervention.

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

Art, this is Marty. There\'s another issue that I think it\'s related to
this. In the first part of the letter from Jason. And that is that the
notion that a minimum dataset isn\'t necessarily a solution. This is my
interpretation. A solution because a lot of local jurisdictions have
more than the minimum dataset which still will require these special
interfaces. And it\'s \-- although it would \-- I would take from that
that a call to support more of a uniform dataset for \-- particularly
for reporting purposes, that if there\'s laws that require more than the
minimum, then it\'s helping some. But there\'s still a lot of custom
work that needs to be done. So the next \-- the would seem to be either
a standard dataset or uniform dataset across state agencies wherever
possible. Is that a fair assessment of that concern?

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

This is Eileen. I think that\'s a fair assessment of the concern in one
way. But I\'d like to go back to something that Steve Hinrichs said
before, which was what you have to do to try to get the data that you
didn\'t originally get before you report it, and part of the problem, we
actually once created a internal initiative to see if if we couldn\'t
internally create a standard process for getting this. But there\'s so
many data elements required by so many different public health agencies
that required us to have people calling doctors' offices and begging for
information that if you create a superset, you\'re spending time doing
that for data that the public health agency didn\'t need or want in some
cases. So there probably isn\'t realistically a way that I see in the
foreseeable future, to create a standardized minimum dataset that will
in fact meet everybody\'s current individual programmatic needs without
creating an enormous excess burden collecting data that nobody wants.

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

So what is the expectation of what is going to happen when this
requirement for a minimum data set, meaning will it become mandatory or
federal law that this information is collected on the laboratory test
for example in is that a goal?

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

Kelly, can you help us?

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

Kelly, still there?

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

In terms of whether this would be required? You mean how these
recommendations would be recognized by the Secretary? You know, I think
that it depends upon how everyone \-- we\'ll have a group think on this
internally about how specifically we\'ll operational lies the. But the
intention is to take the minimum dataset and to use it certainly with
federally-funded efforts as a way to guide, you know, what should be
capture. As we do biosurveillance programs. But there\'s also, I guess,
a hope that beyond what the federal government is it, there will be
agreement between the state agencies that participate, that this is also
the right dataset for them to be using as well. So for these efforts
that we anticipate will be really across all levels of public health, as
we\'ve stated in our assumptions, this \-- the intention is that this
minimum dataset will work for everyone.

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

So to follow up on the issue of the minimum dataset, are we perceiving
then that it will be different inside of the local jurisdiction, i.e.
the state? And then the federal government? Because this issue of
anonymization, meaning locally, the minimum dataset will have to be
expanded for it to be sufficient for the local jurisdiction. But this
will then only be sufficient for the federal government ; is that right?

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

I think it\'s really up to this Workgroup\'s judgment. The assumption
moving into in that higher level is if we can get the right level of
data, including anonymized data, that should be workable for all levels
of public health. For local, state, and federal agencies. Now, if in
fact there\'s going to be some need to have more specific identifiable
data for a local jurisdiction to do more follow-up investigation, then
that should probably be specified in your recommendation.

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

Well, that is \-- that\'s the point that was number 15 on your
preconditions, that local jurisdictions as Steve points out, local and
state, would be allowed to see PHI, whereas, this minimum dataset we\'re
defining is trying to target staying away from that.

So it is a subset of what would be reported to a local agency.

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

And that\'s all I'm trying to emphasize and make sure everybody is clear
on that. Locally, this minimum dataset is not sufficient. If it\'s an
anonymized.

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

For local activity, right.

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

That\'s correct.

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

So it\'s only a minimum dataset at the federal level.

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

That\'s correct, and I think what we\'re trying to do here is
acknowledge that the implementation should consider that there are local
data need and requirements that will need to be fulfilled by the data
sources.

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

I think that\'s appropriate to include in the assumptions and any
recommendations that move forward. I would just be mindful that in the
feasibility assessment we need to think about, you know, what are the
ramifications. If you\'re talking about a larger dataset being used in a
local level. Particularly if you\'re thinking about transmission every
24 hours.

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

Well, I think I\'m talking more about \-- this gets back to what Mr.
DuBois is saying here. We spend all this effort to communicate to local
health agencies. Don\'t make it harder on us to connect to yet another
one. Can we somehow leverage what we\'ve already done? That\'s where I
think Marty was taking us back to.

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

And I\'m saying this could make LabCORE and Quest at risk financially
because they have to have the ability then to not only report locally
with it being a full record or an expanded record, and they would have
to have the ability to report nationally in an anonymized way, which a
local smaller laboratory that doesn\'t operate outside of the state
jurisdiction, whatever that jurisdiction is, wouldn\'t have that
expense.

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

This is Scott. Can I pose a question to the group at the point where
we\'re getting into what is sent to what jurisdiction, I think we\'re
getting number one, into the filtering part, but number two, would the
local jurisdictions at a minimum encompass the minimum dataset and as
you said, it would \-- expand out, correct?

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

Well, this is Laura. I guess I\'m getting a little confused and
concerned. What we have been \-- I thought we had always been talking
about is the same data going to all levels at the same time. And not
requiring clinical care to send different messages to different levels
of public health and making sure we had those linkers in there such that
local public health can go back to the source and get the additional
data that they need to do follow up, appropriate public health followup.
So I think we\'re off on a different conversation now. We\'re talking
about sending different messages from clinical care, different levels of
public health.

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

This is Paula. I think the issue that we\'re getting into here is that
we really don\'t have a good grasp, I think, on all of the data that is
being collected by the many, many different surveillance \-- or
biosurveillance systems out there, to know whether or not we are
capturing in this minimum dataset, what is already being captured, or if
it there are quite a few missing data elements, or if we\'re doing more
than most.

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

I think that\'s what the work of this group has been over the last month
or so, is to get people who are doing this, to weigh in on the minimum
dataset, that\'s part of the feasibility question.

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

Sure, but we really haven\'t done a data elements analysis to know.

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

Well, we started one in the broader group, and brought that over. I
think this is not as much data as most \-- different cases some people
are collecting already.

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

And I guess what I\'ve been struggling with, since the beginning, is how
we actually implement a minimum dataset. I mean, what does this really
mean in practice?

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

Well, I think the Secretary\'s goal was to have broad implementation
nationally, so we were targeting something that a lot of clinical care
providers could participate in.

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

Right, but is it at the expense of progress in electronic lab reporting
for communicable diseases? I think that\'s sort of the tension that\'s
building here, is that as a desire by the Secretary to have a minimum
dataset, but the labs already have relationship with local health
departments and state health departments to report what is their
obligation.

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

Right.

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

Already.

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

And when we start getting to a minimum dataset, as Mr. DuBois is saying,
now you\'re going to have to create a different mechanism for reporting
the MDS, versus the one that we\'ve got going with 3,000 local and state
health departments.

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

And this is Eileen. I can tell you also that some of those local
requirements are very, very specific and very, varied. For example, in
New York City, every time we do a HIV genotype, we have to send them the
gene sequence. Now, that is not something that you\'re going to require
on virtually any other reportable condition. And so to create a
superset, as I said, we once started that effort internally and
attempted to create a superset list of everything currently required,
and it was enormous.

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

This is Perry. I just want to let folks know that I made it back without
getting wet. And I\'ve been listening to this conversation for the last
few minutes, and have some concerns. It sound to me that there may be
the perception of some of the discussions that the minimum dataset that
we\'re discussing is going to replace local or state reporting for
public health purposes, and I don\'t think \-- I don\'t see how that can
happen for \-- like Eileen was just commenting, one example. There\'s no
way that I can see that Quest or LabCORE or HMOs or anybody that has to
report to state and counties, is going to be able to meet the reporting
requirements through this database. I look on everything we\'ve been
discussing as another reporting system because I don\'t \-- even if a
lab result comes through the minimum dataset, that\'s reportable, we,
and I suspect there are 49 other states around, will also require it to
be reported with names through their own reporting system. So I\'ve
looked on this discussion as a way of \-- the other thing I would say
is, obviously this is a \-- these are administrative datasets that are
\-- that include information, conditions that are not reportable. It\'s
very different. It\'s apples and oranges from the routine public
surveillance. It facilitates it and it will help local and state health
departments identify additional cases, perhaps, and do all the other
things we\'ve talked about. But it\'s very different, and so I think
it\'s a misconception to think this will meet or replace, I should say,
replace some of the reporting obligations that are here already.

Now, some day, maybe 20 years from now, it will, but we\'re just not
there yet. And so for our lifetime, or for our career time, I think
we\'re not talking about replacing any current reporting requirements.

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

So then we are talking about, as Mr. Dubois says, a 3,000 and 3,001st
data stream, which is different than the ones that already exist and
this may result in some costs to the reporting laboratories.

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

This is Paula. I guess my larger concern, because I never considered
this to be the same as communicable disease reporting, but how does this
minimum dataset impact existing biosurveillance systems that are already
in place at the local state and health departments, and BioSense for
that matter?

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

This is Eileen. I think two things are \-- in addition to being the
3,001st, part of the way it affects the other systems is competing for
resources. Because right now not all reportables are transmitted
electronically. So there are ongoing efforts to increase and expand and
improve the reporting that\'s done electronically today and so this
would be another item on the list, it would be competing for some of
those same resources to get done. And the other point I would make is
that this does not just affect laboratories. I mean, this letter came
from Jason DuBois who comes from the American Clinical Laboratory
Association, so he\'s obviously speaking on behalf of laboratories. But
the same impact would be true for any other provider who crossed
jurisdictions.

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

Absolutely.

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

This is Marty. What I\'m certainly hearing, the \-- Jason DuBois\'s
letter, as it\'s supposed to have done, or made the issue, I think very
practical about the feasibility and the concerns that are here. I think
they\'ve been nicely just summarized by Paula and Eileen. That there are
potential impacts of related to additional system, potential impacts
related to the existing BioSense-type syndrome, surveillance systems
existing and impact on communicable disease reporting pieces. And those
relate to the point about practical feasibility. It seems we need to at
least take that into consideration as we comment on these. Art, and just
a time check here, I think this, in terms of feasibility, we want to
make sure we understand their concerns, and I think this has been a
great discussion to, as we get the feedback, and we may want to check in
on the other testimony as we have a few minutes left here before we move
on to the dataset.

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

Thanks, Marty, for keeping track of the time. So which one would you \--
are there any last comments about Mr. DuBois\'s letter?

Should we move on to one of the others? We only have about another five
minutes or so in this section.

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

Art, I just wanted to make a brief comment. This is Kelly. I think it
might be helpful for us as we continue our discussion around the
testimony and feasibility, to think in terms of where something is
perceived to be not feasible because of the burden on certain providers,
or the lack of infrastructure, if only 18 states are able to receive or
transmit public health information electronically. I mean, I think it\'s
important to note what the Data Steering Group feels to be necessary and
important for public health, and if \-- and make some determinations as
we go along about what is going to be needed to implement the minimum
dataset. So there\'s going to be sort of a tradeoff assessment, I think
we\'re all going to have to be considering, about what \-- at what point
do we recommend that this data be part of the minimum dataset. It may
not be feasible across all jurisdictions, across the country. Yet we
feel it\'s important enough, you know, at this point in time to be
inclusive with the caveat of needing additional resources to not impact,
you know, the existing reporting of communicable diseases or to not, you
know, underestimate the resources that would be necessary to have
additional infrastructure to meet the need.

So I mean it\'s premature to say how anyone will come out on this, but I
think we need to be thinking about this tradeoff, and whatever comes out
of this process you can caveat what you think is going to be necessary
for implementation.

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

Kelly, this is Steve. That\'s fine in terms of resources, but there\'s
also an underlying difference in philosophy. And so how do you address
that?

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

And what aspect of philosophy are you talking about?

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

Well, I think so on one hand, if in fact we believe that it\'s important
to monitor the occurrence of a certain number of diseases and
conditions, then why isn\'t that important to know nationally as opposed
to only know it locally? And it\'s back to this issue of well, that\'s a
state responsibility and concern as opposed to a national responsibility
and concern. And I think what Perry was just saying is that, well, maybe
20 years from now we\'ll perceive this or accept it. But it\'s not
accepted now.

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

That many of these are of national concern.

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

Yes.

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

Yeah.

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

And I think we\'re fooling ourselves. If we really believe they\'re of
national concern, then why aren\'t we willing to process this data and
submit it nationally?

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

Well, then, you know, I think it\'s going to be something we have to
address head on and not avoid it. And if it\'s only a subset that people
can agree on, that should be of national concern because of the
implications of the pandemic or the short-term public health needs that
we\'ve agreed on that are applicable to all levels of public health,
then we need to have an honest, straightforward discussion about it.

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

So maybe some of these things will come out as we get into the
feasibility discussion.

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

Feasibility and I think filtering. This is Marty, Art. That\'s the
concept that I\'m hearing here. It\'s not so much the reporting as
perhaps the system and approach. Is what I\'m hearing. In terms of
what\'s needed nationally versus the local responsibility.

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

We were moving on to either the other feasibility pieces or we can move
right into the minimum datasets, Art, if people want to provide comments
or discussion from the other two pieces that we\'ve been provided.

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

I think we should move on to the next discussion and ask the committee
members to comment back in writing when they get a chance to read
through the various documents from Tarrant County and the southwest
center and then this other document from Mr. Jawoski. Is he also \--

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

Kasowski.

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

Is he part of this same jurisdiction, Bill?

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

He\'s part of the regional network that we\'ve set up here and I\'ve
been listening to a lot of the discussions here we\'ve had going on
which are reminiscent of a microcosm of a discussion we had about two
and a half years ago we started this whole network and I think \-- I
can\'t help but wonder if a lot of our discussions regarding the
feasibility or effort required or whatever, really stems back to what I
would call a value justification that we had with all the other
hospitals and stakeholders in this area two and a half years ago before
they knew the application and this is really the key. So much of the
time the effort or the perceived effort, the cost, you know, to change
the time that it takes, the money it takes and so forth. Stems back to
almost unspoken things that people are expecting to say what\'s it going
to do for us locally. You know, to have a national perspective or go to
all the effort at a local level to give this national visibility, and a
lot of that started going away after year one as the local stakeholders,
that is where the rubber meets the road, where people had to come up
with the resources to establish and maintain the datasets and we\'re
doing obviously the smaller dataset than the 61 pieces. But we have, two
and a half years later, people ready to move towards a large part of
this minimum dataset in our stakeholders because they\'ve seen after the
first year and a half the value of the application of having a larger
regional perspective that they never saw before. I can\'t help but
believe that\'s part of what we\'re struggling here where people are
looking at the cost and complexity and inconsistencies of this minimum
dataset when what it really boils down to, they don\'t know what value
the national perspective is going to add. Because we haven\'t shown it
to them yet. That\'s what that one final report makes one stab at and
we\'ve had a complete turnaround since this efficacy testing has been
done to show there really is sort of a regional system that can check
this data and really justify something of value to all the stakeholders
that they really were kind of doubtful could ever be done. And we may be
in a similar situation here. With some of these stakeholders we\'re
talking to, even though they may not be able to articulate what\'s
bothering them about this. Corner other than it costs too much and it\'s
too complex and we don\'t want federal level people having this kind of
burden on us.

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

Thank you, Bill. I don\'t know either, I don\'t know whether we have a
clear value statement for what we\'re doing. And I think Marty and I
were hoping some of it would be (indiscernible) as we start going
through each data element regarding how it might be filtered and whether
it\'s feasible, be able to capture some of that value in this next
discussion.

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

I think it\'s so much more, though, Art, than just in the filtering and
the preprocessing of the data. It\'s the visualization, the analytics,
and all those things that go along with it that really give, you know,
the sort of the live nature of this thing, and you negotiate the time,
whatever you call, it the time sensitive urgency to the thing that
people say, when they see it, they finally realize oh, gosh, yeah,
that\'s, you know \-- I mean in our case it\'s counties and other health
departments and hospital systems that want to know on an aggregated
basis that something that hasn\'t hit them yet may be coming their way.
Smoke or some of those kinds of notions anyway, that really \-- that
really tell them oh, that\'s what the value was. And it wasn\'t that
anybody was trying to control their backyard. They were really trying to
get, you know, accurate early warning or situational awareness that they
had never before seen. And that\'s in the application. That\'s in the
visualization products. That\'s in the analytical products that are
going to come from the use of this data, rather than just the
prefiltering and, you know, the inherent value of the data elements by
themselves. I think we all know \-- we have an intuitive feel for
that\'s what\'s coming but it\'s very hard to articulate that value
proposition at this point to the stakeholders.

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

So we\'re now about six minutes beyond this section of the agenda.

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

This is Eileen. Could I just say one last thing? Having looked through
most of the other comments that we \-- I didn\'t read the long
continuing thing but I read almost all the others. The one thing I would
point out is almost every single one of them was mentioning additional
data elements they wanted added and why.

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

Right.

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

And so just as a concept, you know, as we talk about this discussion, I
think it\'s important to note that. And that\'s my comment.

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

As \-- this is Marty, Art. Perhaps a note here for Scott. One of the
things that we could probably do then is to go through and maybe we
could summarize what are the \-- either concept data addition and what
it is sort of boil it down into some synthesis of these comments for us
to look at the perhaps the next call, something like that.

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

Good idea, that\'s a great idea.

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

Not a problem. Bill, is there a table within the Tarrant County that you
all have provided?

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

No, but I can do that. I\'ve done that sort of mentally here, and was it
Eileen\'s last comment about people wanting more in some cases, at the
local level, I think there\'s another clue there. They\'re not really
opposed to even adding things that they\'re not currently electronically
collecting in some instances because they see the value if locals are
willing to collect more, what\'s the opposition to giving less? And I
think again it\'s that value proposition thing. So I think we should
summarize all those things, and I think there may be some useful
patterns that may emerge from analyzing it that way.

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

Okay. I think I\'ll take the action item to go through some of these
testimony, if you\'ll work with me, Bill, on that, and then we\'ll
present to the group.

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

You bet. I will.

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

Okay.

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

I would say these people are saying they\'re willing to receive more
data. Most of the burden for generating and sending it elsewhere.
They\'re not indicating they\'re willing to do more work to collect it.
They\'re wanting the data collected for them.

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

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

I think those are two very, very different concepts.

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

I agree. And they\'re both. I mean, the stake holders that we dealt with
are willing, you know, as we\'ve already talked with them, they\'re
willing to do more. I can\'t say I\'ve analyzed in-depth all the inputs,
but some of the ones we\'ve actually agreed to do more than what the
minimum dataset is. So you know, again, I think it\'s a question of
really sorting out why the people are objecting to it that see it as an
effort of cost, a burden they don\'t want to bear, and I think in most
cases it will go back to they don\'t perceive the value-add or value
proposition it\'s going to bring them in their operations. And I think
that\'s \-- I think that\'s an issue to address, but I don\'t think it
will be extremely difficult to overcome.

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

This is Paula. I guess my concern is with a minimum dataset, if we are
taking this to LabCORE, Quest, some of the large healthcare networks,
organizations, what do we say to them? Are we \-- what\'s the message
that we\'re hoping gets put across that this is what at least what
they\'ll provide? And that we still want them to work with states and
locals to provide additional? Or are we saying this is all we want you
to provide? I\'m specifically speaking to the large organizations that
cross jurisdictions.

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

Yeah.

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

I mean that\'s a message that I\'m concerned about. And I\'m completely
for a standard set that everybody is going to capture. But just how will
this impact the additional data that some may want to collect?

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

Well, this is Marty, and I think perhaps a note here is that where
we\'ve uncovered the whole issue of implementation issues. And while we
move from a standard type of set into a longer-term goal, there\'s going
to be some excess burdens on many of us, submitters, receivers, as we
move toward a transition and that needs to be looked at, examined, or
try to minimize wherever possible. Very good points.

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

So the take-away from feasibility testimony is everyone will read it
again, we\'ll work with Bill and Scott to help us sort of summarize
perhaps by submitter or by receiver, some of the key points from each of
the feasibility comments. So we can look at it in sort of a summary view
of the key elements. Won\'t capture everything point of view what are
the key messages relevant to our data set. So we can look at that and
decide if we need to take particular action or concerns or note them in
our report.

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

Okay. Sounds good.

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

Does that wrap up this section?

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

I\'m sure I\'m going to hear one more comment. Just one more. This is a
great, great comment and discussion.

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

I\'m hearing a long pause, hopefully, so should we try again to take a
look at our notion of feasibility and filtering, Art?

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

Yes. I think so.

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

Okay.

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

I think some of this is going to come back into this discussion.

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

I think so, too. It all is linked.

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

I think, too, with the additional elements that Bill and I will pull
out, we\'ll go through the process again with those additional elements,
and you know, it will come out whether it\'s feasible on the sender or
receiver, and whether you can \-- you know, so it\'s \-- it will take
\-- we\'ll take a look at all these, sure.

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

Do we want to Scott, and Art, perhaps set a bit of the context for the
feasibility and filter discussion? We\'ve got the spreadsheet to bring
up. We have sort of a conceptual definition for each. What do they mean
and what do we want to try to achieve this first pass.

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

Right, if everybody would kindly open or \-- it\'s tab 2 of the minimum
data set.

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

Yep.

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

And if you notice, we\'ve just added two quick columns there, whether
it\'s feasible or filtering, and I\'ll let Art and Marty take over from
there. But I\'m going to try to capture whether the group thinks it\'s
feasible or not and take a consensus. We can certainly discuss these
further, but I\'d like to start getting a baseline so we can move
forward. So I\'ll turn it back over to you, Art and Marty.

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

Art, do you want to start with we\'ve had a little discussion around our
definition issues.

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

Right.

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

Just open a document here from yesterday. It comes back to we can look
at this preconditions document where I\'ve added this bullet number 8,
about filtering. And you know, precisely what approach rather than
method. So should we receive everything except X, versus create a
specific list of everything desired. So those are two different
approaches to concept of filtering. And what we\'re trying to do with
this document, this Excel sheet, is just run down this list and see, do
you think that anything on the line, on the row, implies a requirement
to filter? So we\'re just trying to get the broad view here. We\'re not
saying how to do it. We\'re just saying should we be considering
filtering, yes or no? Or that \-- for that data element.

And then I think the other part of this is around feasibility and really
this is where we\'re going to get back to the discussion we\'re having,
which is how reasonable is it to expect someone is going to be able to
do this in a short-term, let\'s say within the year? And if it\'s not,
make comments about that and maybe even comment a little bit about some
of the value, as Bill was trying to point us to, about what would we see
as valuable that might sort of change the way that we look at the
feasibility? This is one approach. I think before we jump in \-- and
Marty and I spent some time, as I said, yesterday, discussing this with
the people from ONC. What would be a first pass at this. And before we
jump in, maybe Marty may have additional comments or those from ONC
might chime in here. And then I think I would open it up and ask the
group, does this sound like a method we can kind of run through and Bill
said there were 61. I don\'t know how many there are right now. But we
can run through these data elements just to take a first pass and say
okay, we don\'t need to worry about this filtering for this one,
feasibility. We think this is feasible. And without filtering. And then
the next time through we may define what do we mean filtering for a
specific element. So I\'ll stop there and ask Marty to comment.

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

Thanks, Art. I agree. I think it perhaps is capturing the comments here
that all of our best judgment at this point, we know this is not
perfect. and welcome other thoughts on the approach as well. I know
Scott is looking for more precise definitions of the notion of
feasibility and filtering as well.

And we will try to incorporate and use that and then as we run through
the passes here. I\'m hoping that we can kind of gather in two general
areas. One is that there\'s general consensus around yes, and general
consensus around no. And perhaps a fair number in the middle. In which
are going to need further discussion. But if there are generally
speaking information is available and \-- or feasible, then to collect
it, then it makes sense and we want to identify that.

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

This is Perry. I would, in terms of answering the filter question
yes/no, I think it would be \-- I hate to say this because it\'s going
to take time. But I would need to think through personally or have the
group think through a little bit about the criteria on which we\'re
making that decision. It seems that the first step would be to say, what
are we trying to accomplish with filtering, because it\'s still vague in
my mind. Otherwise I\'m afraid we will have varying criteria by
different people and maybe even across the discussion, from time to
time, within any one person\'s head as to what we\'re doing. So it would
help me to \-- if somebody could say, maybe as a straw man, this is what
why we\'re filtering. And then see if there\'s general agreement that\'s
the concept that we\'re all working from.

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

Okay, so we went through this a little bit yesterday. There could be
limiting of a subset of a record based on some specific value. Or a
specific condition. We could just limit our entire activity to targeted
biosurveillance work. We could limit our work specifically to avoid
release of confidential information, let\'s say someone has a
psychiatric diagnosis that we don\'t want to let that come into the flow
of data. We could limit an entire record for high-profile individuals.
So we could just say the mayor is in my hospital and we don\'t want to
send anything out for him.

So I don\'t think we have the full sort of taxonomy of limitation here,
or filtering. But \-- and maybe if we need to, let\'s go ahead and list
those out so at least the group is clear. I think we were just
brainstorming yesterday about this, and trying to figure out what is
filtering. We don\'t have a definition and we don\'t have a clear
purpose. That\'s one of the things that\'s written in the \-- in that
point 8, there\'s neither a purpose nor guiding principles for why we
would filter. And we need \-- those need to be clarified. We\'re hoping
the group will help us get there to some degree. Some of this may have
and some of this may have to be done by others afterward.

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

This is Perry again. Let me say something that might shock the group
since it\'s maybe out of character for me to say this. Being maybe the
conservative person looking to collect less data rather than more but
maybe to play devil\'s advocate here. Make we don\'t need to filter
anything. And if we have selected the minimum dataset appropriately
confidentiality is protected. Sensitive information is not being
transmitted. So what if the hospital sends us all their psychiatric
admissions, none of which are reported to public health, and maybe none
of us can think of an example where we would want to \-- or would need
that information for any kind of public health emergency. So what if
they send it to us? It would be easier and cheaper for the hospital to
dump everything and if we design the minimum dataset appropriately, I
think that extra data won\'t hurt. It may be useful to us, but \-- so I
guess \-- I\'m not sure I know the answer in my own head to this
question, but I guess I\'m wondering why we would need to filter at all
if we\'ve done the rest of our job correctly. Or well.

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

This is Steve. I\'d like to be respond. And Lynn has another perspective
we\'ll want to hear from. One issue for us is that we\'re required to
keep a record of every data element or data report that we send out of
our institution. Whether or not it\'s public health, it\'s required to
keep a record of. I suppose you're saying it might be easier to say
well, we send everything out. But I don\'t think that\'s quite the case,
because we also have to be able to respond to a request from a patient
as to who and where any of their results were sent.

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

This is Eileen. I have an additional perspective on it, which is the
question of thinking about who is getting this data. If you do no
filtering, the quantity of data going into a system, is going to be
staggering. It\'s going to be something that probably not anyone has
ever handled yet. And can assistants handle the volume. We load ten
million records a night. And we\'re just one facility. Who is going to
be getting all this and can their systems accommodate if you don\'t
filter? Even if it\'s a minimum dataset in terms of number of fields.
The number of records would grow exponentially.

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

So you\'re saying one of the reasons to filter is to decrease the size
of the filter \-- of the database.

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

That\'s my assumption, and because then the larger your initial data
feed, you have data loading on the receiving end, and the need of
processing and running queries degrades, and if huge percentage of that
data is of no practical interest, then \-- that\'s my assumption, why we
would filter, is create a dataset more targeted on the need.

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

That\'s sounds like one very good criteria. We need to decrease the size
of the database so it\'s more manageable.

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

I know we\'ve heard from several of our members quite strongly that they
have major concerns about privacy and confidentiality if if the data is
not filtered. They simply don\'t want information that they don\'t need
and feel they may also not have the legal authority to collect it.

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

This is Lynn Steele, and Laura Conn can probably also comment. Having
sat through lots of these types of conversations, especially last summer
in making decisions about what goes into the BioSense messaging guide, I
think we have to think about what we even mean by filtering. If you
filter, certainly we\'ve made decision that is we\'re not receiving all
laboratory results. But rather those that are related to microbiology.
Because those have the most close link to a public health use. And the
decision to receive all microbiology or microbial results was made. So
we filtered on the data \-- or on the category level, or the data type
level. But then when you start talking about whether you\'re going to
filter specific results out, some of them are markers that might relate
to HIV infection, for example. That\'s when you get into even more
issues of feasibility. So it\'s one thing we\'re only going to receive
this HL7 message. We can technologically do that. It\'s another to say
we\'re going to read each of those HL7 messages to see if it contains
this specific result. So we made a decision of course not to do that.
But I think the point being especially in addressing the privacy issue
is we should \-- public health should only be receiving data where
there\'s a public health use for that data. So the idea of filtering
HIV, for example, as a priority, would limit the population that you
were most interested in. It could eliminate one of the most vulnerable
populations that would certainly be needed in community biosurveillance.
Similarly, if you can make a use case for why you would want
psychological diagnoses as an aftermath to a catastrophic event in order
to understand who is seeking those types of services and how to provide
the appropriate public health interventions there. So I think this whole
exercise and discussion about filtering really needs to be aligned to
the public health use of that data. And those are the decisions we\'ve
tried to make with BioSense.

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

Have you listed those use cases?

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

We have use cases that were example use cases for how we would make
these decisions last year. But they\'re not in \-- they\'re not in a
written out format or we didn\'t spend a lot of time on defining those
use cases.

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

Might we receive from you even a listing of those and one liner that
says \--

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

Yes.

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

I mean \--

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

What we\'re talking about are those sort of one-liners.

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

That\'s all I\'m saying. I\'m not expecting you have a fully developed
use case. But at least for us to create some context in which to have
this filtering discussion.

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

Yes, and Laura, is there anything you want to add there? Since you were
part of these discussions as well.

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

She had written to me that she needed to drop off by 3:00.

**[\>\>\
]{.underline}**I\'m sorry, sorry to out her.

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

This is Marty. Lynn, did you use a working definition for filtering, or
just a description? In those documents as well, something that might be
useful here?

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

We did. I\'m going to have to refer to \-- sometimes David Dobbs,
listens in on these calls. He\'s really the developer of the
biomessaging guide and listens carefully to all the guidance he was
given last summer by the CDC, epidemiologists and biostatisticians who
really were convened to work on this. And there may have been a
definition. I wasn\'t around during all that time when they were
developing the messaging guide. David, you\'re not on the phone. He\'s
public, so we probably couldn\'t open it up to him anyway, right? I\'ll
follow up with him and get back with the committee.

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

That would be great. Thank you.

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

This is Marty. What I\'ve heard emerging from the discussion, some of
the principles, such as linking to the public health use case, and
perhaps some examples of those as it relates to filtering.

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

Yeah, and Marty, that says to me that going through by data element to
make a yes/no in the filter is kind of one parameter, one way of getting
at this question. But I think that won\'t answer the dimension of, say,
condition specific things that we want to filter out as a category that
wouldn\'t be answered in this column. So if we wanted to filter out
psychiatric admissions, for instance, would that come under discharges,
or ICD9 coding, or are we going to pick up \-- I guess my concern, are
we going to pick up everything with just a simple yes and no in this
column?

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

Well, no, I think our intent was to say, yes, there is filtering, and we
come back to it later to define what it is that we\'re going to be
filtering out.

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

Okay.

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

If we had an agreement, in general, as Marty was saying, if we had
general agreement that this is an area that needs some work on defining
what would be a filtering strategy for this data element, we\'re not
trying to sell that today.

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

Okay, that\'s helpful.

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

Okay. Now, let me go back to Steve\'s comment earlier about requirement
to inform a patient about the release of the information.

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

No, that\'s not quite right. We don\'t need to inform them. We need to
keep record of them.

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

Right, but is that a record when it has been de-identified or
anonymized, or whatever, you know, where it\'s not possible to find that
person? As Perry was saying at the beginning, imagine we did our job
right, we\'re not releasing any PHI, we have no way of going back except
if you know how to use the linker. Would the institution be responsible
for tracking the fact that this information had been released if there
was never any way that someone could go back and identify the person?

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

Good question, and I\'ve got attorneys who love those types of
questions. So we\'ll get to them. But when \-- your other point I\'ll
have to make sure they understand, i.e., the sending laboratory, so know
who that is, and therefore if I de-identify it to an outsider, have I,
what do you want to say, eliminated that requirement.

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

Right, that's the question.

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

I got it.

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

Okay.

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

I think \-- this is Eileen. I think part of what makes it complicated is
that HIPAA has some restrictions in cases where the population is below
a certain amount, and ZIP codes, since we would be giving record-level
data, even if it's de-identified, and not aggregated data, depending on
the frequency with which something occurred in the geography, it could
still be considered identifiable. And so there are some of these little
wrinkles in there, in terms of how thoroughly de-identified is
something, as long as the data is at a record level, and not at an
aggregated level.

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

Yes, I agree. I think we, let's try to take the easy road here, the 80
percent will be one where we don't need to worry about that
jurisdiction, we can put that aside for now and say we need to come back
to dealing with that other 20 percent.

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

Right.

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

Correct.

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

Would it be helpful for the group if we just kind of walked through some
of these elements that, in their, specifically the first five, and just
kind of walk through and pull out certain examples of whether they're
feasible for filtering in any context, and just focus on those specific
elements, and I know I'm being the devil's project person here, but if
we can \-- and I love the conversations \-- but I think if we can stick
to the elements themselves rather than what ifs for the whole condition
of filtering that I think we can probably knock off some low-hanging
fruit, and leave some of the others with an asterisk in the column that
we will discuss and, you know, filter out, well, not filter out, but
flush out more of the discussion around those elements. Would that be
okay? Don't throw things at me, please.

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

Oh, sure. Sounds fair.

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

This is (indiscernible). I think it will be helpful to get specific here
with a few and just see if it works.

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

So if we're all on the tab 2, I'll go through, the first one is facility
identifier and what we have here, it's a unique facility identifier is
the description, and is it feasible to collect and capture this data and
would it need to be filtered, I guess, would be the question, would it
be sensitive or data size or any of that type of filtering? And I'll
just pose that to the group and let you guys kind of ramble with it and
run through the first one.

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

I have a question. Is the unique facility identifier something that is
commonly known, that the CDC, and all the states, that everybody who
gets this data will know that unique facility identifier 120X is
hospital, is Good Samaritan Hospital in Cincinnati, Ohio? Is that going
to be commonly known, or is this kind of a way of keeping the facility
anonymous?

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

Ed or Eileen? What is the HITSP saying about this? What is the mechanism
to identify an OID or something? What is it?

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

You know, I think they want to use an OID here and I suspect that's
going to end up being identifiable, but I'm not sure for a facility that
that's going to be a problem.

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

Right. I agree.

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

I would tend to suspect these first five elements would all be treated
comparably.

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

It's all public information.

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

Yes.

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

With the exception of the one data field that says we should try to get
the beds regardless of license. The licensed beds are going to be public
information, and the Medicare number for each facility is going to be
publicly available.

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

But again, the biosurveillance system should have limited access for use
by public health, right? It's not publicly available information.

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

Right, but the point is we don't have to filter it, or \--

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

Right.

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

Did I understand correctly, that HITSP is recommending that the data be
visualized only by OID? Because in BioSense we do display the name of
the facility.

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

No, no, no, no, no. Not visualized only by OIDs, that they're just, and
not necessarily for the facility identifiers. It's more in the
authorizing somebody that authorizes, they're creating an ID, they want
to use OIDs to identify the source, but probably not for the facility.
But they're pushing OIDS pretty heavily.

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

Okay. But I would hate for that be visualized that way, because that
wouldn't be very useful locally.

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

I don't think it would be very useful.

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

So do we have agreement that the first five are feasible and require no
filtering?

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

Well, I think that there was a comment made that number 4 \--

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

Okay.

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

\-- might not be entirely feasible, but that the others would be and
would not require filtering.

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

I'm not sure our definition is quite good enough for 4.

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

Yeah, that's a good point.

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

People need to understand what they're doing. I mean, if you kind of
want to \-- conceptually I know what we want to say, it's going to be
active beds, or the beds you could activate in the next 72 hours, or
something like that, if you have whole wings of your hospital that have
licensed beds but don't even physically have beds in them, you know,
don't have power, et cetera, because you shut down that wing, to me
that's not an active bed. It's a question of how do I articulate that in
a definition, and I don't know. I have to think about it.

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

And do we have anybody on the phone who works in a hospital in a way
that they would know how likely this information is feasible to get, for
that element.

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

The hospital would know how many beds they have and how many are
licensed.

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

Yeah, the licensing issue isn't the problem. That's listed in tables in
the state's \--

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

Yeah.

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

It's how many of those licensed beds really, say there's a disaster, how
many beds, and you're going to really scale up and fill every bed in
your hospital. How many is that, really? It's probably some number less
than licensed beds.

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

Usable.

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

Yeah, a usable full capacity, or something like that.

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

So that sounds like it\'s comment on the feasible based upon the number.
So that should capture that as a comment for number 4.

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

Maybe it\'s usable beds at full capacity or something like that. It does
make it more difficult in terms of the feasibility question.

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

If I may, this is Lynn Steele. I have the definitions for the have
standards here.

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

Uh-huh?

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

So the physically available beds, I think that\'s what we\'re talking
about. Licensed physically set up available for use much these beds are
regularly maintained in the hospital for use of patients. May or may not
be staffed, but are physically available.

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

There you go.

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

And that\'s distinguished between licensed beds, staffed beds, unstaffed
beds, occupied beds, and vacant beds. I think we have a definition and
that\'s what we\'re talking about. So we just probably need to call it
physically available beds.

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

There you go.

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

Very good, thank you.

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

You\'re welcome.

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

Where did you get that standard from, Lynn?

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

One of my contractors pulled that together.

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

So number 4 becomes physically available beds. Given we know what it is,
how feasible is it to get it?

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

We\'re going to change the description?

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

Who was having the heart attack? Scott?

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

Yeah, that was me.

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

Is it still feasible in or is this where we need to qualify it in a
comment?

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

I just wouldn\'t be qualified to say.

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

Okay.

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

I think it\'s real feasible and all I have to do is call the admitting
department or one of the nurse supervisors at any hospital and they\'ll
be able to tell you off the top of their head.

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

Yeah, I think so, too. From my hospital experience as well.

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

Electronically-enabled data?

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

I\'m sorry?

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

I thought we were talking about electronically-enabled data.

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

I don\'t know that any of these are electronically-enabled.

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

Okay.

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

They were from the hospital people that we queried at this end, both the
nurses as well as the facilities officers all agreed that all these were
fine. Electronically.

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

They were available electronically.

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

The message from the hospital?

**[\>\>\
]{.underline}**It\'s available in the hospital records, and it\'s
available electronically. It didn\'t say we were \-- because we didn\'t
stipulate how we were capturing it.

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

If somebody could query a system that allows them to get this answer.

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

Exactly.

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

Okay.

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

So yes for 1 through 5 is that what we\'re hearing? I\'ll take that as
an affirmative.

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

Okay.

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

Filtering. Any reason to filter any of that information?

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

Not that I would see.

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

A type of facility we would not want information from?

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

We have made progress.

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

Should we try more.

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

The water is not so bad now, is it? Should quit while we\'re ahead.

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

Should quit while we\'re ahead.

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

Well, shall we move on to the 24-hour, 6, 7, 8, the admission,
discharge, and death. Unless Marty that you had a different path that
you wanted to take.

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

No, I think we can just march on through here.

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

And I appreciate the group, I truly do. So admission for the last 24
hours, discharge, and death. And can we collect this information and do
we need to filter it?

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

The filtering is easy. I don\'t think we need to filter it. The
collection I think it varies whether you want to say it\'s already
electronically available or not. But it\'s certainly feasible to collect
it. Places that don\'t have it electronically available, I think will
fill out a Web form for us.

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

So shall we save that for \-- should we say that for all three of those,
Ed?

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

That would be my vote.

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

So that this is an intermediate feasibility here.

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

So it\'s \-- this is Marty. Is it yes with a comment, is that what I\'ve
heard, feasible but it may not be electronically available?

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

May require some data entry by someone, yes.

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

Okay.

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

It\'s going to be the same thing on the HAvBED category down below.

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

Okay.

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

Good.

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

So.

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

Any other views on those, or can we move on to the next series?

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

So I heard a yes with an asterisk?

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

Yes.

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

And then filtering would be no?

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

Correct.

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

Yes with a comment.

**[\>\>\
]{.underline}**May require data entry.

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

So the next series, the clinical status and facility status, would you
see any problem with an institution reporting that, Ed? The facility
operations and staffing, all these ones that are coming up from have?

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

Yeah, the issue is asking to report it forever. Or do you have some of
those that you\'re asking them to report daily, and then others that you
ask them to report when there\'s a disaster or something. Just because I
think for the same reason that some of those fields are going to require
data entry.

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

Okay. In our case, one of the hospital reports on ours indicated that
facilities status was not electronically available.

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

That\'s my point.

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

Right. If they haven\'t it entered into a Web form \--

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

Okay, I see, right.

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

The interest in entering that into a Web form tends to wane over time.

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

This is Marty. Is that a type of \--

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

That\'s an interesting way to put it.

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

I was going to say does it need to be filtered for other reasons. I was
going to say no. I think a lot of hospitals will want to keep that
information private. But that doesn\'t mean it needs to be filtered as
it goes to public health.

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

So shall we say based on what Marty just said, this is a potentially
filterable data element?

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

Yeah, I like, that actually. May want to filter based on the situation.
Or situational filtering, I think that\'s kind of an interesting term.
Especially at those facilities that require some data entry effort.
It\'s my hope by specifying more of these things, more will be automated
into the system that we can capture.

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

Uh-huh.

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

I don\'t think we should back off from specifying them, but I think we
need to acknowledge that there may be some filtering if manual entry is
required of some facilities.

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

This is Ed. This is clinical statute and facility status and facility
operations, those three.

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

Even as you get into the various bed types, the same thing.

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

This whole area. Anything basically to have with the HAvBED?

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

Yeah, I think it is.

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

I mean, Lynn, as you\'ve looked at this in more detail, are is there
anything else there that you think we can reliably automate at least up
front in.

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

Well, you know, we\'ve been able to automate some of that census data.
It requires an IT solution at the hospital.

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

But it\'s automated then.

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

And again, I really want to emphasize, I think it\'s good for us to
specify this as part of our data set even though it\'s not maybe
immediately captured in an automated fashion. Just because I think it
will drive the industry to automate it.

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

And we\'ve been able to drive the health care \-- if no one said no,
they wouldn\'t automate.

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

Right.

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

We don\'t necessarily know what we\'re getting, but we get it.

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

Right.

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

Yeah.

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

If we have an automated solution, and you can enter it in the Web form
\--

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

I think that\'s a different issue.

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

Automated long-term.

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

Yeah.

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

It is, I guess.

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

Yeah.

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

I guess I want to encourage the industry to move to automation.

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

Yeah.

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

We can get them to automate some kind of regular census update. We
probably will never get some of the automation that\'s part of what are
in some of the have requirements. Necessarily related to available
isolation rooms, capabilities within, you know, so many hours.

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

Uh-huh.

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

And this whole idea about diversion, you know, we\'re at full capacity
in our emergency department. So a lot of those things that have been
developed as part of these emergency department systems related to
HAvBED. And that, you know, I met with some of the EM systems folks who
have been working or were charged by the American College of Emergency
Physicians. And what I came away with from that meeting is there\'s \--
well, we look at this as data entry and we don\'t think data entry
necessarily is a good thing for the long-term, hospitals, an emergency
department look at this as a way to manage traffic coming in and out of
their facility, and as a way to communicate to healthcare facilities
what\'s going on within their facility. So they\'re compelled to enter
this data. Whether it\'s a Web system or not. So it actually becomes
part of a clinical management for our facility. We\'re trying to
determine if we should explore that data display alongside BioSense
data.

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

You\'re saying you\'ve managed to create an electronic summary for a
facility.

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

That\'s correct, we\'ve done that.

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

And now you\'re going to match that up as to what is the provider or
emergency department leader of a summary.

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

Right, we\'re in discussions about that, because it\'s not, you know, at
least I was under the impression this was an extra burden to healthcare
facilities to enter this information and certainly that\'s the way it
was a lot of requirements during Katrina to get information quickly. But
if we \-- if we move toward a system that has \-- exists because
there\'s a compelling reason as part of the management of the facility
and I don\'t know why I\'m talking about this as well if Ed is on phone.

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

I am.

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

How was I doing, Ed?

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

You\'re doing fine, I think it\'s better for them, for you than me
anyway.

[\>\>]{.underline}

The point is if there\'s day-to-day systems where people are collecting
and shipping this data around anyway, and we can just harvest the data
out of those systems, then whether it\'s Web form or a main frame system
that somebody is entering data into, the point is there\'s sources we
can get the data from.

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

And both may be useful to inform public health.

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

Correct.

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

This is Marty, so for our table we\'re marking these with yes and an
asterisk in terms of feasibility and filtering, no filtering, but with a
comment situational filtering if manual entry is required or until
automated.

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

Is that a general census.

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

Put may be desirable or something like that.

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

Okay.

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

Some wiggle room.

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

So Ed, are the majority of the hospitals using some tool to share
information across a metropolitan area? Just trying to understand
Lynn\'s comment. Is this really \--

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

Yeah, I mean EM system alone is now 35 percent of the country\'s
hospitals interacting with it all day long and there\'s other programs
that are out there so it\'s probably over 50 percent are using one
program or another. In terms of just kind of their local regional
situational awareness, and particularly with interactions between the
emergency departments and EMS providers.

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

Right. I know that happens in my area as well, just wasn\'t sure how
prevalent it was. Point of view it sounds like it\'s pretty prevalent.
And that might be a data source.

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

Yes, absolutely. What I think the point to Marty\'s point is some of
that depth of that data that\'s in the have spec, how many burn beds do
you have available, is not necessarily shipped on a day-to-day basis in
those systems.

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

Right and some of these will be easily retrieved and some will not.

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

Right, right.

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

So we think facility status might be something that could be retrieved.
It would be, if not available, it would need to be some web-based
system. But if we keep moving down this \-- is clinical status also
captured in EM system, or others like it?

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

It can be. I mean, the way EM system got configured and rolled out
across the country is each region kind of defined their own fields of
what they\'re going to define, follow on a day-to-day basis. Therefore,
until we come counsel with this nice standard that we\'re kind of
suggesting, everyone customized to their own individual region. So there
may be some mapping activities and transformation activities that will
have to go on over time the regions to synch them up with what they\'re
specifying here.

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

Is there someone at EM.

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

Someone we should speak with?

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

The chief medical officer.

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

In terms of the mapping and stuff like that.

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

Yeah \--

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

You\'d be the best conduit to that in.

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

Sure, and the EM technical personnel were involved in writing some of
the HAvBED spec and their team is very much involved with that.

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

Okay. So they understand that\'s the way the industry is going.

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

Art, this is Marty again. We have, what, ten minutes left is the clock
that I have? Or am I in the wrong time zone?

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

I\'m trying to figure out myself.

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

You\'re in the wrong time zone.

\[Laughter\]

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

The twilight zone, is that what you\'re saying?

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

The Chicago song, does anybody really know what time it is.

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

You have about 20 minutes left. I thought we went until 4:30.

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

Okay, I\'m in the wrong time zone myself.

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

We have 40 minutes left.

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

Excellent. We\'re doing well.

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

Okay.

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

So just to summarize here, all of the way from \--

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

I think all the way through the rest of the resource items, we don\'t
have to go through them one by one, do we?

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

No, I want to \-- from the clinical status all the way down to the data
linker, I have a yes asterisk, with a filter no, and in the notes
section I\'ll put may require some data entry, will require automation
on the part of the sending facility, and situational filtering.

Is there anything else?

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

One other input from one of our feeds here on the decontamination
capacity. There was a recommendation to look at through-put or percent
committed of the facilities. What we have there is sort of a zero
percent, 100 percent, or over range, in terms of the way we characterize
decon capacity, and this one was recommending a percent committed or a
through-put capability. That was the one input that we had from one of
our stakeholders. This is from Parkland.

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

Is that part of that \-- the HAvBED spec, that\'s the way it\'s
reported?

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

That\'s the way it\'s described on the description column in our \-- we
said not being used, in use and able to accept patients, or in use at
maximum capacity.

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

That\'s from HAvBED.

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

That\'s from HAvBED. Right.

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

So your Parkland group is suggesting we code this differently?

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

Yeah, they were proposing a different consideration for the description,
and I\'m not sure \--

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

Well, I think what we\'re trying to do is find something that\'s a
standard, and I think this one has been submitted to OASIS? Right.

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

They\'re in a public comment phase.

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

We could ask to direct that comment to them?

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

If I understand, it they want to quantify, not just open or close. They
want to quantify \--

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

Exactly.

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

What they\'re capable of.

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

Exactly.

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

Interesting.

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

Because of additional \-- if additional through-put can best, needed,
additional transport can be routed to less stressed facilities.

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

Sure.

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

Isn\'t that the same as the last one.

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

That\'s a yes or no, though. I mean, if you\'re over range, that
definitely would require routing, but if you\'re close to the edge, you
know, and you had some analog indication there to tell you, then you
might choose to assess the situation different.

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

Okay.

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

Well, I think we can take this as a no at this point. We\'re not trying
to get too deep into these. So \--

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

Yeah, the note can say quantification may be desirable.

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

Yeah.

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

It\'s still a yes.

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

So Ed, will all the EMS questions as well be covered by EM system?

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

Let\'s say they\'ll be covered by have, because a lot of cities don\'t
have EM systems.

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

Sorry, HAvBED, correct. I misspoke.

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

I\'m trying to be sensitive.

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

Right.

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

All these are included including negative flow (indiscernible) and
ventilators.

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

They certainly can be. I\'m not saying that people collect that every
day as a matter of routine, because I don\'t think most of them do.

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

I had a question from one of the health authorities, on the available
ventilators, does that include bypass machines or other machines that
can assist ventilation other than ventilators?

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

Good question.

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

Who is riding the train?

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

We have that problem here, but I don\'t know, a hundred yards from the
railroad tracks here.

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

That beautiful office building, though.

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

It is, it\'s gorgeous, but if you\'re out in the parking lot, it\'s
deafening.

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

This may not include other types of machines.

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

Yeah, and \--

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

I wouldn\'t try to break it down into \-- if you just leave it as
ventilators, I think we\'re starting to detail it more than we need to.
I think it will be hard enough to get ventilator data reported.

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

Is Biosense doing any tracking of ventilator equipment activity, Lynn?

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

You know, we\'ve talked about it. From the perspective that, you know,
that information probably exists somewhere in an IT system in a hospital
for service \-- you know, related to servicing ventilators. But we have
been trying to stick to our primary mission. So we\'ve talked about
doing it, but it\'s not \-- it hasn\'t been a high priority.

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

We have some data elements here that are not in BioSense.

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

Oh, yeah.

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

Okay.

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

I\'m surprised.

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

Because this whole data facility summary stuff really came from sort of
the HAvBED concept.

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

Yeah.

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

This is data that\'s entered for another reason or the have a bed
project I think is probably a better way to say it. This was not part of
BioSense.

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

Okay.

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

Does that complete that section?

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

I think so. Should we run down to (indiscernible) data elements. This is
probably where we\'ll get into some discussion around filtering.

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

Oh, yeah.

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

So should we start with the pseudonymized data link center.

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

Can we put that last?

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

Or go way up?

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

I\'m all for lopping off the low-hanging fruit here, guys.

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

So I mean, I think we really should just kind of \-- this is part of the
meat of Mr. DuBois\'s letter how to generate the link of the data \--
there were others who made the same comment. Might have been Shaun
Grannis as well. Yes.

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

Yes, he did, during our last call. I mean, I would tend to say creating
it is a form of filtering. So in if a way filtering is almost not
applicable. But from my perspective, it\'s a major problem for
feasibility.

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

Does anybody disagree with that?

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

So my only question is the classification. It seems between yes and no.

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

To me, feasibility to answer is no. But that\'s just my opinion.

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

I\'m sorry, I missed some of that.

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

What\'s the issue?

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

How feasible is a data linker?

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

Very. We\'re doing it.

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

So we have a yes and we have a no.

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

You have to have some way to display the data, but then to only \-- and
to ensure that you have a way to link a patient for their multiple
encounters even during the same hospital admission or care.

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

I think we all agree there must be. I think the problem, Lynn, is that
the BioSense has, I know from personal experience, invested in our
capacity to create an environment that allows us to do some of these
things.

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

How do we isolate from IT or other vendors.

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

Right and I think that\'s what Eileen is speaking from.

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

It\'s feasible, just costs money.

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

Right.

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

How are we defining feasible?

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

I was going to say, that\'s the question.

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

Is it feasible \-- it\'s technically feasible. Is it feasible to
implement within the next six months everywhere. I mean, those are two
different questions.

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

It\'s definitely not low-hanging fruit.

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

Oh, that\'s for sure.

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

But it\'s crucial to the entire project.

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

It really is.

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

When Eileen said it was not feasible, Eileen, were you \-- I think you
were thinking in terms of generating and keeping track of randomly
generated numbers. But would the laboratory number meet the requirement
of a pseudonymized data linker for the group.

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

No, for one thing we considered the laboratory accession number to be
PHI, because of the fact that it is entirely possible to get directly to
patient data if you know the accession number. But more to the point the
accession number is unique to a testing event, and so there\'s no
ability to link that to any other test on the same patient. Unless it
occurred during the same testing event. So if a patient is tested 22
times for the same thing, you have 22 unique accession numbers and
therefore 22 unique IDs. And I don\'t think that meets the criteria for
pseudonymized ID. That\'s number one. Number two is the idea that once
you\'ve created these IDs, you have to store them in a way that you know
what they were so that if somebody contacts you and gives you the
pseudonymized ID, you can find the original ID, which creates the second
burden of keeping track of all of the assignments for an unspecified
period of time, of those IDs, because it\'s not part of our internal
data record.

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

I was \-- I guess this gets to the question of the \-- how the
pseudonymized data linker will be used and I\'m thinking of it maybe too
simply. That would be that if an authorized public health official
wanted to \-- or needed to for public health, legitimate public health
purposes, go back and follow back to identify the source patient, they
would have to go to the lab, first of all, because you\'re going to be
holding this linker, if you can make one. And if the accession number
meets that need and is easy for you to do, doesn\'t that meet the intent
of this? That retrieving it and keeping track of it is another issue
that you bring up. But in other words, \--

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

The accession number is something we would have store and always be able
to track, but it\'s not \-- our attorneys have defined our accession
number to be protected health information under HIPAA.

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

How about if you used a \-- an algorithm that can go backwards? That
don\'t send an actual accession number, but you send a \-- another
number linked to the accession number.

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

No, I\'m saying that you run a random number generator off the accession
number, and encode it.

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

Again, it goes back to having to record that information for what period
of time, where do you keep that tables of how you\'ve done that.

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

I think that\'s an important point. So \--

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

I mean, it\'s a big implementation issue. It\'s not a simple thing. And
again, it\'s still not giving the ability to collate records on the same
patient in any way.

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

I don\'t even know that the labs ever could do that.

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

Right, well \--

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

That\'s a nonissue \-- that issue exists whether we have a pseudonymized
linker or not.

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

So I think there are certainly \-- I\'ve heard from other people whose
expectation is that that would be a single one from the institution. And
also I don\'t think \--

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

For an institution, yes, but for you, you cannot promise that. You
don\'t have a master patient index. You live by the specimen. Isn\'t
that the unit of analysis.

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

Yes, exactly.

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

Right, it\'s not at the level of a patient.

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

Right.

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

Right. So then let\'s ask Lynn how long will BioSense store the data?

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

Yes.

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

Yes.

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

Is that a yes from Lynn?

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

Yes.

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

Because I\'m not sure.

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

Those discussions are going on right now based on a number of different
parameters. One is amount of data and storage capability. There\'s some
usefulness in keeping historic data available in the Biosense
application. Because especially as you look at trend analyses over one
year to the other of seasonal outbreaks. The short answer is we haven\'t
made a final decision on that. When we say how long will we keep the
data, we mean to keep the data as available for real time review through
the application.

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

Because that has an implementation for potential data sources.

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

I\'ve never thought about this question, truthfully, from the
perspective of having to go back and relink patients from 12 years ago.

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

Right.

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

Probably should get on that.

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

This is Marty. I\'m hearing our first yes, Y/N, a techno feasibility.
But an implementation feasibility issue and including practices about
standard approaches for implementation. Keeping track of these and the
feasibility of doing that is uncertain right now.

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

That\'s great that the key element of this whole thing is our first Y/N.

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

This is Perry. I had a question for \-- follow-up question, just to make
sure I understand. Eileen, it\'s your understanding, then, that your
lawyers are saying that the accession number is HIPAA protected but if
you made up another number that linked to the accession number that you
could link, that the lab could link, that would be releasable?

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

I believe that\'s the case. The first part I know is definitely true,
because that we\'ve had discussions about. I believe the second would be
true, but again it\'s the issue of storing the mapping of all of those
created numbers. But I believe that would be the case.

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

I\'m struggling with the fact that if the lab is the only person that
holds the link between the accession number to the demographic
information and the name of the patient, in actual practice is really
very little difference practically speaking. Whether I, as a citizen,
have \-- or as a public health official, know what the accession number
was, or randomly generated code number, right in because \--

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

The difference would be that presumably if this was created for public
health, the information would only exist in very limited iterations
within our system. Where the accession number appears all over our bill
systems, client service systems.

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

Okay, that\'s helpful.

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

And there are lots of different ways that you could, depending upon how
you accessed our system, there are lots of different paths to the
patient through the accession number. But presumably they would only be
one and it would be a two-step path through a bogus system, essentially
or mapped.

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

Okay, I got it. That makes sense.

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

Okay, so \-- and does anybody believe there should be filtering on this
one?

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

As I said, I think that it is a form of filtering in creating it, but
\--

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

No additional filtering?

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

I wouldn\'t see that, myself.

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

Okay.

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

Are we through that one, or should we continue to discuss this?

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

I\'ve heard a yes/no for the first feasibility and a no for the filter.

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

With the comments.

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

And that was on the data linker, correct in.

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

24 data link.

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

A yes/no, because the implementation of the data link and a no
additional filtering is required.

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

Yes, because it\'s technically feasible. It\'s no because of \-- it\'s
not feasible to deploy this widely to collect data electronically in the
next year. The year one implementation strategy. and the additional
issues of required mapping or standard models and method for it
deploying what a data linker should look like. That\'s what I heard. Was
there anything else?

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

Sounds right.

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

Okay.

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

Good.

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

Excellent. Counter D. time, is that where we\'re at, Art?

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

Is that feasible?

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

So you know, I wrote this, encounter only has meaning for outpatient
settings. You are tracking the time \-- date and time of admission in
BioSense, aren\'t you, Lynn?

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

Say that again, I\'m sorry.

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

I wrote this little comment here about the encounter has meaning only
for outpatient settings. I wondered if we should expand this to say
encounter/admission day time. Because for an in-patient admission, you
would know exactly the date and time. Is that not right, you\'re getting
that off an ADT?

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

That\'s right. But that date and time message comes with updates of
other clinical data.

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

But this is just for the event that there was \--

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

The encounter.

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

The encounter or the active admission or discharge.

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

We probably define it differently depending upon if we\'re talking about
an emergency department encounter or in-patient or outpatient visit.

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

Right.

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

That\'s right.

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

So I don\'t know whether we have the right term here, the official name
may be incorrect, Scott. We may need to come back to this. But let\'s
just assume it\'s outpatient right now.

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

Is that something that we can get at this point?

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

We want an admission data if we\'re tracking in-patient.

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

That\'s my point. I think we should call this admission/encounter.

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

But isn\'t it admission date considered an encounter date within an
in-patient setting in?

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

No, they\'re used differently.

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

One is referring \-- well, actually, I think the encounter is considered
an admission to an outpatient setting. What do you think, Ed?

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

I think outpatient data is tough.

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

So let\'s just assume we figured out the name for this. I don\'t think
we know that right now. But you are capturing \-- this is a standard
data element in an ADT. So this is feasible. Does anybody believe it\'s
not?

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

I think we all agree.

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

Okay, great.

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

Yeah, if I understand the question \-- I didn\'t understand your
question well before, but yes.

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

And is there any need to filter that?

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

Is there some fear that this needs to be masked because there might only
be one admission to a hospital in a day or \-- that could then be
determined who that person was?

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

Can\'t we limit this whole filter discussion to things like diagnosis
and lab results? I mean, all this demographic and outside stuff, I
don\'t think we have to worry about the filtering. Not even \--
administrative type stuff.

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

I\'ll tell you, the filtering we use in our sort of front-end
processing, we use a combo key to eliminate duplicates because some of
these systems that generate these messages do have a tendency to
generate duplicates. I don\'t know if that\'s something that can be
fixed elsewhere in the system, but we nevertheless, to accommodate the
hospital data that comes in, we have to eliminate duplicates by the use
of this combo key, which is basically a filter.

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

From a HIPAA perspective, both age and ZIP, there are typically
restrictions on what you might be able to provide, usually we\'re told
age over 89, we\'re not allowed to provide \-- at least the data is
supposed to be de-identified. and ZIP-5 can be problematic in areas of
low population density. From a HIPAA perspective there may be some other
filtering.

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

Can we put a yes in ZIP and age?

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

For filtering?

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

With those comments?

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

Yeah \--

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

We\'ve gotten a different interpretation on that from the HHS attorneys.

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

That if these data are to be used for public health intervention, then
those HIPAA requirements don\'t apply.

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

So is this \--

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

Because we\'re not talking about de-identifying the data. To apply those
standards for some data elements but not for others, doesn\'t
necessarily make sense to me. Rather we\'re coming up with a minimum
dataset that suggest these data will be used for necessary public health
interventions.

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

But you are de-identifying it. If not, you could just use the patient
identifiers and not have to create these randomized data linkers. So \--

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

But that I think is more related to sensitivity. About getting patient
names rather than the legality under HIPAA.

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

Well, it may be that different attorneys view it differently, but I know
that there have been discussions in the HITSP also, indicating that they
felt age should be capped at 89 for specific ages, so I don\'t think
it\'s just our attorneys. So I think that might be one of the ones
that\'s a question mark at this point.

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

We have a Y, question mark for ZIP and age? And I\'ve heard a no for
encounter date in this category.

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

The encounter date to yes/no?

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

That\'s what I\'ve heard so far.

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

Okay, date of birth was what? Was it also a yes no? Or was it a yes
asterisk?

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

We haven\'t.

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

Okay.

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

I think it\'s the day I was born.

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

So this was a question mark? I I\'m sorry, you guys were jumping around
too fast for me.

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

The universe is feasible, does everyone agree that? Receive it and then
does it need to be filtered?

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

You may recall that was one of the data elements that (indiscernible)
that questioned during testimony during our last call.

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

Who is he?

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

And then Shaun questioned age because that was not available in many
systems. Isn\'t that right?

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

I believe that was correct.

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

Well, you know, if the issue is one or the other, and age is not
available then it would seem like you could collect age and data to
calculate a month and year of birth is to help you ensure you\'re
referring to the correct patient. So we don\'t have an answer for
whether we need to filter day of the birth or at this point.

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

We have a Y, question mark, I think, to be determined. One we need to
look into further.

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

Right.

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

Okay. Age may not be feasible. From Shaun\'s comments.

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

It\'s going to be feasible for most systems.

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

From my system it is, but I think he pointed out that he didn\'t think
it was.

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

So should we say Y/N for this one? Y, asterisk, I think. It\'s generally
question yes, but it may not be available on all systems.

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

But date of birth was definitely feasible?

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

Yeah, it should be.

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

Okay.

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

I think the only potential caveat is month and year requires an action.

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

Right.

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

It\'s going to have day in it so it\'s a calculation that\'s going to
strip off the day. Or presentation. So it requires a manipulation versus
the full birth date. I think that perhaps parents the asterisk to that
effect.

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

Okay.

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

Are we on gender?

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

Yep.

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

Is that feasible?

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

I\'ll that I as a yes. People \-- need to fill that in any way.

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

I think we were going to restrict it to the administrative six
categories, but other than that, probably not. But that might be
something we want to point out.

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

Is that, depending upon the standard chosen, it may or may not be
available?

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

Well, I \--

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

So transgender?

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

(indiscernible) do track many different flavors of transgendered
individuals, and so that\'s why the HITSP was looking at \-- simply
saying male/female or other. It might have been unknown, I can\'t
remember right off the top of my head whether it was other or unknown.
But.

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

I think it was an U. I was looking at it last night.

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

It was probably \-- I don\'t know whether it was unknown or unspecified,
but yeah, I think you\'re right, I think it is an U.

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

And maybe that\'s just a note. I don\'t know if that\'s going to be a
problem for anybody\'s system to map anything that\'s not M or F, or
however they represent it to another category.

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

But we don\'t believe there needs to be any filtering of this, do we?

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

I wouldn\'t think so.

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

Okay. So ZIP. We decided it\'s a Y, question mark for filtering. How
about feasibility? I assume that\'s in all systems, but I may be wrong.

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

I\'m not personally aware of any that don\'t have it, but \--

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

So then that\'s a yes for feasible and state should be feasible and
there\'s no need to filter a state? And time \-- day and time of last
update. So this was intended to deal with Bill\'s comment earlier about
repeated messages. I think it\'s feasible, every message out of an ADT
should have that. And I don\'t know that there\'s a reason to filter it,
unless we\'re fearful that\'s a way to go back to identifying a person,
but this going to a public health official, so this should be no reason
to filter, is that right? It\'s also a way to make decisions about what
data you\'re going to visualize in an application. If something is
updated, there are decision rules about removing certain data.

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

Right, so I think these are Y/N, right, would you agree?

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

Wholeheartedly.

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

Okay, great.

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

Well, Ed, we\'re finally into your area. The one you wanted us to get
to.

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

It only took us 15 minutes.

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

We have about 15 minutes left.

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

Everybody\'s shown great endurance, I\'ll tell that you.

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

True.

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

I appreciate everybody\'s patience myself, too. So thank you.

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

Maybe we can do a couple of these and then we probably are going to have
some homework.

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

Right.

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

The big one here is diagnosis injury code. ICD-10, right?

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

I think that this is very feasible to get an ICD-9 code. I don\'t know
how feasible it would to be filter it.

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

Keep in mind that depending upon the source, I mean I can tell you we
only get ICD-9 codes on about 40 percent of the requisitions we receive.

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

Okay, now, I was thinking that the lab would \-- I don\'t know that I
was thinking the lab was going to be reporting this section of clinical
data elements. I thought the lab would be reporting \--

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

I\'m sorry, you\'re absolutely correct. I\'m sort of thinking \-- never
mind.

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

Okay.

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

Ignore me.

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

I think it does speak to the availability of ICD-9 codes in real-time. A
lot of people don\'t assign ICD-9 codes in real time. They have billing
clerks that do that days or weeks later.

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

Right, at the point of after discharge and when they\'re sending the
bills out, that\'s correct.

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

It may not be available in real-time in \-- is there a comment here?

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

In a codified version. You can get the free text.

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

I\'m sorry, we\'re at diagnosis. I think you can get free text
diagnosis, even. Lynn, are they sending you any diagnosis-type messages
at this point?

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

Yes.

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

And they\'re code?

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

You know, I better not answer until I know that for sure. We\'re working
hard to get that. We\'re in a pilot project with emergency department
through the 8-4, for a solution through one of the emergency department
vendors, but I\'m not \--

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

That\'s the way it can happen because sometimes that will force them to
go and code it off of a menu.

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

I think what we\'ve discovered is these data will exist and often exist
in emergency department systems. The problem is they're a database and
they\'re not HL7 messages that are moving as part of the translational
\-- or the traffic in exchanging information between IT systems. So
we\'ve had to come up with a solution of how you get that data.

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

Because I\'m thinking some of the hospitals where I work, at least
before I can admit a patient, the clerks always say to me what\'s the
admitting diagnosis, and they type in whatever I say into a field, but
it\'s a text thing. So it\'s not really coded. Now, the discharge ones,
I don\'t know even know \-- well, I do think they do document in the
main frame ADT system, the discharge diagnosis I write on the chart.

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

We\'re receiving free text diagnoses.

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

Yes.

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

We\'re receiving free text chief complaint. We\'re prepared to receive
it.

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

You can get those in real-time.

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

Correct.

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

It\'s the codified stuff you have to have systems installed that kind of
force the clerks or the clinician to code it instead of putting it in as
free text, and I think that will evolve over the coming years, but I
think we have to admit at least up front that many facilities won\'t be
able to provide codified chief complaint or diagnosis in real time yet.

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

Right, but I think what is \-- I don\'t know that we should have code
listed here. What we\'re saying is that having \--

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

You want the data element.

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

A data element that\'s either diagnosis or injury, that\'s associated
with a time. So that we begin to move from having data that ADT-related
chief complaint, administrative reason for visit. and waiting for the
coded diagnoses that we know a latent two or three days.

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

Right.

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

So I think the intent of this data element is to begin to look at the
feasibility of getting clinical diagnostic information in real time, as
it becomes available in IT systems. Either as a code or as a free text
diagnosis. So I think the word code there changes the intent of what I
would think we would want as part of biosurveillance minimum data.

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

If we say diagnosis and then leave HITSP to designate the appropriate
code to use and hopefully that will drive the industry \--

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

Hence the date and time stamp of number 34. That helps us to understand
the encounter date and time and when this diagnosis was made regardless
of the format.

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

This is Marty. So I\'m hearing for chief complaint and diagnosis injury,
a Y-star, indicating that coded values may not be available in
real-time. Although \--

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

But are encouraged.

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

First year implementation. Is that what we\'re focusing on, what\'s
feasible in this first phase.

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

Correct.

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

We\'re saying it\'s feasible but saying coded values may not be feasible
in the short-term. May not be available.

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

For diagnosis and chief complaint. Any others? I think those are the two
main ones with coding.

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

Do we want to tackle the filtering issues with either of those? On
diagnosis injury. How would you filter the \--

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

Can we go on record that we don\'t think it should be filtered? I mean,
what you\'re going to get is push-back saying the HIV, and psych stuff
should be filtered and my personal bias is that it shouldn\'t be.

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

Well, I mean, I think you have to look at that in the practical
considerations of if you don\'t filter on anything, can anybody handle
the volume? And you know, I can understand \-- I can appreciate argument
on either side. So I\'m not saying I have a definite opinion either way.
There are pros and cons to filtering and not. There are costs of doing
either. But I think you can\'t \-- having dealt with very large data
systems, having dealt with the system where I have to contend with the
scale that we contend with, I know the price of huge amounts of data. If
you\'re not working with most of it.

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

I\'m not talking about lab data. I\'m just talking about for diagnosis
and chief \--

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

But still if it you\'re looking at all of the different interactions in
a hospital, I realize you\'re not talking about lab data. But whatever
it is you\'re talking about, if you\'re not filtering on anything,
you\'re getting into a lot of volume. and I just think that\'s something
\-- they\'re just tradeoffs, I\'m not \-- as I said, I\'m not really
taking a position. I\'m just reminding you that there\'s a practical
implication on both \-- on every side of the fence. Filtering is its own
problem \-- the process of filtering and rules and that\'s not trivial.
But you just have to figure out what the \-- that there are significant
costs and issues doing it \-- either doing it or not doing it?

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

It becomes an issue, then, of if it\'s \-- we filter at all, what types
of conditions are we talking about, or what situations make sense?
Otherwise it\'s \--

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

I guess \-- yeah, my argument is we shouldn\'t make argument \-- or we
shouldn\'t be deciding to filter or not filter based on the limitations
of technology. We can let other people analyze that. Rather we should
try to do it on the basis of whether there\'s subsets of patients that
are just not useful for surveillance, and at least with regard to the
diagnosis and chief complaint elements, I think we want to track all of
those.

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

Are there any for public health scenarios that make sense to exclude?

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

Yeah, this is Perry. I think that the vast majority of this data will
not be useful on a day-to-day basis for public health, but on the other
hand I think we can all think of a scenario where a particular diagnosis
or something we might want to look at in had a particular instance would
be of benefit to public health. So I think we can always think of an
example, but the day-in and day-out, 365 days a year, the vast majority
of this data will not be probably \-- or at least of \-- at least a lot
of it will not be critical for public health. Would you agree, Lynn.

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

I would, but right up until you need it.

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

Exactly \-- yeah, that\'s right.

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

No, I mean I\'ve been thinking about this a lot. You know, so maybe the
model right now, I mean so we\'re getting data because there\'s a
biosurveillance use \-- you know, there\'s a use for, it a public health
use that would inform biosurveillance when the question is being asked.
You know, maybe this isn\'t always going to be the model. But it\'s what
we have right now. Could you turn data on and off.

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

I think so that\'s hard.

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

Right.

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

Very hard. I mean, this gets back to what I was mentioning a half hour,
45 minutes ago, is that not filter by diagnosis, just take everything
and keep the dataset as minimum as possible. I hadn\'t carefully
considered Eileen's point about the size of the database, which is a
major issue. But I have confidence that CDC will handle that.

\[Laughter\]

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

Seriously, \--

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

Did I hear you say you\'re confident in CDC?

\[Laughter\]

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

You did.

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

I almost tuned out then.

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

Too late, it\'s on record already.

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

We\'re almost four hours into the call.

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

We need to kind of do the public comment period here. I think the
discussion can go further, but Matt, if you could queue them up.

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

Sure, I\'ll put the information up and if you can continue with your
conversation for a couple more minutes, and then I\'ll check back with
you and let you know if anybody got on line.

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

Thank you, Matt.

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

Art, in terms of timing, this is Marty. We\'ve got \-- we\'ve made
terrific progress through here. Wonderful discussion. We\'ve got a
little bit more to do, including I\'ve heard some principles related to
our definitions of filtering and feasibility. We can help come back
with. The discussion is very valuable and kind of going through these,
even though it\'s a little tedious at times. It\'s been helpful. We
could do that, or we could have people actually do as we did before,
which is to fill out these last two selections, submit it and use that
as a basis for going through these quickly at the next call. Art,
thoughts on \--

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

Well, I think we do need to spend a little more time on this, but the
three of us, or the five of us with Kelly and Laura, might be able to
spend some time between now and the next time we get together kind of
firming up what are some definitions here for us to go through the meat
of this list. I\'m feeling positive about the progress we\'ve made, but
I think we still have some of the more difficult things to tackle. The
bottom of this list. And we should be considering Perry\'s and Eileen\'s
comments about, you know, let it all flow versus what are the burdens
that creates. So I think we need a spend a little time huddling again as
a small group and then come back to the larger group and figure out
where we go with what we\'ve done today. Did I answer \-- you know, it I
got distracted. There was a call on my cell phone just as you were
talking, Marty.

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

I\'m wondering how the group perhaps feels about trying to give their
own paths of these, answering it and sending it to Scott. Whether we
want to try to do that, or do we \-- there\'s a rich discussion that
goes on as well.

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

I think we would miss that.

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

Yeah.

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

The only value I think is one that we \-- it gives us a chance to think
about it. Outside of the call. The second is to \-- those that we have
some clear agreement on, we can move out of the way and focus on those
which we have different \-- disagreement.

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

True.

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

So if I can propose something to the group that I will \-- if I \-- I
heard Art and Marty probably taking notes on their end. If you would
send me your notes, I\'ll combine our documents, or if anybody else was
taking notes for that matter, please send me the documents. I will go
ahead and combine them into a new spreadsheet. And hopefully get it out
to the group by noon tomorrow, and that way throughout the week next
week, we can be reading over the testimony by that time Bill and I will
compile a list of these additional elements through the other written
testimonies. Also, hopefully working on the definitions, we should
probably have a little bit clearer picture. Does that sound okay?

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

Sounds good to me.

**[\>\>]{.underline}**

That sounds good.

**[\>\>]{.underline}**

Yep.

**[\>\>]{.underline}**

Yep.

**[\>\>]{.underline}**

Thanks, Scott.

**[\>\>]{.underline}**

Sure.

**[\>\>]{.underline}**

I also do have questions from the HITSP bio group on a couple of the
data elements that we hadn\'t gotten to yet. So maybe what I\'ll do is
just type those questions up and send them to you to send to the group?

**[\>\>]{.underline}**

That would be wonderful, Eileen, I appreciate it. I\'ve been following
and I know I\'ve forwarded some of the conversation that\'s going on. I
was planning on providing a summary to the group, but maybe what I\'ll
do is just forward on the e-mails as they come in to the full group.

**[\>\>]{.underline}**

Okay.

**[\>\>]{.underline}**

But if you would do that, that would be excellent.

**[\>\>]{.underline}**

Matt, do we have anybody on line?

**[\>\> Matt McCoy:]{.underline}**

No, nobody called in.

**[\>\>]{.underline}**

Nobody called in to listen to our call?

\[Laughter\]

**[\>\>]{.underline}**

They\'re all here in the room.

**[\>\>]{.underline}**

Well \--

**[\>\>]{.underline}**

Well, very good. Well, I think we\'ve made a lot of progress today, and
we got a plan for the next session. When is \-- do we have a date for
the next call?

**[\>\>]{.underline}**

Isn\'t it Tuesday?

**[\>\>]{.underline}**

Yeah.

**[\>\>]{.underline}**

Yes. The 19th was a planning call. Scheduled for the preliminary
recommendations going up to the full Workgroup, the Biosurveillance
Workgroup. Which is at 10:00 to 12:00. I know I\'ve got questions in to
Kelly, who is running that group, as to what they\'re expecting for a
deliverable. In other words, is it just one person from this group
telling them either Art or Marty or representative, telling them what
we\'re coming up with, where our problems are, what our process was, or
are they actually expecting a presentation at that point?

**[\>\>]{.underline}**

Can I just confirm the time? Is it 10:00 Eastern?

**[\>\>]{.underline}**

Yes.

**[\>\>]{.underline}**

Okay, I need to correct that on my calendar. I had that down for wrong
time. Thank you.

**[\>\>]{.underline}**

Sure.

**[\>\>]{.underline}**

And I have requested for whoever needs to do this, that they be on the
first part of the agenda.

**[\>\>]{.underline}**

So \-- and I\'m talking about the 19th. 10:00 Eastern time.

**[\>\>]{.underline}**

10:00 to 12:00.

**[\>\>]{.underline}**

Thank you.

**[\>\>]{.underline}**

And that\'s not for the whole group, you don\'t think?

**[\>\>]{.underline}**

No, that is for the whole group. It\'s just, it was more of a
administrative meeting.

**[\>\>]{.underline}**

Okay.

**[\>\>]{.underline}**

Get ready.

**[\>\>]{.underline}**

So in other words, there will be no public, no recommendations, no
decisions made. This was mainly a housekeeping moving forward, what is
our deliverable, to the biosurveillance, the formation of that
deliverable. Where the group \-- you know, \--

**[\>\>]{.underline}**

Okay.

**[\>\>]{.underline}**

So what\'s the date for the next call like this, Scott?

**[\>\>]{.underline}**

The 19th \--

**[\>\>]{.underline}**

It \-- it is from 2:00 to 4:00.

**[\>\>]{.underline}**

I\'m sorry, what date?

**[\>\>]{.underline}**

The 3rd of October.

**[\>\>]{.underline}**

Okay.

**[\>\>]{.underline}**

And the calendar is updated that I sent.

**[\>\>]{.underline}**

Okay, thanks.

**[\>\>]{.underline}**

So if not, please correct me.

**[\>\>]{.underline}**

Could we go on a little bit further, so I know? After October 3rd,
what\'s the next one?

**[\>\>]{.underline}**

We don\'t really have one at that point, because we\'re starting to get
into the biosurveillance committee \-- or the Workgroup is on the 17th
from 1:00 to 4:00. So that was going to be our final recommendation. And
then the AHIC final presentation to the full committee \-- or the
Community, is on the 31st.

**[\>\>]{.underline}**

We don\'t have a lot of time left here.

**[\>\>]{.underline}**

Maybe we need to retreat.

\[Laughter\]

**[\>\>]{.underline}**

Charge.

**[\>\>]{.underline}**

Backed into the ONC office building.

**[\>\>]{.underline}**

Would that be at Aspen or Vail?

**[\>\>]{.underline}**

Or the elevator.

**[\>\>]{.underline}**

Got a place in Breckenridge that\'s open.

**[\>\>]{.underline}**

We have a lot to do for our October 3rd meeting to wrap up.

**[\>\>]{.underline}**

Right.

**[\>\>]{.underline}**

You may want to check and see if we need an extra half an hour on that
call.

**[\>\>]{.underline}**

Okay, I certainly will.

**[\>\>]{.underline}**

Yeah.

**[\>\>]{.underline}**

If people can manage that, it\'s \-- that\'s going to really set the
pace for the final reports and all of our agreements.

**[\>\>]{.underline}**

Okay, terrific. Any other questions or issues, Scott, to wrap up, or can
we \--

**[\>\>]{.underline}**

No, I think \--

**[\>\>]{.underline}**

Are we done?

**[\>\>]{.underline}**

I think that\'s it for right now, at least from my end.

**[\>\>]{.underline}**

Okay. Well, from my perspective, thank you everyone again, great
comments and suggestions.

**[\>\> Art Davidson:]{.underline}**

Thank you as well. This is Art. I look forward to our finishing this
table.

**[\>\>]{.underline}**

Me, too. And we got a lot of pieces to pull together into that report.
It will \-- I think we\'ll have good material to forward on.

**[\>\>]{.underline}**

Thank you.

**[\>\>]{.underline}**

Sounds good.

**[\>\>]{.underline}**

Have a good weekend.

**[\>\>]{.underline}**

Thank you for your leadership.

**[\>\>]{.underline}**

Yep.

**[\>\>]{.underline}**

Well, we\'ll be speaking to you next week.

**[\>\>]{.underline}**

Okay.

**[\>\>]{.underline}**

Thank you.

**[\>\>]{.underline}**

Thank you very much.

**[\>\>]{.underline}**

Okay.

**[\>\>]{.underline}**

Bye-bye.

**[\>\>]{.underline}**

Bye.