American Health Information Community

Biosurveillance Data Steering Group #5

September 5, 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.*

Okay. We will begin with a very quick roll call for today\'s
Biosurveillance Data Steering Group meeting, and I will turn it over to
the co‑chairs. On the phone today, Laura Conn. Co‑chairs are Art
Davidson and Marty LaVenture, Eileen Koski, Paula Soper. Lynn Steele.
Bill Stephens. A couple of presenters also joining on the phone today.
Farzad Mostashari from New York Department of Health and Shaun Grannis.
Is there anybody else on the phone who we have missed? Anybody else in
the building over at ONC that should be introduced that we have missed?

Hearing none, very quickly to review the procedures. For the Workgroup
members on the phone, please keep your phone muted when you are not
speaking, and when you do make a comment, please say your name first so
we all know who is speaking. And if you are following along with the
Webcast, don\'t press any of the buttons to advance or reverse the
slides. And those members of the public, you will be given a chance to
ask make a comment or make a comment in the meeting, and we will post
further instructions for that when the time comes. And that\'s all.

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

Well, Art and Marty, I think I will turn it over to y\'all and I think
we should get right into the presenters here. And I think we have Farzad
up first and then Shaun second, if that would be okay.

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

That sounds fine. Why don\'t we just go ahead and get started, unless
Marty had some comments beforehand.

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

No. I\'m just really pleased and appreciative for Farzad and Shaun to be
here today. And welcome everyone back from the holiday, and thank you
for being here. We have got a full agenda so lets move right into it.

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

Okay. This is Farzad Mostashari of the New York Department of Health.
The ‑‑ I sent my slides in with apologies, I think too late to have been
distributed; but they will be, I hope, posted and I\'m going to
basically talk through the content on the slides.

I had just a few general comments about the documents that I received,
and I think it\'s appropriate to recognize that this Data Steering
Committee\'s efforts in defining a minimum data set for biosurveillance
is likely to be an ongoing process and the, you know, this is ‑‑ I
recognize this is not the final word and that, as the utility for
additional data elements and the importance of them and the feasibility
certainly changes, those additional data elements will, may become
included in a minimum data set in the future, but just recognizing that
the focus appears to be on what is, what has demonstrated utility and
feasible in the near term here.

I also recognize that the Steering Committee is not endorsing any
particular architecture or policy decisions, for example centralized
versus systems or systems or Federated model for surveillance, and that
the minimum data needed may be different at different levels, at
different levels, public, state and federal. For example, the named
reporting for, report of ‑‑ may be appropriate for the local or state
level but not appropriate for the federal level. And I\'m taking this
effort to really be focusing on what would be the minimum data needed at
the federal level. So those are the assumptions that I\'m kind of going
into in these comments.

The facility level data elements, the base facility data elements are
clearly generally available. In fact, they are unlikely to change. The
facility location and number of total facility beds, regardless of its
licensing status and also facility beds considered licensed. And those
probably don\'t need to be transmitted continuously in real-time, and
kind of a lookup table might be sufficient. The daily facility summary
report addresses a need for monitoring resources and utilization in
public health emergencies, clearly one of the Secretary\'s priorities.
Manual reporting of some of these elements is, I think, currently
feasible in our jurisdiction. We do have a system that participated in
the HAvBED demonstration project called HERDS. And I think certainly
that is feasible for some of the data. The amount of work required
though to, to do all of these on an ongoing basis, I think, would be
prohibitive. So I think the resources would make it unsustainable for
routine reporting; but then again, is it really necessary to have all
these, all this information from across the country reported routinely
or is it something that, as we do with our HAvBED system, would it be
something that might be turned on in the event of a public health
emergency or in the event of a concern. So I think that the minimum data
elements seem generally appropriate for, you know, within the public
health emergency. But routine reporting at least, until the automated
reporting may be feasible, is not at the current time. This is something
that the Certification Commission Committee for Health Technology
Information, proof in‑patient clinical information systems imbedding the
capability for producing some of these reports on an ongoing basis based
on transaction data would clearly be something that would be within the
purview of this entire process.

In terms of patient data elements, I would strongly agree with the
suggestion, the comments that it should be limited to ADT or admission
discharging and transfer event rather than every single patient event,
which wouldn\'t be really daily but would be for hospitalized patients,
could literally be thousands of events. HL7 events types within a
system.\
\
So again, the utility and the feasibility really lies with limiting it
to the ADT type of events. The encounter day/time by analogy admission
date which would be more for emergency or hospitalizations is feasible
and appropriate. Data birth and age, you know, it mentions that age
could be categorated based on data birth, but I think more appropriate
and less concerning in terms of privacy issues would be an age with a
unit next to it. So if, if the person is an infant that is two months
old, there could be two and the unit would be months. As another way to
get at what we are really trying to get to, without introducing the
re‑identification possibilities that really, you get significant once
you have combinations of things like month and year and birth, gender,
and ZIP code. The ZIP code is the other issue similarly.

The HIPAA guidelines say that, you know, if the population for ZIP code
is less than a certain cut‑off amount, I think maybe 30,000, then it
should be limited. Not the full five are not presented. And I think
again, if the purpose here is national surveillance, then that might be
an appropriate limitation to also put in place.

But these data elements are clearly all feasible and obtainable from
admission, discharge, transfer information systems which are widely in
place.

Clinical data elements on the other hand, some of them may not be
available as widely. I would again reiterate that it should be limited
to ADT type of encounters rather than every single hospital event. On
SID date can be very useful, but it is also very unlikely to be
available in a structured format. Almost anywhere. Pulse-ox may be
available but the, I\'m not sure if the utility for that has been
demonstrated. In addition, it could be, from a data perspective it could
be rather complicated because there could be numerous different
Pulse-oxes taken, indeed continuous monitoring of pulse-oxes that might
be within, stored within some information systems. So I think that need
more thought needs to go into that one. And then nursing triage notes
are generally not available only within context where there are EMRs
capable. Utility had not been shown, to my knowledge. And it really does
introduce significant privacy concerns in terms of the free text, what
might be in that free text.

The next group was lab and radiology groups. I\'m glad there is a
recognition there would be a subset of all lab and radiology data, not
all. They are generally available, I think, but again the utility has
not clearly been shown across a wide swath. So this consult may have
merit, if narrowly focused some examples come to mind are viral assays
or viral resistance patterns. Radiology results which were not discussed
here may be useful in some instances, like widened mediastinum, but may
not be readily available in structured format and I think is beyond the
scope of this discussion.

And finally, lab or microresults, again defining the subset, would be
critical. There would be reasons to the ‑‑ to include HIV or STD or
laboratory codes to submit can be an arduous process requiring a lot of
work on the institution\'s side.\
\
And I guess a question that I have is whether there are official
standards or standard setting bodies for all of these data elements. I
know that the work, PHIN initiatives and meds has been really tremendous
in this but there may be, may be appropriate for the data steering
committee, after consulting with those groups, to see whether the
statement around the necessity for standards and kind of official,
officially enshrining some of those standards through some of the larger
standard setting bodies.

For example, test interpretation may be one where there really are not.
I know that for many of these, we in New York City do not currently have
access to kind of generally agreed upon standards for how those should
be coded so that may be a problem elsewhere as well. And then finally
the need to coordinate with national, and really local as well,
electronic lab report initiatives. The mention is made in the general
document about how individual case reporting of note final reportable
diseases is the desired outcome of this; but it is not clear to me how
these, this initiative is going to dovetail with the national electronic
lab reporting initiatives that have been going on for some time in a way
that could be helpful and complementary rather than distracting from
those efforts.

So those are my comments. Thank you very much for opportunity to speak.

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

Thank you Farzad. This is Art. Maybe we should go on to Shaun's
presentation at this point. Dr. Grannis, and then might have some
opportunity for some questions from the group. Or, Marty, do you think
we should go to questions now?

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

Well, let\'s hear the full spectrum and then perhaps questions. We have
a tight agenda. Want to make sure we hear ‑‑

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

Right.

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

‑‑ hear the comments, and then it would be wonderful to probe a couple
of questions here.

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

Great. I ‑‑ this is Shaun Grannis. As I think my presentation will be
complementary to Farzad\'s, we took a slightly different perspective on
commenting. So what I will start with is, the fact that I work at
Regenstrief, the Institute. And we have been developing and implementing
and studying real world clinical information systems for quite some
time. To that effect, in the mid 90s we developed the Indiana Network
for Patient Care which connects, depending on what day of the week it
is, at least 17 hospitals. And we are using HL7 for all of our
hospitals, standardized to a common vocabulary and mapped to\
LOINC throughout. The INPC, since the late 90s, has been automatically
delivering laboratory reporting data to local and state health
departments. And in 2002 Regenstrief, in conjunction with the State
Department of Health, began rolling out our state‑wide surveillance
system using standards-based messaging. So the system supports not only
the syndromic surveillance component but also the electronic laboratory
and communicable disease surveillance component using standards based
infrastructure. We have not built a silo. We have built a system that
helps to integrate data together.

So in reviewing the minimum data set, I\'m on slide 2 now. I\'m going to
just go through the five categories as Farzad did. And I would ‑‑ as I
went through these data elements I sort of put them into two categories:
One, either they are being collected or they are not. That\'s the big
division. And of those that are being collected, is there a reasonable
standard that exists today for unifying what is being collected and, if
not, is there opportunity to begin standardizing what is being
collected? And then the third bucket was just simply whether or not data
elements were being collected today. In the interest of time, I\'ll
focus on data elements that typically are not captured or are captured
with a fair amount of variability.

Moving on to slide 3, the base facility data element category, agree
entirely with Farzad and that, the facility identifiers are routinely
transmitted. Facility name and location can be derived because this
information is generally static. Similarly, location can be derived as
well. We ‑‑ the State Department of Health licenses hospitals for beds
and so the information regarding total bed capacity and licensing,
again, can be derived from lookup tables.

Moving on to slide 4, the daily facilities summary report elements. We
do not currently transmit electronically any of this information. And I
would just comment that although all hospitals generate census reports
for their internal operations, few commercial systems have standard face
(inaudible) interfaces from these systems. So over the short-term
interfaces could have to be built for these systems, although one major
written in implementation guide for transmitting these reports. An
implementation guide does not eliminate the resource intensive work
necessary to create those transactions. So the real work is not in
coming up with standard. The real work is in interfacing and translating
your local codes into something that\'s standards-based.

Further in this category, the concept I would argue require further
definition and clarification. For example, item number 11, facility
operations defined as the status of supplies necessary for facility
operations. And it seems ambiguous. I don\'t know if you are talking
about enough diesel for the generator or enough flu shots to immunize
the patients. So until data elements are clearly specified so that they
can be clearly standardized, it is a challenge to create level 4 in
their operability with these elements.

Moving on to slide 5 and the patient data elements section. We do not
here in central Indiana use a pseudonymous data linker because both ‑‑
data are sent as identifiable elements according to the state
regulations. The issue of patient date of birth with month and year of
birth and age, I\'m confused why both would need, would be necessary.
And in fact, by sending both as Farzad mentioned, there is an increased
privacy risk with that, though in general those data elements are, can
be routinely collected.\
\
The pseudonymous identifier again, because we have not had a need for
it, we don\'t implement it but could be implemented.

> Moving on to slide 6, LOINC elements. High degree of variability here.
> Diagnosis and ‑‑ code are invariably set through ADT interfaces. Some
> hospital systems use a separate billing mechanism so they are not
> tightly coupled to their ADT interface. Diagnosis type, even more so.
> Invariably transmitted. Patient class again, where most of these data
> elements based on the Excel spreadsheet that I received, I would have
> a number of questions about clarifying and specifying exactly what is
> meant by that data element. For instance, patient class is an HL7
> field, which specifies ED out‑patient and/or in‑patient there, and
> I\'m not sure if that\'s what you are looking for. Chief complaint is
> universally collected. Only one of the 67 hospitals that we have
> currently connected actually captures both pulse and the, and
> temperature in electronic format. So that is a nascent field requiring
> additional work ‑‑ nursing triage notes or ‑‑ is included in encounter
> transmissions it ‑‑ today though a great deal of work to be done
> there.\
> \
> Moving on to laboratory test order elements ‑‑ and a point of
> clarification that the group may be able to comment on. So in
> laboratory radiology test order elements section, you included
> radiology; but in the results section, for that heading, there was no
> mention of radiology. So I\'m not sure if you are interested in
> radiology results or not. But we certainly do collect order number,
> test procedure, name and procedure code using our standardized
> vocabulary. We recently ‑‑ the LOINC group has been coming up with
> hierarchies for order sets.
>
> In general, a lot of work has been done in standardizing clinical
> results, not standardizing orders. So order, electronic order trends
> exist today, but the information contained in them are
> non-standardized and highly variable. And I would argue that orders
> are sort of the wild, wild West of the vocabulary world.
>
> Much work remains to transform orders into information for broad
> consumption. For example, the example I like to use is, if I order a
> hepatitis panel, I may order the same thing at different institutions,
> different hospitals, but the tests performed are different so the
> results retrieved will be different. So just recognizing that the
> information models will be different, the codes used to represent the
> same concept may be different. So there is a great deal of work that
> still needs to be done here.
>
> In the final category, laboratory, microbiology results, there is a
> fair amount of variability in these elements. Again I was unclear
> about some of the elements in terms of what was exactly meant. For
> example, item 49, report status is an HL7 field. You have preliminary
> and final. And labs are notorious for not filling in the result status
> field. So that is sometimes challenging. The other flag that I would
> highly advocate for is a normal or abnormal flag that labs can flap,
> and that has a great deal with electronic laboratory reporting. And
> again labs are notorious for not reporting that.
>
> Looking through the remainder of these ‑‑ it is unclear how the group
> wants to delineate the difference between specimen and specimen
> source. So if I have a urine specimen, I\'m fairly certain where that
> comes from. If I have a blood specimen, not quite certain where that
> may have come from in the body so there is some specification issues
> there that can be challenging.
>
> Often in the result, the ordered test code may not be there. The
> result code may be there. So again, there is a great deal of
> variability in this that I think the ELINCS specification will go a
> long way to helping combine the ordered information with the results
> information.
>
> Test status, I\'m unclear how item number 60, test status, differs
> from report status. And again, that clarification would be helpful.
> And as a general aside, as co‑chair of the HITSP, clarifying the
> differences in these data elements will go a long way toward helping
> the HITSP groups coming up with the right standards to delivering
> these kind of data elements.\
> \
> I will finish up with the final slide and start by a general concept.
> I think about these data elements and the strategies for getting these
> data elements along two paths. If the data elements are already
> collected, then the challenge is standardizing them. If they are not
> collected today, then they need to be very clearly defined and the use
> of that data needs to be very clearly defined. And you need to clearly
> define that use to get buy‑in from the people who are going to be
> collecting that data for you. So I go back again to, I believe it was
> item number 11, and say, okay, how am I going to justify to the CIO of
> Hospital A that they need to pay somebody to routinely capture
> facility operations code? How is that going to help us in an
> emergency? There very well may be a clearance to that question, but
> that needs to be communicated very clearly to folks as we begin to
> build out these standards and specifications. So I will stop there.

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

Thank you, Shaun.

For the group now having heard these two very distinguished and
knowledgeable public health researchers, any comments or questions
regarding the two presentations?

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

This is Laura. Don\'t we also have ACLA on the line?

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

Oh, I\'m sorry.

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

I thought I heard Jason Dubois join.

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

Yes, this is Jason. If I spoke to ‑‑ hi, Laura.

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

Hi.

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

I spoke to Kelly earlier in the ‑‑ I guess Friday actually. We didn\'t
know about this meeting until late Friday. So unfortunately we don\'t
have formal comments to make at this time, but we are striving to have
something to the committee by Friday close of business for your
consideration. Although just as a quick note, I will reinforce what was
just said about ELINCS as a means for lab and microresults which is, you
know, we are leveraging that both with HITSP as well as with the
Certification Commission for Health Information Technology, which has
already included that in their 2007 draft in their operability criteria.
So like I said, we don\'t have anything at this time but we will be
hopefully submitting something by week\'s end.

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

Thank you. Any questions from the group or comments back to our two
presenters?

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

This is Marty. Again, thank you very much. Excellent summary here. When
you look at the materials, is there any obvious missing pieces? When you
think of a minimum data set for biosurveillance from definition that is
used here with regard to ASTHO, are there some missing pieces or data
elements from your perspective, or is it really about the execution, the
standards piece, and then defining the use of the ones that are here?

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

This is Farzad. I think it covers the ‑‑ it covers the ground very well.
The one piece that might bear just drawing a distinction from is the
point about epidemiologic investigations in the, for example the nature
definition. And just to make the point that we cannot expect to get all
the information we need for epidemiologic investigations from automated,
ongoing perspective transmission of data from information systems. I
think we just have to recognize that.

And then this will, in all likelihood continue for the foreseeable
future to require some shoe leather epidemiology, and putting in my
usual plug for public health resources to do that. But even where, you
know, automated systems exist and state‑of‑the‑art information
technology is available, the North Carolina system has a very
interesting reach back capability where, in the event that a, one or
more individual cases are the subject of a epidemiologic investigation,
they can tap into the clinical information system to get at that much of
deeper, richer clinical data. That could include potentially the free
text information as well.\
\
So I think the ‑‑ we do have do kind of draw a distinction between what
is needed for ongoing prospective surveillance, and I think you have
covered the ground here. And then what might be very attractive to have
for, you know, to be able to then drill down and do much more
sophisticated types of queries in the event of something really of
public health concern.

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

Great. Thank you.

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

Thank you. Maybe I could take your point there, Farzad, and ask Shaun
about this. In Indiana where you now have the electronic lab reporting
and chemical disease reporting, are public health officials there able
to reach back into your system and retrieve additional information, or
does it really fall back on typical public health shoe leather
epidemiology?

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

Today the public health users, strict public health users do not have
access to that data. Those physicians who also provide care within the
INPC, who are also public health employees, do have access to that data
for public health purposes. So the, you know, the INPC is the Indiana
Network for Patient Care. So it is designed for patient care purposes,
and we are actually working on developing some mechanisms to open up
patient records to public health. So just as in our model in the INPC,
when a patient shows up to an emergency department, their record is
opened up to emergency department physicians. When a patient has a
positive reportable condition, we are working on mechanisms to open up
that chart to the appropriate public health official but today they
cannot reach back into the system. Technologically it is there, it is
working through those, you know, policies and permission issues.

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

M\'hmm. Thank you.

Any further questions from the group? Or others on the line?

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

This is Lynn Steele. I just had a question about thinking about limiting
the data to what exists in ADT systems. And I certainly, Farzad,
understand your point that that\'s the data that has been demonstrated
in most systems to be useful. However, it leaves a lot of interpretation
that will require and has required that traditional shoe leather
epidemiology, meaning having to go back and get additional clinical
information. So this movement toward nursing triage notes and other
things that have demonstrated some initial utilities, such as in the
North Carolina system, is sort of that movement to getting the right
clinical data elements that would help inform the beginning of those
investigations. I just wanted to hear your thoughts on that.

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

Sure, Lynn. I think there is two issues here. One is about whether we
want ongoing, for example, temperature measurements throughout a
hospital stay to be reported. And I think when ‑‑ my understanding of
the comment here was that the clinical data ‑‑ would be transmitted for
each admission/discharge and transfer at a facility. Not necessarily for
all hospitalized patients during their hospital stay.

So the temperature may not come from an ADT system. It may come from a
clinical information system, but it would only be transmitted when
associated with an admission, discharge, or transfer. So kind of, what
are the trigger events, I guess, would be one way to put it rather than
all the information residing within an ADT system. So that\'s one
clarification of my understanding of the recommendation.

The second is this issue of, and it gets back to, you know, don\'t we
want to help extend our capabilities? And I think we clearly do. And
this is clearly going to be an iterative process whereby this is not the
last word on what the minimum dataset is going to be. And as a utility
for additional data, elements might be shown and demonstrated. Then it
would be entirely perfect to go back and say, you know, we have built an
architecture that can handle this variety of different data elements and
we now have evidence from our pilot studies, from our research studies,
academics and otherwise, that this data element is useful.

So now with added minimum data elements said. So I\'m not seeing the
minimum data element as being the, you know, what limits investigation
into potential utility of additional measures. I think I\'m seeing it as
a reflection of what do we have evidence of utility and feasibility of
today.

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

Thank you.

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

Thank you. Thank you both, Shaun and Farzad. Marty, I think our time is
sort of limited here and we have a pretty full agenda.

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

Yes.

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

Might we move along?

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

We ‑‑ and certainly any follow‑up, either questions from the group, we
would love to hear them. And we look forward to getting your slides as
well, Farzad. And thank you, Shaun, for yours as well. Were we expecting
any additional comments in writing?

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

Yes. Hopefully by Friday we should know.

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

Okay. Great. Well, this is terrific. This is very helpful input. So
thank you very much again.

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

Thank you.

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

Shall we move along? I don\'t want to spend too much time on the
summaries. I don\'t know how many of you had a chance to read the
summaries from the 26th and the 8th. I don\'t believe there is a summary
yet for our face‑to‑face meeting that we have circulated, but were there
any comments on those summaries? And if so, maybe we could quickly
discuss them now. We have such a full agenda, I\'m just afraid we\'re
going to fall behind here.

No comments?

Well, we will certainly ‑‑ you are welcome to send comments to Marty or
to me or to Scott if you see something that seems askew in the minutes.
But why don\'t we go ahead and proceed with our next item on the agenda?

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

Hearing none, we will take that as approval pending any comments.

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

Right.

So the next item on the agenda was the preconditions list. And ‑‑ open
mine up here. Just one second. We have ‑‑ Marty and I worked on this
list over the last couple of weeks since our meeting. We have added some
things, some things that speak to items that Farzad was discussing in
the early part of his presentation as well are on this list. And we had
been through about nine points at the end of our meeting. And the last
four or five points are ones that have been added. So maybe I can give
you a minute to read through these, and if there are any questions we
could begin a little discussion around this. Again, this is an item that
we have been working on. We will continue to work on. I think it\'s an
area that we would just like to catch everybody up on. But if there is
any significant comments at this point, please bring them to our
attention.

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

The intent here of course is to focus and clarify the intent of our
discussion as we go through the minimum dataset as they relate to
preconditions.

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

This is Laura. I guess, looking at number 12, I think the first sentence
is within the purview of HITSP and then setting the standard of, will
help prescribe the method that this data will be transferred to public
health. I was not sure what we meant by the architectural synergies with
local and regional health investments. But ‑‑

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

So ‑‑

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

Maybe ‑‑

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

If I might answer that.

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

Sure.

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

I think that what we are trying to do here is to recognize that there
are local investments made in health information exchange and that we
should be cognizant of that and trying to leverage that whenever
possible to achieve exchange of the minimum data set with public health
authorities, that there may be a way to use health information exchanges
around communities or across an entire state to achieve our goals. So it
was just opening up that idea that there are these efforts going on
outside of what we may be thinking about in this group that may
influence the way that someone accomplishes this.

Is the wording there not okay with you, Laura, or is it confusing still?

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

Well, I just don\'t ‑‑ I agree with what you just said. I don\'t want us
to give the impression that we are going to, you know ‑‑ investment is
not standards-based, that we are going to endorse that and try and
figure out how to move that, you know, and have that in the
architecture.

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

Okay. So you added the words \"standards-based\". So somehow if we could
get that concept into this point, would that be, meet your approval,
that it was working toward some national, national or emerging national
standards ‑‑

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

Yes, I think that would be helpful.

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

Okay. I think we can do that.

I noticed something as I was reading this through. In point 11, we
single out emergency departments, but it might be other clinical
providers like infection control practitioners so we might kind of
modify that one as well. I know that, you know, because Ed is on the
committee we have a strong leaning towards emergency departments, but
there may be other health care departments we should be giving examples
of as well.

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

And Ed agrees with that.

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

Okay. Thanks, Ed.

Any other comments about these? I mean, and you are all welcome. If we
don\'t have enough time to cover them today, I think this is the first
time that the group has seen items 10 ‑‑ well, maybe 11 through 14. So
if you come up with something, just shoot me or Marty or Scott an e‑mail
and we will figure out how to reword this, if there is something
concerning. We have tried to add in the NACCHO statements as well. I
think Paula is on the call and Paula worked on that document from
NACCHO, which we have now reference in this preconditions document as
well.\
\
**[\>\> Eileen Koski:]{.underline}**

Can I ‑‑ this is Eileen Koski. I have a question about item 10.

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

Yes.

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

It says multi‑jurisdictional approach include ‑‑ all jurisdictions will
simultaneously have access to timely data. What exactly is the
expectation there in terms of where this data ‑‑ I mean, it is going
into a single repository from the data sources and then other people can
go in and get it? It is not the idea that it would be transmitted to
multiple locations. Right?

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

I don\'t think that we have an idea about that. I think the intent here
was that no one jurisdiction would be getting it without allowing other
jurisdictions to simultaneously get it. And if they don\'t have a
mechanism to receive it, well, that\'s ‑‑ you know, that\'s something
that we are not going to be able to solve. It is just that intent was to
say that one jurisdiction did not have a priority in receiving data.

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

Okay. It is just, it seems that it needs clarifying to some degree in
terms of implementing it because it is hard to know if people would be
expected to send data simultaneously to multiple jurisdictions or to one
place from which different people would have access. And I realize that,
you know, trying to look at architecture that has not quite been defined
yet, but I think that that makes a big difference for ‑‑

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

I mean ‑‑ this is Kelly Cronin. I think it is really hard to make some
assumptions around architecture where it may vary from region to region
or state to state or jurisdiction to jurisdiction. And we don\'t have
all the answers right now so I don\'t know that we can safely add an
assumption to add on whether or not it would be some kind of repository
or intermediary that would be responsible for ensuring that simultaneous
data flow.

I mean, that\'s a concept that we have talked about in past but had
never come to closure on. There\'s just some, you know, obvious
realities that, we don\'t have instant resources to create a lot of new
infrastructure. But I do understand your point. I think that the concept
of simultaneous data flow really came from the initial six months around
this subject and was reflected in the May 16th recommendations and was
one of the assumptions really, I think, important for this group to keep
in mind. Because even if we don\'t have the architectural solutions ‑‑
specify, I think that\'s just one of our goals is to ensure that we will
enable, or that this data could flow across jurisdictions if the
architecture were to allow for it.

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

Okay. And I don\'t ‑‑ you know, I agree completely with the goal. I
just, as I look at it, it can turn me a little bit ‑‑

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

I will try to work on that a little bit, Eileen. See if we can figure
out a way how to get into that. But I don\'t want to get too much into
architecture here because, as Kelly says, that\'s not our role here.

Any other comments from the group?

Okay. Well, I guess we could move on to the next item, Marty.

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

That sounds good, Art. We will take these then with the adopted changes.
We will work on this as the next draft and get it back out to the
committee. Does that sound the right way to go? Terrific.

Our next area is the functional area results. And we wanted to try to ‑‑
if you can bring up that spreadsheet or make it available however you
can. We had a few, if you recall, made a great deal of progress in
identifying the short‑term/long‑term components and what was not in
scope. And we had a few left that we wanted to try to finish so we could
wrap up the functional area piece and wanted to walk through this sheet
with that part.

In addition, we have tried to update, I believe, some of the notes a
little bit, and they need some additional note comments in these areas
as well. It will be the next two, two steps that we need focus on. So
for today we will be focusing on the white, if you are using the colored
spreadsheet, I believe it starts with number 7 and tried to identify
what is not in scope on short and longer term. Is that your
understanding ago well, Art?

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

Yes. Number 7 under the outbreak management.

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

Yes. Outbreak management, number 7 is one that we have not decided on.
The original counts would suggest perhaps not in scope. But can we can
come to consensus on this?

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

Anybody feel this should be in scope?

It almost sounds like a principal statement rather than a scope thing,
that you should be able to be flexible to change your requirements. And
that\'s ‑‑ I was not sure what exactly it meant.

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

Me either.

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

Well, Laura is on the phone. Laura is a co‑author.

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

I\'m sorry, which one are we talking about?

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

The outbreak management. Line 14 in the spreadsheet. The seventh item
under outbreak management. Flexibility, support agent ‑‑ and emerging
requirements while adhering to standard terminology and data
relationships.

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

It is really a system capability so that when there\'s an outbreak
that\'s multi‑jurisdictional and we need to add questions, we have the
ability to do that in a somewhat standard way using standard terminology
so that we can then have multi‑jurisdictional data to compare during a
response effort. So I don\'t think it\'s, it is a little bit irrelevant,
I think, for this conversation because it is really more of a system
capability than it is an activity.

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

So that sounds to me like a, not in scope. I mean, certainly we are only
listening, as the two presenters spoke about earlier, if it is ADT
messages, we don\'t really have a way to modify what is being
transmitted in the ADT messages or even adding other laboratory or other
systems. We wouldn\'t really be expecting that we could modify those
systems during an event. Is that what this means?

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

Right. And I don\'t think ‑‑ I mean, in this activity we were intending
to have data try and be turned on in an emergency. We have seen that
that ‑‑ difficult in the past responses we have done.

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

So then Farzad\'s point was that, you know, you might be able to turn on
a data collection tool at the moment that it\'s needed but not on a
routine basis be collecting, I think his ‑‑ you know, with reference to
maybe have bed or something like that during an event. Would that meet
this, or this functional area, or do you think that that\'s not even
coming close?

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

This is Laura. From ‑‑ I mean, my experience in response, that it\'s
really difficult to turn on data sources in a standard way. Multiple
data sources in a standard MNL. I think that\'s why ‑‑ what we are
talking about here is getting some regular flow of data that could be
useful in those times and having it available when we need to look at
it, not having something turn on and, in the most critical times, when
all resources are stretched.

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

And this is Ed. We have been able to do that though for some bed
reporting on a type of thing, and the MS type data. The importance there
is using a system that they are familiar with and drilling it so that it
is not an unusual event for them. It is not something that\'s out of the
blue. It is not impossible, but it is difficult.

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

Right. Well, this is Marty. I\'m hearing, I guess, a couple of concepts
here. One is the notion, the difference between flexibility to add,
versus filtering to turn off. You have already predetermined you want
it, but you only want it in certain situations versus the ability to
collect new data that was not necessarily prescribed ahead of time, and
I think that certainly would be more challenging.

For this item perhaps, is what we are ‑‑ what I\'m hearing is it is
labeled as not in scope, per se, but it is a characteristic that should
be examined into the future. What really is feasible around being
flexible?

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

So you think that maybe this is something we might put in the
longer‑term category, Marty? I mean, from the point of view of adding
new data, I think this system is not designed to do that during a
crisis. But turning something on that, as Ed says, is, you know, you can
drill on it periodically. Is that how we want to interpret this number
7? And if so, should it be in the two or three‑year group or should we
just toss it out as not in scope?

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

Well, this is Marty. I like that interpretation in terms of notes, being
able to have the ability to either turn off or filter whatever term we
would like to use.

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

Right.

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

Then I think it is feasible to be in a longer-term.

Comments from the rest of the group? Looked like this is going to be
yellow.

No other comments. How do we vote here without seeing each other?

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

Well, we have sort of a motion to move it to yellow, and, in terms of
the discussion today we can, we always can have some reflection time.
But at this stage the comments would reflect the yellow, with modified
comment, clarifying what we mean by flexibility here. Any one opposed to
that? Okay.

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

Sounds good to me.

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

And, Scott, you have captured all that?

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

Yes. I have number 7 now in longer term changed to yellow.

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

Okay. Thank you.

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

Terrific.

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

Great.

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

The next item in white is under connecting laboratory systems, at least
the one I have here. And number 3, monitoring of testing activity to
project low distribution during a large‑scale event. And looks like sort
of diverse feelings. Is that an interpretation issue?

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

I mean, isn\'t this a little bit of what the LRN is supposed to be doing
for public health labs?

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

Absolutely.

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

That is, is this really something we can expect to collect from all labs
across the country in an adequate manner, you know, during a crisis? Do
we already have all the tests that we think we might need being asked
for?

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

Well, another thing is, I guess when I read ‑‑ this is Eileen. I thought
this seemed like what you were trying to get at with the HAvBED
specification and it seemed like what you were trying to get at is
capacity in the case of an event. And the question is, you know, what ‑‑
unlike the hospitals where you do have licensing that says a hospital is
licensed for a thousand beds or whatever, and so maybe they have got 900
patients in so you know they have got 100 available beds. What the
normal laboratory volume is does not really tell you what the capacity
is. So I\'m not sure what this is trying to get at.

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

This is geared more toward, or was when we wrote it, more towards the
LRN lab, public health lab, and what their capacities are to help out in
emergencies to accept extra ‑‑ et cetera.

I mean, thinking of it in a national response scenario, you know,
knowing at some level what capacity that our clinical labs have in a
catastrophic event might be helpful, although I don\'t know what the
capacities of the current clinical labs are in order to monitor this in
an ongoing electronic way. Because agreed, obviously it\'s the same
issue with the monitoring of the hospital beds and resources depending
on what\'s, who is staffed and what kind of resources are available as,
you know, plays on how this turns out and how useful this data would be.

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

Oh, and, you know, obviously I cannot speak for the public health labs
and the LRN, but from a commercial lab perspective, I don\'t think this
is information that would be electronically available in any system that
I\'m aware of today in any reasonably accessible form at that would tell
you what our capacity is or how much of it is in use.

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

I mean, what do you think of ‑‑ do you think it is something important
that we should have a system nationally that could tell us this kind of
information?

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

I mean, I can certainly see a use for it. And we have been in
discussions with APHL and NACCHO in relation to this in a disaster that
would certainly go beyond the NLRN in terms of a need. I think at a
minimum it is longer-term.

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

Right.

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

At an absolute minimum. And I could see how it might be in scope. But it
might be even a definitely longer-term because of the fact that is
correct as I said, I don\'t think there is any electronic version of
this data that\'s available anywhere, and I\'m not even sure how easy or
difficult that would be to create. Because there are more standard ways
of assessing the capacity of a hospital, or at least, you know.

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

Right. I don\'t disagree with anything you have said.

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

Yes.

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

I just wonder if it, the group has a whole thinks it is an important
activity for somebody to consider.

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

Well, it is certainly not part of surveillance though. It is keeping in
mind that this would be more part of a response thing.

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

Right.

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

This is Marty. It sounds like it is, certain amount of value question
here as well, as well as a logistics question. And so we\'re deciding
between longer-term or really not in scope. Longer-term would seem to
suggest that we want to, we would need additional data to evaluate it,
and not in scope, we essentially put it off as part of the minimum data
set point.

I would be comfortable with either longer-term or out of scope, but I
would like ‑‑ I don\'t know if other people have any different ‑‑
because we had said diversity of opinion on this, it would be
interesting to hear what other people thought.

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

Anyone on the line that voted for the short-term, and so we understand
the interpretation or the thinking behind this item?

Oh, good. That means we could vote it for yellow.

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

Yes, I think this issue about capacity is really not clear, how you
infer capacity from these, the number of tests performed. And you know,
back to one of the comments earlier was about whether it is diesel or
flu vaccine or is it laboratories.

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

Exactly.

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

And re‑agents.

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

And re‑agents, right. I mean, all those things, yes.

So to presume that we could, based on the number of tests done, figure
out capacity, that has not been proven. I don\'t even know whether the
labs have any way of doing that routinely now.

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

Well, that\'s what I\'m saying. I don\'t believe that any of us do
except in certain areas. But ‑‑ I would say generally the capacity
exceeds the observed usage, but by how much or how sustainable that is
over the long haul is a question mark.

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

I think during anthrax response that, I mean, the example is that when
they received, so many white powders to test in a day. They know that
they received the same amount over the next three or four days, that
they weren\'t going to be able to have capacity to test that. They
needed to figure out if there was another lab that they could have as a
backup, et cetera. So just in not necessarily looking at each individual
test to figure out what their load distribution needed to be, but just
on a general monitoring scale, that ‑‑ you know, they knew that if in
three days time they were not going to be able to handle their, the load
that they were going to have. It is just that, at that level initially
to think about what, how other labs would need to be involved. But I\'m
comfortable really either way, too. It is a little bit on the edge,
although I can see the usefulness of it in response at a national level.
You know, if it\'s this group or another group, I think it\'s an
important thing for us to know at least that there is not this capacity
at this point.

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

Well and, no, it is not available now in electronic form. And it would
even take quite a lot of thought to figure out what the meaningful
data ‑‑

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

What you would want, right.

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

That\'s a pretty long lead time to get really useful data.

So ‑‑ but again, I can see the potential value so I\'m still torn
between longer-term or not in scope. I guess leaning towards not in
scope, but I could see longer-term as well.

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

Any others on the call have any opinions about this?

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

This is Farzad. I think it is going to be almost impossible to create,
to calculate that based on structured data. A lot of ‑‑ for example, the
anthrax white powder event was mentioned. A lot of that has to do with
things that are, the capacity has to do with things that are very
difficult to quantify like how many of your staff are, you know,
performing at what level. And the physical layout and how that\'s going
to be influenced by people bringing in, you know, car doors from the
basement entrance, things like that. So my recommendation would be not,
that it not be included, but ‑‑

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

I vote to, for this to be not in scope at this time. And you know we can
re‑visit these things, but this just seems like such a stretch.

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

Yes.

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

I agree.

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

Good.

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

Marty. So ‑‑ anyone disagree? And otherwise we will move ahead with not
in scope at this time. Okay. Hearing none, let\'s move on to measures
and response administration items. We have several here. Some diverse
thinking. And as we think of the functional areas, think of how we want
to clarify these as well. The first one is, number one, support and
track administration of vaccines and prophylaxis.

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

Well, I think from our current minimum dataset I don\'t think we could
do that. Maybe I\'m wrong. But are we even looking at medications at
this point.

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

There is nothing that I recall.

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

Yes. So either we have to expand the minimum dataset to get this or this
one would not be in. I don\'t think we could expect that standard ADT
message is going to be able to give us this sort of information on a
regular basis. But there were quite a few that did vote for this.

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

Well, if we are not ‑‑ this is Marty. If we are not collecting the
medication information, then I\'m not sure where we would expand that to
include it.

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

I mean, if you had out‑patient office data then it could be a reason for
an office visit so that, you know, in the out‑patient data setting you
could get it potentially without medication information. But we don\'t,
we are focusing on ERs and hospitals and lab and radiology. So I just
don\'t see anything in our data universe that covers this.

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

Right. Well, that\'s a vote for not in scope. Is that what I\'m hearing?
Anybody feel otherwise?

We are making great progress here.

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

All right. Not in scope.

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

Do we have any Workgroup members on the call?

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

There are some ‑‑ are there any members on the call?

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

Yes. Bill Stephens, still here.

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

All right. Bill ‑‑

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

‑‑ on the call ‑‑

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

I agree.

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

Still here.

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

Okay.

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

I agree.

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

Sorry. Everybody was being too quiet today.

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

I\'m letting my members speak.

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

Number 2, support ‑‑ allocation for limited supplies. Similar diverse
views.

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

If nobody is going to speak, I will. This is Laura. I actually do think
that having the data will support this. It\'s not making the
determination but knowing how many patients are filling in what areas
might need vaccination or prophylaxis that would help the
distribution ‑‑ and allocation of supplies to certain areas.

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

This is Eileen. I agree. I think we have the data to support this.

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

Yes, I agree with this one, too. You know, especially if we got into the
area of ventilators or something like that. Not necessarily in vaccines,
but we have some data that we are collecting that would allow us to see
what is needed in hospitals or what has been used up in hospitals. So
this is one that, I think, I would vote for.

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

Longer-term or short-term? This is Marty.

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

I tend to think this is actually shorter-term in terms of being able to
look at where the concentration of cases are.

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

Where the concentration of, what?

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

Cases, or at least based on the surveillance data.

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

To project where there might be greater need coming up?

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

Yeah.

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

Yeah.

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

Yeah.

That\'s ‑‑ there is a proposal here for it to be green.

Any feelings to the contrary?

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

I say it was a green ‑‑ a green one-year myself for the same reasons.

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

Anybody have a differing opinion?

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

Hearing none, we have green for number 2.

And move on to number 3. Traceability to a drug lot vaccinator or
clinic.

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

I would say if we cannot do one, we certainly can\'t do three.

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

I agree.

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

Agreed.

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

Counts agreed as well. So we have a not in scope for number 3.

Any one have a contrary view?

Not.

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

Okay. Good.

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

And adverse agents monitoring, number 4.

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

It is just more complicated because obviously there could be adverse
events that would present to an ER. So I would tend to advocate for
longer-term here because I think it is a little more complicated to
think about exactly what we are looking for, but this is potentially at
least in scope. But I would say not short-term because I think it is a
little more complicated to tease out adverse events.

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

This is Ed. I think a lot of this ended up being a coding issue.

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

Yes.

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

Because diagnosis coding is allergic reaction. You don\'t know if
that\'s from a bee sting or taking an adverse reaction to a drug. So it
is just a little bit tricky in terms of the, teasing it out from the
collage.

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

And trying to pull this out of a chief complaint would be pretty hard as
well, I think.

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

Yeah.

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

Okay.

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

So then, Ed, are you thinking that this should be longer-term or not in
scope?

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

Well, I think you could do it longer-term. It is a matter of trying to
get some consistency and coding practices across the country. That\'s
not an easy ‑‑

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

Right.

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

‑‑ nut to crack.

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

This is Marty.

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

Capability of potentially monitoring for the ‑‑ is there. The
situational awareness component, if we knew that there was adverse
events occurring, based on vaccinations be given we could potentially be
looking at a system like this to see if we could identify those
patients.

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

So this is Marty. What I\'m hearing is perhaps a long term, but with
comments reflecting that what we really need is to look at consistency
in coding practices as well as, I guess, I would support the notion from
number 2 that this is really supporting adverse events monitoring. So as
a, reflecting that in\
the notes ‑‑

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

So, just want to be sure. Scott, some of these, capturing these comments
that we are having here that we can add those to the notes section? Or
‑‑

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

I am doing my best, but we have a full transcript that comes back to us.

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

Great. Okay. So we can fill this in later. Because I think there have
been some good comments here. And I would like to clean up this notes
section so that it has meaning to the subsequent reader.

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

You got it.

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

Okay. Great.

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

Terrific. So are we ‑‑ we have a proposal for long-term?

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

M\'hmm.

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

M\'hmm.

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

And any contrary feelings? Hearing none, that\'s number 4.

And number 5. This is ‑‑ you guys are great here. It is going well.
Followup of patients, example of vaccine take response evaluation. Most
folks thought this was not in scope.

Maybe if there is anybody on the call who thought it was, they could
explain why?

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

I guess that means that it can be out of scope.

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

I see this, similar to the traceability, or support of vaccine tracking
administration of vaccines. If you can track the vaccine, conceptually
you could lengthen the followup per patient. So that\'s out of scope. It
would seem that this is out of scope as well.

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

Agree.

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

Hearing any other contrary views? Otherwise number 5, not in scope?

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

Okay.

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

We are just whipping along here.

I think isolation and quarantine monitoring and tracking. I don\'t
recall anything in our minimum dataset that would allow us to identify
that a patient was in isolation.

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

Yeah, I don\'t either.

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

And there is no way that ‑‑ quarantine at home would be in any of these
datasets so this looks to me like it doesn\'t match with what we are
collecting.

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

Agreed. It seems like it is out of scope for what our data elements are.

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

Anybody have any other ideas?

Okay, Marty. I think we have got another vote here for another
salmon‑colored line.

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

Okay, not in scope. Terrific. The other one in this integration ‑‑
integration with ‑‑ and disease registries. What do we mean by
integration with ‑‑

Does this mean that we are going to be able to take what comes out of
the data received at a local level? Let\'s say a local jurisdiction
receives this information from the ADT streams and then populate a
disease registry?

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

How would you do that if it\'s anonymized?

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

Right.

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

You could not. So how could it do any of this?

But getting back to Farzad\'s point earlier, it may be that there is
anonymized data or pseudonymized data going to some jurisdictions, but
patient-identified data going to more local jurisdictions because it is
in accordance with public health law.

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

The Indianapolis example.

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

Maybe it is Indianapolis, right.

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

Or was this meant to be more like some of the things that we discussed
at our meeting in August where it was not so much really integration
with the registries as maybe comparing our data with data from
registries to see if they support each other?

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

The last technical standards are more situational awareness.

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

M\'hmm.

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

I guess without more clarity on exactly what we have in mind, I think it
would be awfully hard to say it is anything other than not in scope.

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

Yeah.

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

This is Laura. If we think about ‑‑ I mean a couple of the once that we
said were out of scope, number 1, number 3. If a system was tracking the
actual people who had received vaccination or prophylaxis, you can see
where that would be, it would be nice to be able to integrate that
information back into immunization or disease registries. So think again
that this one is more on a system capability side than a public health
monitoring side. I mean, I\'m comfortable with this one being out of
scope.

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

Okay.

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

This is Marty. My only concern is back to the preconditions consumption
where we, or discussion where we talk a little bit about this
integration with the state and local infrastructure. I think your point
earlier, Art, and that Farzad has also discussed, that it implies a
certain amount of state and local infrastructure that this is meant to
support in some way.

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

I think you have just argued for it to be in longer-term, Marty, but ‑‑

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

I think I did, yes.

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

Actually ‑‑

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

Kind of look at that a little bit differently. Your point, Marty, is
that the, the effort that we are doing should support state and local
infrastructure. Right?

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

Yes.

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

Now, I was actually thinking that the point being made in, let\'s see,
back on the preconditions sheet where that\'s point 12, was that the
state and local infrastructure may support MDS reporting but not that
MDS reporting is supporting those structures.

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

You have, broke up there at the end of your sentence. Can you say your
last sentence again, Art?

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

Okay. I think the point was that, Marty was saying that MDS should
support state and local infrastructure and health information exchange.
And in point 12, on the preconditions, I think what was being said there
is that there may be existing infrastructure that can support MDS
reporting, which is different than what Marty was saying.

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

I hear your distinction.

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

So maybe we need to have a discussion around whether MDS really is
supportive of state and local infrastructures. And data from MDS
reporting, how will that help state and local health information
exchange infrastructures.

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

Well, this is Marty. If we\'re collecting certain, you know, diagnostics
codes coming into the ER that may be an event or a, part of a registry,
that the health department, would we not want to have at least ability
to validate that that had been reported under some other mechanism and
drill down into it? And thinking broader than even acute disease issues.

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

Yes. And I think this gets back to this hazy area between, which I think
Farzad was alluding to around how this local jurisdiction may be using
MDS for lab reporting and/or communicable disease reporting but, beyond
the state level, that\'s not important. That\'s not a function. So I\'m
not sure.

Maybe we should put this as something that needs to be explored. Because
the point of both the presenters earlier today is that whatever we do,
we should make sure that it lines up with the value at the local and
state level as much as possible.

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

Yes.

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

This is Laura. I agree. I guess one of the things that Farzad said that
troubled me a little bit was part of his assumptions was this was a
national system. And I think part of our, what we ‑‑ this group is to
make it valuable at the local and the state level. And so I don\'t want
us to ‑‑ I don\'t think this group has been, but I don\'t want us to be
thinking about this as only a national system. I think that that last
comment of how we make this valuable for all levels is important.

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

This is Marty. Perhaps it is the word integration. And as we are kind of
defining it and I guess I, is what\'s troubling me a little bit in the
sense that, what I\'m hearing is that it has the potential. We are just
not quite sure what that is. And I guess I agree with your suggestion,
Art. We either don\'t color it, or I would suggest we consider coloring
it to a longer-term and then put in our comments that this really needs
to be evaluated.

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

Yeah. With an emphasis on local and state value.

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

Yes.

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

Right. Okay. Any comments to the contrary there?

We are hitting the homestretch. I think we have just one more.

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

Okay. Next section, partner communications and alerting.

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

Marty, can I back up real quick? I think I heard that you all wanted it
long-term but with the comments added to it. Correct?

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

Yes.

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

Okay. Thank you.

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

That\'s the current proposal.

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

This is Perry Smith. I just joined. Just wanted folks to know. And
apologize for not being here earlier.

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

Well, welcome.

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

Thanks for joining us, Perry.

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

Sure.

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

We are on the functional analysis under the, reviewing the last few
items here. Partner communications and alerting, line 29 in the
spreadsheet. Number 1 in partner communications, whether this is
short-term, long-term, or not in scope. It is the rapid distribution of
health alert and communications of a health workers, primary care
physicians, lab workers, et cetera.

Comments from folks?

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

I mean, to me this seems out of scope because this has to do with the
mechanisms of what happens to the data through the system after it\'s
collected. And while I ‑‑ you know, I certainly think it is important, I
guess I don\'t know how the distribution mechanisms relate to the
contents of the minimum dataset.

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

Right. I think I agree with you. That\'s Eileen. Right?

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

Yes.

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

Yes. I think I agree with you. In precondition 11 we say that
information will be shared, but we don\'t really have to get into the
mechanism here. And I think most of this is CDC\'s and, you know,
correct me in I\'m wrong, Laura. But this is basically the CDC\'s
feeling that they have an obligation to disseminate it and they need a
mechanism to do that. And that\'s part of PHIN, but that\'s not
necessarily part of our scope here. So I agree with Eileen.

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

M\'hmm.

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

It is very important we recognize the need to be sharing of data but,
you know, will there be rapid dissemination of health alerts and
communication through something that we are doing? I doubt it. We just
provide content.

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

This is Laura. I don\'t disagree. And this is an area that the ‑‑
broader by the surveillance worker is talking about at, you know at a
national scale between ‑‑ and public health. I think it is fine to be
out of scope here.

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

We have a proposal ‑‑ this is Marty ‑‑ for a not in scope, for number 1.
Any contrary views to that? Hearing none, we will have that at this
point designated not in scope.

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

Wonderful.

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

I don\'t see any others here. Is that it?

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

That is it. We have, every one of these lines now has a color. And just
to review, I think if I got this right. There are now three areas in
these titles, early event detection, outbreak management, and we have
one in the counter measure and response administration that is green. So
we have covered three of the five areas ‑‑ we left out the cross
functional components. We touch on three of these five broad categories.

That\'s good.

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

That\'s terrific.

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

Yeah.

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

Thank you, everyone, for the time and, I think your attention in the
next version that comes out to making sure we have the classifications
correct, but also to the notes that truly reflect the intent of the
functional area relative to the minimum dataset would be great.

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

You know, I think that\'s an important point. We have steered away from
changing from the titles and the wording that was used in the article
that we culled this from to begin with. But I really hope that everybody
feels the power to add to the comments section so that someone who reads
this will understand what we were thinking as we interpreted the wording
from that article in each of these functional areas. So please feel free
to put your comments in there. We will collate those and put them
together for everybody to share.

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

Terrific. We are ready for the next section?

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

Yeah. It\'s now ‑‑ oh, we are only ‑‑

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

Right. Our minimum dataset.

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

Yeah.

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

And, Ed, we will need your help here as we finalize the minimum dataset
and really review and adopt the descriptions. Let\'s see. Which ‑‑
that\'s our other spreadsheet. Is that correct?

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

Did that go out in today\'s e‑mail or are we using one from last week?

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

We got both of them in today\'s e‑mail.

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

The minimum dataset.

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

Yup.

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

Yes, it is the last half. It is the overview.

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

So if you have the spreadsheet with you, you need to, if it is up on
line you have to press the MDS overview. Is that correct, Scott?

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

Correct. It is the last tab there.

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

And if you have printed it out, you want to make sure you have printed
the one that\'s the MDS overview. There is several tabs that were
included in this workbook. Is that your understanding as well, Ed?

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

Did we lose Ed?

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

Sorry, I was on mute.

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

Oh, okay.

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

I don\'t have the spreadsheet in front of me, but that\'s my
recollection.

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

Okay.

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

I don\'t seem to find that ‑‑ what is the title of that spreadsheet?

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

It's called BDSG versus HITSP-TC.

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

Okay. Thank you. I kept looking for the overview document. Thanks. There
it is. Thank you.

So we had some comments earlier today from some, I think it was from
Shaun mostly, about these descriptions. And I take responsibility for
them. I just filled something in so that we had an item listed for each
one. We certainly can change any of these, and need better specificity
as Shaun was pointing out for some of them.

Did anybody see anything that they like to comment on now?

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

There is (inaudible) a lot of places instead of number.

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

Oh, right. That\'s my typing.

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

Perhaps we could walk through these by section?

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

Yeah.

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

And just make sure we\'ve started to capture the, again, the
description. And anything else you think we need to add to these so
others outside will help understand our thinking.

The first section, base facility data elements.

Perhaps just a moment, what are you ‑‑ the question is, what do we think
will be the most ‑‑ what type of information in the description is going
to be most helpful here? Because one of our assumptions is that the
HITSP will help identify the ‑‑ of it so our description will reflect
the intent and description of the committee about what it means. Is that
the general understanding?

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

And this is Ed. I agree with that. And especially because HITSP maps it
through to existing standards. That standards that generally are going
to provide the detail you need to really specify things more precisely.
I don\'t think we have to re‑invent that.

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

So are there particular instructions, Ed ‑‑ this is Marty ‑‑ that would
help HITSP about these in terms of giving guidance?

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

I am at base facility section. The real question is, is there any source
of data of kind of available beds. It is more meaningful than licensed
beds. I\'m not sure that there is, without doing some kind of a polling
method.

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

Okay.

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

But otherwise I do agree with both Shaun and Farzad, that that can just
be a lookup table and use the facility identifier.

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

Can we put that perhaps ‑‑ this is Marty, in one of the comments and
understanding, Scott? Can you capture that so we make that notation?
That is, understanding this type of information could be somewhat
static? It should be able to be derived from the tables.

Should we move on then to the next section?

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

Yes.

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

Daily facility summary reports. Quite a few items in here. A comments,
on the comments section. Let\'s focus on 6 through 12.

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

And again, because this is going to be mapped through to the HAvBED
standard which defines with a certain agreed precision all of these data
elements I\'m not sure we have to get too tied up in them. I certainly
do agree that all this information is readily available in ADT systems
and have to look at other systems to acquire it but being table to
identify in terms what we want to get in terms of the information and
define how we would like to get it standardized, that can be done.

I would put down some items in italics where, for instance admissions in
last 24 hours, Ed, were you thinking that this would be something
derived from just counting up ADT, admissions for 24‑hour period, or
that this would be something aggregated at the institution?

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

I don\'t know if Lynn is still on the call. Maybe she can answer that
better than I can. Or Laura.

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

I\'m sorry, this is Laura but I got ‑‑ ask me again?

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

So the question is, do we know ‑‑ we are asking you because Lynn is not
on the call now.

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

Okay.

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

For instance, on line 6, admissions in last 24 hours, whether it\'s
anticipated that this number would be derived from adding up all the
admissions from a facility in a 24‑hour period or this would be an
aggregated number entered by the facility every 24 hours?

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

Based on the ‑‑ principal of using available electronic data and not
having anybody enter or re‑enter data, my initial reaction would be this
would be a system capability where it adds up the number of admissions.
But I can certainly have them confirm that, you know, based on what they
are seeing in the hospitals, that it is not an actual entry into a
system but in the totaling up of the admissions by the system itself.

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

Okay. So the same would go for discharges and deaths?

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

Yes.

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

Okay.

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

I do not think in BioSense we have anybody enter any data just for the
Biosense system.

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

And it sounded like Regenstrief does nothing of that nature, and I
didn\'t hear Farzad say anything about entering data. So ‑‑

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

Right.

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

I mean everybody is looking for what\'s feasible. So we should presume
that there is no need for facility to calculate, aggregate a number and
then report that number.

Okay.

So I think those, those three would be derived from individual message,
ADT messages.

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

Right. But I don\'t think we need to specify whether that\'s done at the
facility side or at the surveillance systems side.

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

No, well, now it would have to be at the level of the surveillance
system because we are saying there is no need for the institution even
to do it. Or am I misunderstanding?

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

I\'m just saying that I don\'t think we need to worry about it one way
or another.

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

Okay.

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

Hearing no other comments ‑‑ this is Marty ‑‑ unless, I think as Ed
mentioned, much of these have related specifications, unless there is
some clarification, given the time I would like to move on to the other
sections. And we can always, you know, as you review these comments,
send those in to Art, myself or Scott as well.\
\
How about on the patient data elements, if we move to that. Any special
clarification? We heard a little bit about date of birth and age, for
example, in the earlier presentations. Any other comments, changes to
the minimum data set related to the patient data elements?

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

So ‑‑ I think both of the presenters earlier today spoke to the issue of
age and date of birth, I believe. Should this be something that this
group considers, given the concern about HIPAA.

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

I mean in a local jurisdiction it may not be an issue because it is a
reportable, but at a national level should we be sharing ‑‑

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

HIPAA limits were not put in place for public health though.

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

Yes, but we are just drudging data here though. Some of this is ‑‑ are
we not trying to mine data here rather than have a reportable
conditions?

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

Yes, as long as this is not a reportable condition, I would ask what the
real advantage of having the date of birth is over having the age.
Because I would think we could do what we want to with the age.

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

But ‑‑

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

Not arguing that. One or the other. But, you know, knowing the age is,
would be important. And generally systems capture date of birth. They
don\'t consistently capture age. So that we may have to either have
systems calculate age in order to be sent if they don\'t capture it on
their side. There may be an extra step.

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

Okay. So the thinking is this is either/or, depending on what is easier
for the sending system?

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

Well, I think originally we said month and year and if that was not
available, then age. But I think you can ‑‑ that\'s a different proposal
that we can consider.

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

So we are saying it is one or the other.

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

I agree with that.

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

Okay.

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

So in this case, where we are at here, we are having the comments
reflect that, Art, is that what you are thinking?

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

I think so. Right. That\'s what I\'m putting in my comments.

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

Okay. Other comments on the patient data elements? Otherwise I would
like to move on to clinical data elements.

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

Well, I would also like to echo what Shaun said earlier about the
pseudonymized data linker which is I think that we are going to find
that this is not a data element that\'s available at most systems and
that that\'s going to, you know, pose a problem getting that for most
data originators.

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

I mean I understand the need for it so I\'m not necessarily arguing it
be removed, but it is just something I think we have to remember.

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

Do we need to reflect that in the comments?

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

Do we also need to add an element for the unit of the age? I\'m not sure
we had that before. I guess I could look, sorry.

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

No, I don\'t think we had units. I think we were assuming if it was age,
it would be in years.

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

But that wouldn\'t necessarily be helpful for infants.

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

And right exactly, and I\'m often leery when I see a zero if that\'s a
child less than one or I\'m missing data value.

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

Right.

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

So number and unit, I think, was the suggestion from Farzad. It should
be reflected in the comments.

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

M\'hmm.

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

Other comments on the data elements for patients?

I think the only other piece I heard from opening was ZIP code from
three versus five depending on the, again, the privacy and
identification issues. So perhaps the comment should reflect the usage
and related to that value.

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

Right.

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

This is Laura. I will just share on the ad hoc group that we had that
talked about this, they actually ‑‑ several times arguing for the nine
digits that code and came back to the recommendation that it just ‑‑
minimum of five would be necessary.

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

Five is pretty specific.

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

Right. And I think they initially recognized that it is not likely
captured but ‑‑

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

Right.

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

I\'m thinking through the scenarios they were thinking it might be
useful.

Just the other opinion that\'s on the table.

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

Well, I think at this point a lot of places you capture nine, but it
doesn\'t, it goes back to the HIPAA question. If there are questions
about five, nine obviously amplifies that because it really is not quite
person-identifiable but pretty close.

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

So why don\'t we leave it at minimum of three, except where privacy and
identification issues may require limiting it to ‑‑ did I say three? I
meant five.

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

Right.

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

And then limit it to three in those other areas.

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

I think that sounds right.

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

Sounds good.

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

Okay.

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

Moving to the next section, clinical data elements. Comments on this
section?

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

I think what you heard is that this systems aren\'t really out there to
make it feasible to collect nurse\'s notes and vital signs and pulse ‑‑
at this point, but I think we can still leave them in there as being
desirable but recognizing the systems may not yet exist to collect this
electronically.

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

I was surprised at Shaun\'s comment that diagnosis is not always
available consistently because I thought that was something that keyed
off the billing process, but maybe I misunderstood. ‑‑ I agree with what
you said, Ed is leaving these things in, and trying to get them.

And I think that North Carolina has used quite frequently the nursing
and free triage notes to help in some of their investigations. I think
they have found that to be useful although recognizing it is not always
there.

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

I think, I think it was Laura that was just making comment about
diagnosis being required for billing purposes. And I think the network
for patient care in Indiana was a series of hospitals. And the billing
at the end of the hospitalization will have all the diagnosis codes
correct, and I think that this diagnosis type, this interim diagnosis
may be used a lot in an ED or at the point of admission. But it doesn\'t
have to be used. I think that\'s part of the problem. You are right,
Laura, it will be correct for billing, but that may not happen until
after 24 hours.

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

Or longer.

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

Or longer.

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

Yeah.

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

Yeah.

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

For sure longer. But I think we are looking for a 24‑hour capture.

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

Sure.

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

Art, this is Marty. And I\'m just looking at the clock here. We are
pushing up to, towards the, few minutes left on our agenda. Could we ask
for folks to add, send you comments or send us comments?

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

Sure.

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

On the descriptions? As people look through this, any additional
clarification, taking into consideration the comments we heard also from
Shaun and Farzad.

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

Yes. Thank you, Marty. I had not been looking at the clock. Thank you.

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

And so if we could, we could do that and we will have another, I think
feedback from the group here, the committee on the descriptions. I think
that we are getting closer each time through, but I want to make sure
we, perhaps next call for few minutes to cover the lab section as well.
But it looks fairly straightforward. So if we could do that then, I
think we need to really prioritize what\'s left on our next steps. We
have ‑‑ Scott needs to, if you could help us with what do we absolutely
have to cover, and then we have some time for public comments.

This has been a very good discussion from everyone. Thank you.

Scott, are you there?

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

I\'m here. Can you hear me?

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

Yes.

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

Good. Well, the timelines are really what I wanted the group to be aware
of, and so far these are just with the preliminary in mind for the
Biosurveillance Workgroup of what you present on the 21st, the final
report being on the 17th. And if you look at your calendars, I have
started graphing out some timelines through September that we would be
coming up with. So for example, on September 12th I would like to have
some draft recommendations for the group to be looking at and everything
else to be working towards our goal in October.

Also you see here the 21st is highlighted, where that report is going to
the Biosurveillance group. And tap receiving feedback from them and
hopefully incorporating that into final, which is on October 31st.

We have a meeting scheduled for the 14th. One that\'s scheduled for the
3rd. The Biosurveillance is scheduled on the 21st. And October 17th with
the full recommendation going out to the Community on October 31st.

You will also notice on September 8th I have in parenthesis written
testimony, hoping we will be receiving some of that throughout the week
this week.

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

Scott, this is Paula.

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

Yes.

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

Just a quick question. There is such quick turn around time, and some of
the people who requested to give testimony were not able to speak today.
And I\'m wondering, you know, given that we kind of made up time because
we had only a couple of people present or speak today, I\'m wondering if
there is any time in our next call on the 14th to hear a couple of more
people?

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

This is Kelly. Would I think, you know, Marty and Art, it is probably
most important for you to have in mind how you want to lead this
discussion on the feasibility assessment and whether or not written
testimony that\'s carefully reviewed, you know, perhaps what
coordinators in advance of a meeting, or to be at least four days for
review that that might suffice. But it just depends. Do you not think it
needs a good chunk of time to discuss the feasibility assessment then
maybe you could choose to allow for some of that time to go to people
who actually present what\'s on their minds as opposed to just having it
in writing.

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

We have scheduled two-hour sessions, Scott. Is that right?

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

I believe it is a three‑hour session on the 14th.

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

Well, you know, I thought the presentations today were helpful. And if
there are a few more that would help us, even get a little more focused
on our feasibility as an intro to that, you know, our next discussion
will be primarily about feasibility. I would be open if there are some,
I think that was Paula that was saying there might be some locals who
would be able to testify?

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

Right.

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

And you know, we would just take a half hour ‑‑ it seemed like we took
just about a half-hour today out of our two‑hour session so I would be
open to that out of a three‑hour session.

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

And I think there were some besides locals that didn\'t have an
opportunity to speak. They may be ‑‑ to submit written testimony. But ‑‑

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

This is Laura. I know Lynn Steele was out of the country last week and
just saw the note this morning.

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

Yes.

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

So I imagine she would be interested in throwing something together to
formally testify as well.

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

Okay.

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

Speaking on her behalf, but she could certainly submit in writing if the
group thinks that\'s what needs to happen.

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

You want to be mindful of how much you want to read ahead of time that
you can think about as opposed to having a lot of information come at
you today at a meeting. It might be something you want to try to
balance.

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

So, Kelly, are you saying that we could ask them to provide it in
written format a few days before?

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

That\'s what we already have asked to do. We expect to get several
written testimonies by Friday.

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

Okay. So then we would have time to digest that and then that would be
able to include that in our discussions?

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

Right. Right, but ‑‑ there is also value in hearing that you can also do
that. It is your call. It is ‑‑ I guess you would want to make a
decision on how much time you think you need for discussion.

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

Well, it might allow some people to ask some questions though, too.

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

Yes.

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

All right.

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

This is Marty. I guess I would agree that if we can reserve at least at
this time a half an hour for a couple of presentations, then as ‑‑ on
the 14th, allowing us to look at the written testimony following the
8th, that would be helpful.

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

Okay. I agree, Marty.

> That\'s ‑‑ we will have those by the end of the week, or early on
> Monday. Is that ‑‑ we are expecting them ‑‑

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

I ‑‑ we will probably get them by close of business on Friday. But you
know, if we end up asking to, a few in person, then we probably might
have PowerPoints or something, depending on what they are going to
present. But, yes, we can share whatever we get on Friday with you all
immediately.

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

Very good. So were there other, next steps for us to discuss? I know we
are past our time here.

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

Yes. There were just a few of the parking lot items that we have noted
on the agenda. Pathogens list raw versus calculated data types and
potential survey for the upcoming ‑‑ surveillance conference. I don\'t
think we need to visit all those right now in lieu of the public
comments period occurring in the meeting unless you all want to discuss
more.

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

I think we can go on to the next public comments section. How about you,
Marty?

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

Yes, that sounds very good.

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

Okay. Matt?

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

Yes. Well, we have had the information up for public call in on the
Webcast now for a couple of minutes so we probably only need to give it
another 30 or 40 seconds. We have not had any one call in yet. If there
is somebody dialed into the meeting earlier and would like to make a
comment and is already on the phone, just press star 1 and you will be
put through. But otherwise we will give another 45 seconds for people to
call in, and I will let the co‑chairs know if nobody has done so.

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

While we are waiting, I think the parking lot item about raw versus
calculated data types, you know, with Ed\'s comments earlier today, I
think everything will be raw. And the way that our MDS overview sheet
now has it as summary values, those are calculated from raw data. So I
don\'t even know that we will have to come back to this later, at a
later point. I think that Ed was pretty clear, we are not expecting
anybody to be doing any extra work.

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

It doesn\'t look like we are going to have any public comments today.

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

Okay.

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

Terrific. Well, thank you everyone again for a terrific meeting. A
special thanks to our distinguished guests for presenting today.
Dr. Mostashari and Dr. Grannis. Really appreciate it. And thanks again
to all the group members. This is a tight timeframe. We know people are
really busy in September, and we really, really appreciate as the pieces
come out your comments, but I think it is really moving along as well.
So thank you again, and we will be talking on the 14th. Art?

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

Yes. Thank you, Marty, for facilitating today for most of the session
and keeping us on schedule. I\'m glad that we are not that far beyond
the appointed hour. Once again thanks to everybody else on the call, and
look forward to speaking to you next week.

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

Okay. Thank you, everybody.

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

Okay, thanks. Bye.

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

Bye‑bye.