American Health Information Community

Biosurveillance Data Steering Group #7

October 3, 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.*

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

Okay, I\'ll begin with a quick roll call for today\'s Biosurveillance
Data Steering Group meeting. On the phone today we have Ed Barthell,
from the American College of Emergency Physicians. Eileen Koski from
Quest Diagnostics, our Co-chair Marty LaVenture from the Minnesota
Department of Public Health, Richard Milton from the State of Utah, Mark
Rothstein from the University of Louisville, and Laura Conn from ONC. I
also understand there are also a few people in the room at ONC?

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

Yes, we have Angela Fix from ASTHO. Paula Soper, which I think just
disconnected. Judy Sparrow from AHIC, we have Kelly Cronin, and Dr. Rob
Kolodner.

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

Anybody who we missed who is on the call with us right now?

In that case, very, just very quickly, Workgroup members please keep
your phone muted when you\'re not speaking, and when you make a comment,
introduce yourself first so members of the public following along know
who is speaking. If you\'re logged into the Webcast as well, please
don\'t change any of the slides as we\'re going along.

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

This is Kelly Cronin. I just wanted to take an opportunity and introduce
Dr. Rob Kolodner, who is our interim National Coordinator for Health IT.
We\'re in ONC thrilled to have him as our new leader. And he brings, I
think everyone knows, with him some deep experience in running the
information systems at the Veterans Health Administration, and has a
long history in the field of informatics. So we\'re really thrilled to
have him here, and he\'s actually taking some time to say hello all the
Workgroups, so I\'ll just turn it over to him now.

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

Thank you, Kelly. Good afternoon, or good morning, depending on which
time zone you\'re in. I\'m delighted to be able to be with you for a few
minutes right now. And Kelly has been telling me about your Workgroup,
and I think with the number of meetings you\'ve had, and the amount of
work that you\'ve accomplished in this short period of time, you are
either one of if not the hardest working groups at the present time. And
I commend all of you. I know that does take a lot of time out of an
otherwise overfull schedule that you probably all have, and do
appreciate the commitment that you\'ve made and the contributions that
you\'ve made.

If you haven\'t had a chance to hear Dr. \-- Secretary Leavitt speak,
particularly when he\'s addressing the Community groups on an almost
monthly basis, what you haven\'t heard is the way he thinks, which is to
make sure that you have that long-range vision. In terms of where we\'re
going, and what needs to be done to do the kind of job we all want to
do.

He also emphasizes the need to take that first step, and to get some
very short-term deliverables so that we can make that first step
progress.

And I know that he\'s looking forward to hearing from the group the
recommendations that you\'ll be making for that October 31 meeting,
which is the next meeting of the Community. So that we can begin making
some steps in understanding just how to meet the needs of the broad
biosurveillance and public health needs as we move forward in the
interoperable health records and the national health information network
that we\'re all trying to put in place. So I understand that you\'ve got
a lot on your agenda and a number of you have even more work that you
want to do, and I think that\'s terrific and really do appreciate all
that you are doing, have been doing, and plan to do. And I just want to
make sure that it\'s clear that the Secretary would like to take that
first step and is looking forward to your deliverable for the 31st, so
that we can begin to do so.

With that, if there are any questions I\'d be glad \-- from the
Workgroup members, glad to take those. Otherwise I\'ll get out of the
way and let you get on with your schedule.

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

This is Marty LaVenture. Dr. Kolodner, thank you very much for those
comments, and we really appreciate your commitment and leadership to
this important effort. As you know, our committee has not only worked
hard but have great support from Kelly and the staff there, Laura Conn
in particular, and others that have been great to work with. So we
appreciate that, and your leadership and commitment to this very
important area. So we\'re working hard to try to do our part in all of
it.

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

Great. I do appreciate it, and I\'d like to say that I\'ve been getting
some really great reports on how you\'ve been doing, so I do appreciate
it very, very much.

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

Well, with that I think we should move on to the second work here for
the approval of the summaries for the 18th and the 5th. Does anybody
have any comments or edits to both of those summaries? I did not receive
any via e-mail by the way.

Okay. I guess we can take silence as okay on each one of those.

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

This is Marty. Do we have a motion to accept those comments and notes,
please?

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

So move.

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

Second?

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

Second it.

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

All in favor?

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

Aye.

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

Okay, opposed?

\[silence\]

Okay, minutes accepted. Scott, any other updates or introductions at
this point, or can we move into our main meeting objective?

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

Let\'s move into the main course.

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

Has Art joined us yet?

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

Yes, I just joined, I\'m sorry I\'m late. I\'m in a mandatory ICS course
today and tomorrow, so I\'m sorry I got here late.

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

No problem, Art, we\'re just getting started. Thank you, this is Marty.

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

Hi.

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

And the main focus of the meeting today is really to try to finalize the
minimum dataset classification for feasibility and filtering. We had
made a good start the last time through, I think of the third section,
and we\'ve moving into the fourth, I believe. And we had planned on
walking through those to get opinions and comments that we can add to
the notes sections as appropriate for \-- related to feasibility and
filtering, and then come back and make sure that the notes that we have
are generally reflective. So sort of two passes through the minimum
dataset is what we\'re looking at trying to do today. And then there\'s
a few \-- as every meeting, has happened at every meeting we have some
preconditions that we update, and based on comments, suggestions and
information we\'ve learned, and we\'ll go over those, as well. And then
an update and the next step. So that\'s the main agenda for today.

Questions or comments on what we want to try to do today?

All right, hearing none, let\'s move into it. My notes had Scott and Art
through section 3, and we were starting on clinical data elements 4, or
did I miss something? In terms of the feasibility and filtering. That\'s
where the yeses seem to have left off. Although we had some on the
microbiology as well.

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

Marty, also if you look at element 2.4, we do not have anything in the
feasibility as a "yes" or a "no."

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

Okay, we had a lot of the filterings "no" on, however.

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

It\'s 2.4 to 2.15, it looks like.

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

Okay. Well, let\'s take a look at the section 2, then, if we could as a
committee, and 2.4 through 2.15. And if I recall from the last phone
call, we were looking at trying to identify the feasibility issues.

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

Could we get a clarification, Scott? What does the asterisk mean for 2.1
through 2.3 on the "Y" for feasible?

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

I think that was the part where the manual \-- may require additional
fields to \-- you know, manual input, a Web form. For the \-- the first
couple of bullets under feasibility under the total category.

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

That applies basically to most of the ones that follow that as well,
where they say have, that\'s got to be some \-- there\'s no current
system that would collect this at this point, there\'s only some
proposed standard. There\'s no system yet that we collect these.

Correct me if I\'m wrong, is Ed on the line, or \-- Ed is not on the
line?

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

No, I\'m on the line, I just had my mute on.

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

Okay, because I think all these are \-- what does feasible mean? Does
that mean that it\'s captured automatically, or that it\'s captured by
some Web form?

Maybe we need to define what feasible is, here, and what this asterisk
means. I think it means that there will need to be a separate mechanism
to enter those onto a form. Because there is no system currently that
would allow us to do 2.4 through 2.14, at least. Is that \-- or maybe
even all the way through to the end.

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

The systems exist, they\'re not necessarily used on an everyday basis.

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

The system in the \--

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

And they do require some data entry, typically.

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

Right.

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

So I think the "yes-asterisk," with the asterisk meaning they may
require some data entry in the Web forms, is what the asterisk should be
about.

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

Yeah, so if we go to the top of this, where it says feasibility, for
this daily facilities summary report elements, the feasibility, the
third bullet underneath there, may require significant data entry, in a
Web form. That probably applies to most of the elements in this table.

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

Correct. Yes, up through the patient element data elements, correct.

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

So while we may say feasible "yes-slash-no," maybe we should classify
what we mean by feasible. It\'s feasible with a Web form, is that what
the asterisk means, Scott?

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

I apologize, Dr. Davidson, I missed that.

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

I was just asking if the feasibility as categorized now as "yes" or
"no," and we have "yes-asterisk." So should we clarify, and call out
that the asterisk means will require additional data entry, it cannot be
done automatically?

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

Yes, I would think that would need to be put there.

I\'m looking over the preconditions document, just to make sure that we
have something in here about manual entry, also.

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

In 2.1 to 2.3 they have asterisks that I actually think those to be
generated could be generated by the information systems without
additional data entry, at least those first three.

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

Laura, I think I agree with you, I think the ADT will say that a patient
died. I have not looked at those specifically, but I know it certainly
does the first two. So I think that would be something that we would
want to check out, the third one. But the rest of them are certainly all
asterisk-wise, if we\'re defining that as requires additional data
entry.

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

I believe you\'re right.

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

Okay, so we can carry that \--

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

I\'m not really sure. The bullets under feasibility, at the top, are
those just caveats on how they\'re feasible, \"but\"? These things?

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

Yes.

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

Okay.

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

Right, and I think that what we should do is maybe for the third one
there, say that would be a "yes-asterisk" in the table below. Somehow
indicate.

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

Right.

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

And then we can go ahead and use our "yes-slash-no" and "yes" with an
asterisk.

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

Right.

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

Is there agreement about that?

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

Yeah. I don\'t know, if you can even just say "yes," it\'s feasible. I
was at a meeting last week where people put up the system that showed
how they were collecting all the HAvBED data elements on a routine basis
in Oklahoma.

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

Are they doing that automatically?

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

It\'s through a Web form.

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

Right, but that\'s \-- see, I think the question here is who is going to
be doing that. And we need to inform the AHIC, or the BSV that this will
require additional data entry. We need to (Inaudible) points that came
from Dr. Herbseck (ph) is we need to let someone know it\'s going to
cost 50 to \$150,000 to create some of the interfaces from systems, and
we need to let them know that this will require additional data entry.

I\'m not disagreeing with you all, Ed, I think we \--

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

Right, just puts in the initial charges that it was about getting
electronically available data. So we just need the caveat that this is
not yet electronically available data and will require manual data entry
for now at least.

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

Yeah, I think we need to keep in mind our assumption number three, too,
because we do say we\'re going to be focusing on readily available
electronic data.

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

Right. If it\'s readily available from an electronic data system from a
State, and we can then collect it for our national systems, I guess I
don\'t understand the difference.

If you\'re entering the data into an ADT registration system or you\'re
entering the data into a Web-based form system, somebody is entering
data at some point.

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

Are you doing it just for this reporting or are you doing it for care,
clinical care within the organization, I think is the distinction.

They\'re going to register the patient, obviously that takes data entry
as they come into the hospital, but that\'s for use in the hospital
system use already. Is there such data that can give us this utilization
data existing in hospital systems, and I think there\'s not right now.

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

It does exist electronically in systems, and that\'s \--

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

Without any additional work?

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

Well, without any additional work from what they\'re doing now. That\'s
simple.

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

So you think that \--

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

Okay, so then maybe we\'re not on the same \--

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

Oklahoma is doing this now.

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

How are \-- are they doing it out of the ADT system?

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

No, the ADT system doesn\'t capture this stuff.

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

I think that\'s the point, is to just clarify it\'s not from the ADT
system, it requires a separate interface for \-- or a separate system in
which someone would enter the data. It could be collected
electronically, I think we agree with you on that. It\'s just that these
all require someone to input the data.

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

I think that\'s \-- well, every one of these things has that as the
first thing on the notes. At least on the \--

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

Right, and I think all we\'re doing is just clarifying that the
feasibility pertains to a separate system than normal ADT
interactions \-- transactions that occur within an institution.

And it is true, it\'s all in the notes, that\'s correct. We\'re just
clarifying that.

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

I think in a way it goes back to Art\'s earlier comments that maybe we
ought to define what we mean exactly by feasible, given the Workgroup\'s
charge. I mean, do we mean feasible to turn it on today, and on what
level, or do we mean, you know, feasible within what period of time.

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

I quickly put a footnote on the first page of the minimum dataset. And
the first one pertains to feasibility, and the second one pertains to
filtering.

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

Where did you put that, Scott?

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

It\'s on the first page, it\'s underneath the base facility data
elements, it\'s the footnote. But the feasibility is the determination
as to whether the identified data elements could be collected or
captured by using available resources.

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

Okay, but I think Ed\'s point is that there is an available resource
that would collect this, if we use the Web form. And I think we\'re just
trying to clarify that that is not the run-of-the-mill ADT output from a
system. And that\'s not clear on those two footnotes. Or the one that
pertains to feasibility.

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

Getting back to feasible, are we just going to say that feasible is just
something that we can do this year, potentially?

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

What is the group saying? Is that something that we need to include in
the definition for feasibility? Was that the expectation of the
committee that gave us our charge?

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

Anything is feasible with enough time and money.

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

Exactly.

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

But do we \-- is it part of our charge to explain that there are
expected costs

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

This is Laura. I think the specific charge of the group that then gave
you the charge did say within one year. We could do this. So I think
it\'s appropriate for us to be gauging feasibility in this regard in the
one-year timeframe.

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

Yeah, although \-- this is Kelly \-- I think, you know, for those
that \-- I mean, we may want to be thinking about for data elements that
are particularly important, that could be feasible within, you know, one
to three years with appropriate resources, we could probably be
commenting on those, and highlighting them if necessary. And explaining
sort of the need or utility of including them that might help justify
getting the additional resources.

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

Can I suggest some language in the notes that might help take care of
this? Because I think clearly these things are feasible, to put a
"yes" \-- in notes, I\'d like to suggest may require some data entry
into Web-based forms, and then the second bullet say for passive
extraction of this data from an ADT system may require some automation
or separate programming on the part of the sending facility.

The four hospitals I talked to this week, none of them had an ability to
give these reports right out of the box, out of their ADT system.

And then in the situational filter, just say situational filtering may
improve compliance with Web-based data entry, something like that.

Those notes could be applied to all of these resource things, pretty
much across the board.

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

Okay, so I think that \-- we tried to capture that a little bit in the
filtering comment that\'s at the top of this page, but I think you\'re
now saying let\'s \-- that it would improve compliance, is probably a
worthwhile saying at this point.

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

What I\'m just trying to be more explicit about what I think we\'re all
understanding.

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

Ed, this is Marty. Could you express the feasibility one more time?

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

Well, this is the notes. Now, I don\'t know if I\'m looking at the same
form as you. This is the one that\'s got sent out, the form \--

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

Yeah, top of number 2, under feasibility?

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

I\'m just saying that notes would \-- the notes for all of these
resource data notes would be \-- may require some data entry into
Web-based forms, would be number one. Number two note would be passive
extraction of this data from registration system, may require some
additional programming on the part of the facility.

The third bullet would be situational filtering may improve compliance
with Web-based data entry.

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

Ed, I think you\'re looking at a different version. Now.

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

Ed, is your document dated 10-3-2006?

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

This is the one that Scott sent out to study these things for our next
call. From (indiscernible) last week. If there\'s a more recent one
I\'ll pull it up right now.

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

Yeah, it\'s from this morning\'s e-mail.

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

I don\'t have it yet, I\'ll get it in a minute.

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

This is Perry Smith. I just want to let you know that I just got on,
sorry I\'m late. And it sounds like we\'re on the agenda the minimum
dataset and talking about feasibility?

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

Yes, Perry, and item, section number 2 on the daily facility summary
report element. This is Marty. And we\'re working on sort of a
definition for feasibility, here, having some time component is what
I\'ve heard, within the first year. What\'s feasible in the first year.
And a caveat that\'s being suggested to marking feasibility of "yes,"
with a couple of caveats related to its capture using either Web forms
or \-- with some particular programming that might be necessary.

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

If I could interject, and we can table this for a later discussion if
this is off the mark, I\'ve talked with a few people here that I work
with in terms of feasibility, and the (indiscernible) of the \--
question of the definition has also been raised and even if something is
technically feasible, or feasible with minimal data entry, the question
I\'m hearing is are we talking about something that industry will find
feasible to do? Even if something is already electronically available,
it may not be in the format or it may not be in a unified file, and so
there\'s the question about whether this is feasible and acceptable to
industry. And so it\'s kind of a reality check, and I can\'t answer
that, I\'m not close enough to know whether medical systems and
laboratory systems would find what we\'re talking about to be feasible,
even if they had all the data.

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

Yeah, this is Eileen, if I could make a comment on that.

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

Good, yeah.

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

These are issues that come up also very, very extensively in the ANSI
HITSP comments as we\'ve been reviewing the formal comments that have
come in on that. And it is a major issue. And not the least of which,
and this is just a logistical thing, is that these standards have not
yet been really released to the public in terms of asking people when
they could be ready to comply, and we\'ve reached a point in the year
where most companies have sort of set their budgets for the coming
fiscal year.

And if there\'s a very, very large initiative that\'s not in that
budget \-- and this would not be for anybody at this point \-- that may
pose a simple logistical challenge, trying to get it enacted within a
year.

And then stepping back \-- that\'s just kind of a general logistical
comment to consider, in terms of our timing and the fact that you need
lead time for people to take on large projects.

But then to step back to some of the feasibility of doing some of this,
a lot of the filtering, in particular, and the translation of data into
coding, for most people that I\'m \-- that I\'ve spoken to \-- and I\'ve
spoken to quite a few different organizations about this \-- that would
pose a big problem. Because it\'s not at all part of their current
process today. They may have data that is electronically enabled and
capable of being transmitted, but if they have to put it in a completely
different form in terms of the content, that would be a real hardship
for most people.

So for example, taking data that\'s currently transmitted as free text,
and transforming it into SNOMED coding, as an example.

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

And then the question comes up as to if it were required, perhaps it
would be a priority, and it would be feasible. But if it\'s not a
required, if it\'s totally volunteer in the next year, is this pie in
the sky, also.

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

Well, given where it hits in the budget cycle, if it\'s not required, my
hunch will be for many organizations it will be pie in the sky. Just
because, you know, by the time they\'re able to consider it they\'ll
have locked down most of what they\'re doing.

Even if it\'s required, though, most organizations can\'t turn around
the next day and address a requirement. They need lead time in order to
do that.

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

So I guess that would be \-- so you\'re kind of confirming my concerns
and my colleagues\' concerns about whether this committee should be
commenting on this aspect of feasibility, it\'s not just a technical
question.

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

That\'s right. And I sound \-- to be frank, that the ANSI, HITSP has
taken a somewhat disingenuous approach of saying that they\'re
specifying standards with an eye towards the future \-- which I think is
all appropriate and the right thing to do, so I\'m not arguing with
that, with the approach or the desire, or the impetus behind it. But I
do think it\'s a little bit disingenuous not to realize that there will
be a practical implication, and you\'re going to need to figure out what
the timeframe is for people to comply in the real world.

I mean, if you think about how many years, I\'m trying to remember, we
had like two years lead time for HIPAA, from when the regulation was
passed till \-- mostly large regulatory initiatives, people are given
some nontrivial amount of time in which to comply. I mean, it doesn\'t
necessarily help them figure out where the money is coming from, but at
least it gives them time to figure out how to incorporate it into their
budget and their schedules.

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

I think what I\'m hearing, I think this has been a good discussion, I
think we need to go back \-- I\'ve been jotting down some notes here
about we need to go back maybe to the preconditions document, and
describe what we mean by feasibility, and point to some of these things
that Perry and Eileen have just added to the discussion, here.

I think Ed is right, it is feasible, but we need our \-- we need to
clarify what we intend to describe in these columns as we check "yes" or
"no," or "yes-asterisk," and that needs to be clarified somewhere in our
documents.

So I don\'t know whether \--

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

This is Ed, again. I\'ve got the current, today\'s version up, I see now
how you\'ve got this formatted.

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

So maybe what I could do is just take that as yet again another
precondition, that we describe feasibility in a little more detail,
here, so someone interpreting this document would be able to see we\'re
talking about a short-term, that something that\'s reasonable for
industry, that allows them to have enough lead time, the things that
Eileen just went through, and kind of put that into our preconditions
document. Unless there\'s some objection to that.

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

This is Marty. Art, I think that makes a lot of sense, to help clarify
the definition. I guess a nuance in that perhaps is that I think it\'s
real important that we reflect the comments about, you know, the
practical implications that Eileen was mentioning, and Perry\'s
comments.

In the definition. I see it in part that it\'s feasible, but there\'s a
variation. That in fact there will not be universal adoption because of
these kinds of factors, that there are practical implications to comply
in the real world. That people have to incorporate in the budget
process, some will be faster than others, others will be slower because
of the \-- for a variety of reasons in the process. And that \-- sort of
recognizing that there\'s a spectrum.

So I think, I guess I would agree with you, it\'s perhaps just how we
sort of reflect that, that it is a "yes," but it has some variation in
how it\'s applied. And here\'s the types of feasibility variations that
are likely to influence how fast it is adopted.

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

Right. I think I agree with that. And as Ed says, there are examples out
there now, and may be something that \-- you know, the recommendations
might be to see if we can pilot test some of those recommendations.

I think one point that was brought up by Eileen, and I think I heard
this earlier from Alanco (ph) last week, is that the have specifications
still are out for ballot, so we haven\'t really got a standard yet for
this, that\'s one issue. I don\'t know if that\'s our concern, because
all we have to do is say what the data elements are.

The second thing is that there is, as Ed points out, a method to collect
the data, and we would recommend that that be tested. To see how
reasonable this is, and also, to understand what the adoption rate is
based on ULS (ph) comment, how it would be applied.

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

I agree with that, Art, I think it\'s a good idea.

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

This is Perry again. Let me push a little harder on something that\'s
also still bothering me, and that is let me go back to the initial
charge, specific charge to the Workgroup, it talks about making
recommendations, so that within one year, ambulatory care and all the
different settings can submit data from electronically-enabled health
care delivery systems, transmitted in standardized format, within 24
hours.

When I read that, when I started, you know, with this group, I was
thinking that they were looking for us to say we really assess what is
realistically \-- what is realistic to expect most providers to be able
to do within one year. And this is really feasible. And it sounds to me
like we are \-- from what I\'m hearing today, and as I say from my
colleagues, that this is probably unrealistic for most of industry. Most
businesses are not going to be able to do this within a year.

So my \-- what I\'m wondering is if we came up with a minimum dataset of
only five elements, would we have the same answer? We still
couldn\'t \-- industry still couldn\'t do this within 1 year? Or could
we come up with a minimum dataset that is feasible within 1 year, and is
that what we were really charged to do?

And I guess my suspicion is that there probably is a minimum dataset, a
lot smaller than the one we\'ve come up with, that would be able to be
implemented by the majority of businesses within a year. But I may be
wrong about that, I\'m interested in Eileen\'s comments on that.

And that that was our original charge, that \-- so I guess I need some
clarification on whether others on the group, in the group, felt that we
were being asked to really be realistic about what\'s possible in one
year, or not. Because I think the credibility of our recommendations \--
I certainly don\'t want our report to be kind of laughed at by industry
saying well, look, these guys didn\'t have a clue as to what was
realistic, and they just rubber-stamped what others, who were
uninformed, also said.

So that\'s kind of where I\'m coming from, and I\'d be interested in
Eileen\'s comments. Is this just something that most industry can\'t do
in a year, no matter how minimum we make it?

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

Actually, Perry, I would agree with you wholeheartedly, I think there
are two distinctions to be made. One is the what, which is to say what
are the data elements. And two is the form.

And I think in many cases that\'s \-- and I can\'t really speak for the
hospitals, because for example, whether or not some of the data that we
want that comes under the HAvBED specification is available in the
electronic form \-- if it\'s not there, it\'s not there. But for say all
the laboratory data, I can tell you the data is all there, in a lot of
the large laboratories at least, it is in electronic form, but it is
certainly not in the form that it\'s being requested in. Nor is a
filtering something that\'s currently part of the process, in a way
that\'s compatible with this.

So it\'s the combination of conditions. And there was a discussion, for
example, a very heated discussion in the HITSP by people who wanted to
have chief complaint always be SNOMED coded. And the complete \-- what
was viewed by many as the total unfeasibility, if that\'s a word, of
changing ADT systems and requiring everybody to SNOMED code chief
complaint on admission to an ER, for example, certainly within a year\'s
time. Or potentially, that\'s one that I\'m not sure a lot of people
thought was ever going to be feasible.

But for others, it\'s that combination. Not just the what, but how the
data is to be transmitted that poses the problem.

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

This is Ed. I think the fact we\'re giving kind of two ways to do this,
is what keeps it feasible even within a year. And I completely agree
with Eileen, that if you\'re trying to modify mainframe registration
systems, the lead time for doing that is about a year, possibly, on
average. You may get a subgroup of hospitals that are ready to do this
in a few months, but if you look at the bell curve it\'s going to be a
year in advance before you\'re going to get significant percentage of
the country\'s hospitals modifying their mainframe registration systems
to do anything for us.

So I think by doing a two-tailed proposal here, it\'s going again to the
feasibility, may require entering data into Web form since
(indiscernible) report these categories may not be available; and number
two, may require significant automation on the part of sending facility
to achieve passive transfer of this data from an ADT system. That\'s the
way I would modify those two feasibility statements.

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

And I think Ed\'s statement was very telling when he said it would
probably take about a year to do this, and when you think about the
budget cycle and approval issue \-- and it\'s going to vary with the
size of the organization. Obviously, the bigger the organization, the
longer \-- the further ahead the budget cycle works, and the more total
expenses involved.

On the other hand, in (indiscernible) cases the larger organizations are
already more automated than smaller ones. But you put it all together
you\'ve probably got almost a two-year lead time required to go from,
oh, this is something we have to do, to we\'ve turned on and we\'re
live.

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

If the only way you can do it is by reprogramming your registration
system

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

Correct, if you\'re really starting with scratch with something, agreed,
and that goes back to what Marty said a few minutes ago, or it might
have been Art, I thought it was Marty, about the fact that we\'re going
to see a spectrum and a range of some organizations may be much more
able to respond very quickly than others. So this is going to be a
considerable range of what different people can do in what kind of
timing.

I mean, if you want, I can share with you just an example of what it\'s
taking us, in terms of starting to look at SNOMED coding internally, it
took us almost a year just to get approval to significantly start
costing out what it would take to do it. So it\'s a long lead time, with
very large datasets and very large organizations.

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

Well, I don\'t want to keep us just on this. I think I\'ve captured a
number of these things, these last comments, and I think we\'ll add
another bullet to the preconditions regarding feasibility, or a little
more detail about that. And I think we also should modify the little
footnote on each of these pages, so that there\'s a little more detail
about what feasibility means. And Scott, I hope you\'ve just put that
down as an item for us to keep working on, and maybe we can move on to
the next table, rather than spending all our time on 2.

But I think from my perspective, we\'ve now actually got three
categories of feasible. One is "yes," which implies somehow it\'s not
going to take that much work to do this. Yes, asterisk \-- it\'s either
going to take a large modification of the mainframe system, and that may
take us \-- we just went from one to two years to do that, or it may
require use of a Web entry form, as Ed has given us a good example from
Oklahoma. And then no.

Is that a good summation of where we are? Or does somebody have some
additional comment on this?

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

That sounds fair to me, that sounds like a fair representation of the
conversation.

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

I think that sounds good, and I think you\'ve got enough explanation and
definition that keeps us credible, which was my concern.

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

Yeah, I don\'t want us to do last stab either.

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

Nobody does.

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

So Marty, you were about to take us to Table 4, is that right?

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

Can I just summarize? On section 2, are they all "yes-asterisks," then?

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

Well, 2.1, 2, 3, we believe is a "yes." But we do need to check on 2.3,
just to be sure that the ADT carries death information in there. I
don\'t think anyone on the phone is certain of that.

Laura pointed out that 2.1, 2.2, should be available from the ADT
system. And the rest of them relate to the HAvBED specification.

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

Okay, so I\'ve got a 2.3, with a "yes-question mark," and then we\'ll
check on the ADT, the HL7 segments that carry the patient has expired.

And then 2.4 through 2.16 are "yes-asterisks," correct?

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

That\'s correct.

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

Art, this is Marty, just a clarification. I like the classification as
you summarized it. In the "no," do we need to qualify that in any way,
perhaps? It\'s not feasible in this time frame, with the current
resources? Versus never. I guess is do we want to make that distinction?

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

Never say never.

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

So not feasible within the timeframe? Is that \-- are folks okay with
that?

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

Yeah.

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

Okay, great, thanks, Art.

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

Okay, very good. So we\'re back on \-- actually, we\'ve got some
asterisks, and we\'ve got a "Y-slash-no," in the \-- in 3, so maybe we
should run through this, as well, before we go on to 4.

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

I think so.

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

Since we\'re now getting a little more clarity about what we mean by
feasible. Does anybody think that creating a data linker, a
pseudonymized data linker is feasible today with the current mainframe
systems?

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

The reason I think we have the "yes" there, is Lynn Steele felt quite
empathically it was, because they\'ve been able to do it in the context
of BioSense. Unfortunately she\'s not on the call today to discuss that.

I personally feel quite empathically the opposite, that it\'s not at all
feasible for most folks. And for some entities \-- and I can speak for a
company like a laboratory, we don\'t have a patient medical record
number or a patient registration process to begin with. Our core
relationship is with the physician, not with the patient.

So we don\'t even have a medical record number, to start off with, to
anonymize to.

So it would be \-- I can tell you for us that would take literally years
to create. And I suspect it may not be as hard for an entity that has a
medical record number, registration system, and a single identity number
for a patient today, but I don\'t think anybody has the capability or
the practice of actually doing this today in place.

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

Right. And I think that Lynn has been fortunate to get that done, and I
think there are now 40 different sites that have BioSense. With funding.
I mean, the fact that my hospital now provides BioSense data is not a
coincidence, it\'s because BioSense was able to provide us with some
support to make that happen.

So again, it\'s feasible, but, it\'s feasible given there were a cost,
and those were met by the BioSense project group.

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

I think that\'s a very good point. If there\'s somebody underwriting
doing this, you know, as somebody mentioned earlier, given enough time
and/or money, almost anything is feasible. But if you\'re not offering
those budgetary supports to people, it\'s a different issue.

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

Right. Any other comments on this one? So I\'ve captured those thoughts,
and I\'ll be putting those in the notes, here.

It\'s going to take some significant revision. I mean, assuming we\'re
in an institution where there is a medical record number. There\'s going
to have to be some processing of the data as it comes out. And they
installed a BioSense intelligence center, I think what it is is a
server, that provides this data streams to CDC.

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

Right. This is Laura. I mean, it is being done, you\'re right, it
(indiscernible) required, and we have used BioSense funding to enable
the first set of hospitals or clinical care groups to send data \-- I
mean, my take on this is that the charge is that data flows to all
levels of public health. So we have to figure out a way to do this if
we\'re not going to send identified data to the national level, which
is \-- we\'re not proposing that we do that. So I think it will take
some doing, depending on what kind of (indiscernible) like what you\'re
talking about, Eileen, to think about how to make this happen. But I\'m
not sure that it will do us justice to say it\'s not feasible to do
this. That is sort of the underlying premise of what we\'re doing as far
as getting data flowing to all levels of public health.

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

Well, but the data that was flowed to a local health jurisdiction may
not need to be pseudonymized. I\'m not sure about that.

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

I\'m not sure we\'re talking about sending different messages of
different data at different levels at this point.

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

Sure, local public health agencies currently get fully identified data,
because that\'s part of the regulatory data for local agencies. But at
the CDC, at the level of data going directly to the Federal Government,
that\'s not part \-- not supported by regulation at this point. At least
in my knowledge.

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

Right, well, it\'s not \-- not that you can\'t do it, we just don\'t do
it. We don\'t need to do it.

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

Right.

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

But I think we may disconnect in that I think we\'re talking about the
same data, flowing from clinical care, to all levels of public health.
And the reason to do the anonymized data is so local public health can
go back and get the data if they need to get it.

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

So what would the group vote for, for this? Is this feasible? Are we
still at a "yes-slash-no"?

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

Can you describe what "yes-slash-no" means again? Now that we\'ve all
put in our two cents?

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

That there\'s not consensus.

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

Okay.

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

That\'s what I interpret that as.

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

Okay.

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

And that actually should be a "yes-asterisk-slash-no." And one example
is the example that Eileen has given us a "no" for a laboratory, which
has no medical record number.

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

Right.

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

And the other, the "yes-asterisk," would be that we have data, but we
would need to invest to make it happen.

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

Right. So there\'s the caveat of investment, and there\'s the caveat
depending on what the source of data is.

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

Right.

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

And this is Marty. I think also the caveat of the record number.

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

Right. Yes, that one is in there for the lab, the example that Eileen
gave us, of the record number.

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

Yes, that\'s what I meant by the data source. Some data sources can do
that, and others will have to have creative ways to link back to
different things. I mean, I assumed Eileen \-- I mean there\'s something
doing like to the accessioning number that then has to link back to the
ordering physician that can then link back to the patient, or something
like that.

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

There are ways that we do it right now when we need to, through
combinations of different fields that we get. In some cases there\'s
nothing we can do, because if we get data from another laboratory, we
have no control over what they send us. And we often either get samples
that just have some sort of reference number on them, or they have very
minimal data, they might have a patient name, and literally nothing
else. Or a name and age and gender, and nothing else.

Which is hardly enough to conclusively link a record with anybody else.
Even if it has the same, name, age, and gender, I would consider that a
very weak link if that\'s all the information you know about the
patient. And we only get a patient\'s home address, for example, about
65 percent of the time. So that\'s \-- and considering that we report
ten million results, that\'s a large volume of minimally identified
data.

And I\'m sure it\'s not just laboratories who are in that circumstance,
I\'m sure there are other types of medical providers that have similar
issues.

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

Okay, I\'ve captured I think both of those points, and I\'ll have those
in the noted \-- the notes and comments. Shall we proceed through the
rest of this table, or are there other comments about 3.1?

I take that as we should proceed.

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

I think so.

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

I think so, too.

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

Just to wrap that up, I have a "yes-asterisk-slash-no"?

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

Correct. The next one is encounter time and date, I think that one is
pretty clear, that\'s a "yes."

The date of birth, there was this comment about introducing
identifiability, and earlier someone had suggested limiting it to month
and year. Is that still a concern about identifiability?

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

That was Farzad Mostashari, when he testified before the committee, who
indicated he was concerned about using the full date of birth.

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

Right, if we limit it to year and month, would that still be Farzad\'s
concern?

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

I think as I recall he was comfortable \-- no, actually, I think Farzad,
if I\'m not mistaken, was arguing or advocating for just using age. But
I would want to like go back and look at his notes again or double check
with him.

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

Then I think that Shaun Grannis has said that age was not generally
something available out of the system, that that would have to be
calculated on the way out.

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

Right.

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

So should we \--

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

Although I think for most systems that\'s \-- you know, in the scheme of
some of what we\'re talking about, that probably isn\'t that difficult
for most systems to do.

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

Right.

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

If you\'ve got a date of birth and a date of service.

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

Well, should we limit this to just age, and not date of birth? Should we
combine 3.3 and 3.4?

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

You know, I guess I \-- I tend to think for most public health purposes,
age should be sufficient. But I think part of the rationale was to make
it easier and say if it\'s easier for to you give us date of birth, give
us date of birth, or give us age, and we\'ll take whichever we can get
and make the best of it. But \--

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

That\'s what I was thinking, is maybe we could make it either-or, or
both. Whatever is \-- and that would increase the feasibility.

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

Right, I think that\'s what we said, and then we added a unit variable
around age. In case it was \--

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

Months.

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

Infant, yeah, age \-- months, or days.

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

Okay, I\'ll add that to the notes and comments after age.

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

And I thought we had already talked about month and year, and
eliminating day. It\'s also in the comments in the description.

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

Right, I don\'t think there\'s any reason we need to get day.

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

Yeah, I agree.

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

So I just want to be sure, date of birth not needed and introduces
identifiability concerns, is that general comment still applicable? Do
we leave it there for people to interpret how we\'re thinking?

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

Oh, I see what you\'re saying. I think it\'s useful as a reminder.
Because sometimes, we have the discussion, and after all, probably half
of our committee is not on the call today, and so not everybody even on
the committee will have taken \-- or the group will have taken part in
this conversation. Never mind folks outside group. So I think it\'s a
useful reminder.

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

Okay, good.

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

You could add full date of birth not needed, since we\'re taking out the
day, that makes it clearer.

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

Agreed.

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

That\'s a good addition there, Perry. Good. Okay, well then, I think we
can slip through the next few, unless there are some comments, through
the end of this table.

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

Art, this is Scott. Just to summarize, so date of birth is a "yes-yes,"
and we\'re eliminating age, or "no"?

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

No, you\'re still there, and I did capture this section. The only things
that I\'ve changed here on 3.3 is we added the word full, before the
word \-- the general comment. And then in age, I\'ve just noted that
either date of birth or age, and we need to add a unit, either years or
months age.

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

And would "yes" then be a "yes-asterisk"?

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

The age is still a "yes-asterisk," based on whether it could be
calculated or not.

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

Okay, very good, thank you.

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

Okay. So no more comments on 3? We\'ll move on to 4.

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

Sounds good.

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

Okay.

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

Is everybody okay with the ZIP code in 3.6?

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

I\'m sorry, could yoU put the last elements up? Just sort of jump past
them?

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

I\'m sorry, Eileen?

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

Okay, thank you, that was what I wanted to see, since we didn\'t \-- it
probably would help to just sort of glance at these rather than just
skipping over them.

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

Oh, you\'re looking at it on a Web view?

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

Yeah.

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

I see, I\'m looking at it on the document itself.

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

We have a "yes-question mark" on the filtering of the ZIP code, and I
believe that had to do with the three digit versus five digit, and the
general comment would be could follow the HIPAA guideline.

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

Yeah, the issue had to do with sparsely populated geographies, where
combinations of elements, including ZIP 5, could be considered to be
essentially identifiable.

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

So that\'s a "yes"? This is Marty. Yes, with that comment, that caveat,
that it might be necessary?

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

Yeah, that seems correct to me.

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

Okay. Good.

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

Okay. So we\'re going to take away that question mark there after
filter, and that would be conditional on whether it\'s a sparsely
populated geography?

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

Yes.

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

Okay. Good. Getting cleaner.

Okay, any more on that section? Scott, did you have anything else?

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

That\'s it for section 3.

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

4 now?

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

Yes. We\'ll keep trying to get to 4.

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

I think we finally got there.

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

I think so, too.

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

I think we\'re moving pretty well today.

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

I agree.

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

Now, we\'ve moved a lot of these general comments to the top of this.
You may want to look through this a little bit. I think we\'ll do some
cleaning up of this.

So I mean, I think probably we can come back to these general comments,
these are the comments from the testimony. But maybe we should try to
just run through this table, and see if we can complete the filtering
and feasibility sections, at least for this section 4.

I haven\'t got the agenda open, let me just look back, how is our time
doing?

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

We\'re doing well so far, Art.

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

Okay. Good. So the diagnosis \-- this is an ICD-9 code that would be a
straight feed from the registration system. I think that\'s feasible.

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

But the concern here remember was the timing. That the ICD-9 code may
not be ready at the time of admission.

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

That\'s correct. But all we can do is just take what\'s available. I
mean, what is it \-- so do we need to clarify what is available? Or what
we think might be available?

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

Or when, rather, I think. But yes.

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

Okay, so maybe we\'ll put a little feasibility comment in this notes
section for the first one.

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

Right, the comment that I see is may not be available in real-time.
Which I think is, you know, a fair \--

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

Right.

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

Any filtering necessary?

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

I can\'t imagine that we\'ve set up an algorithm to filter out just
certain diagnoses. That would be pretty complex. I don\'t think we know
what we\'re looking for. It\'s specifically an ICD-9 code. Being
national scenarios.

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

Well, but I think that actually there is \-- this is one of the places
where that is a question, is depending on the volume of the data, can
the receiving system handle getting information about every admission,
every day.

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

Well, this is where I think it would be good to have Lynn on the phone.
I wonder how many terabytes they have right now just from 40
institutions sending everything to them.

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

Right. This may not be so much an issue of feasibility on the sending
system \-- although it could be, if a system \-- and you know, if a
hospital system is very, very large, depending on the size of the file,
but there\'s a limit to how many patients can be admitted to a hospital,
generally, in a single day. So it probably isn\'t a huge barrier to
them, but the barrier is more on the side of who is getting it.

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

Right. So the answer to filtering is really dependent on the site where
this will be received.

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

I would suspect so.

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

Yeah, in earlier discussions of our committee I think the example had
been put forward of psychiatric diagnoses being filtered out for \--
since it would be less likely to be needed by public health, and because
of sensitivity issues. I don\'t know \-- my memory is that psych
illnesses make up a significant proportion of hospitalizations. So that
might cut down the volume a lot.

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

That\'s a good point.

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

Okay, so I think now we\'re hearing a vote for "yes" for filtering, is
that correct?

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

I\'m thinking probably yes.

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

Well, at least as an option, yeah.

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

So yes, with filtering, with a caveat of an example of a type of
diagnosis we\'re talking about?

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

Right. Psychiatric diagnoses should be filtered. And it is feasible. So
we have "yes-yes," here.

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

4.2.

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

Right. This diagnosis type, I know that only \-- I\'ve only seen this in
terms of the ED, that will get this preliminary diagnosis. Outpatients
have only a final diagnosis, and the ED does this preliminary on
admission to the hospital. Anybody got more information about this
preliminary interim and final?

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

Well, it definitely applies to lab reports. But for admissions, I would
agree, it primarily makes sense for the ED department.

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

So should we clarify that these are not the \-- are we expecting that a
lab result would have the diagnosis associated with it?

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

In the case of microbiology, essentially it does. But no, I mean, this
is not lab data here, so I think it\'s \-- I don\'t think we need to
bring that into the discussion right here.

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

Okay, good.

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

It\'s impression \-- I thought these data elements were for clinical
encounter.

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

Yes, that\'s what I thought, too, I just wanted to be sure.

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

I just said that because that\'s the context in which I\'m familiar with
using those classifications is the labs.

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

So it is \-- diagnosis type would be feasible, I mean it\'s part of the
transmission, and do we think it needs to be filtered? I would say no.
But \--

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

I would say no.

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

I\'m sorry, so what did we decide diagnosis type refers to?

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

It just means whether it\'s preliminary, interim, or final.

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

For discharge diagnosis?

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

It could be on admission to the hospital, the ED does a preliminary
diagnosis.

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

Yeah, usually referred to as admitting diagnosis. Is that what you mean?

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

Uh-huh.

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

Is that your understanding, Ed? Maybe Ed\'s not there.

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

This is Marty. In this case, then, we\'re referring to 4.1, so \--

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

No, this is 4.2 now.

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

But it\'s defining 4.1, right?

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

Right.

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

This is Ed, I\'m here, my mute button is giving me fits, but \--

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

So I guess I\'m confused. I\'m assuming that 4.1 is the discharge kind
of the final diagnosis. If we want the admitting diagnosis, which never
changes, once it\'s in the record it stays the same, and then the
discharge diagnosis \-- are we envisioning that 4.1 would change, and
that 4.2 would then change \-- I\'m confused as to what we\'re asking
for, I guess.

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

4.2 is the qualifier for 4.1. 4.1 just says it\'s a diagnosis, 4.2 says
what kind of diagnosis. Is it the diagnosis \-- the final diagnosis,
the \--

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

Okay, so if I get admitted today, and my record gets uploaded with
admitting preliminary diagnosis in 4.1, and 4.2 says preliminary, and
then I get discharged tomorrow, and that changes, you\'ll get a separate
report on me with a final diagnosis. Everything will be the same in the
record except that now there will be 4.1 and 4.2 will be different.

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

Right.

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

Okay.

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

And the time span is different.

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

Right, I\'m sorry, yeah, of course.

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

So are you okay, Perry?

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

Yeah, I understand. It sounds fine.

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

So then we\'ll go ahead and put "yes" and "no" for 4.2. And "yes" and
"no," I assume, for 4.3?

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

That\'s right, yeah.

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

And for the disposition. "Yes" and "no" for the disposition?

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

This is something that would be standard in an ADT record?

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

Okay \--

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

That\'s a question.

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

That\'s the question that we have off to the side there. Need to develop
a standardized list, and does BioSense have one. That\'s still pending.
So I guess there are some things we can follow up with Lynn after this
call.

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

And you understand the intent of that was okay, your discharge from an
emergency department, where you may be discharged to become an inpatient
in the hospital, or you may be discharged to be transferred somewhere
else, or you may \-- your disposition may be discharged home as an
outpatient for followup. That\'s the piece of information we\'re trying
to capture, here.

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

Right. Okay. So that\'s a "yes" and a "no" for 4.4. We do need a list,
as you point out, Eileen.

And same with patient class. What is that, Ed? I can\'t remember that,
now.

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

Well, I think the intent is we\'re collecting data on inpatients,
outpatients, emergency patients, et cetera, so that\'s really what
that\'s applying to.

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

Okay, so we need to \-- I\'ll put that in. Inpatient, outpatient, or
emergency department.

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

I think those are the main categories we\'re thinking. Now, Medicare
parses it, you know, a true inpatient versus an observation \-- you
know, short-stay type of inpatient.

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

Right.

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

And I don\'t know if we\'re trying to parse to that level of detail or
not.

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

Once again, maybe we can go to BioSense and see if they have some
definitions for these classes.

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

I agree.

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

And by the way, Scott, if somebody could forward on \-- if we\'re up to
4.5, if we could change the screen, I got the document, but \-- I can
open everything else, when I try to open this document it crashes
Microsoft Word on me. I don\'t know why. So thank you.

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

That\'s your problem, not ours.

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

I assume so, but it is my problem.

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

Do you want me to send you another copy or \--

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

Yeah, if you\'d like, sure, that would be great.

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

I\'ll send you the one I\'m working on.

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

Okay, because I have no problems with any of the other documents, but
every time I try to open this one, I get a crash.

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

Just so you know, did a little research on patient class, and it almost
always referred me back to the insurance type.

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

Oh, okay.

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

So it says patients by specific classification, usually insurance type.

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

Well, and that would be different from what I understood it to be.

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

Yeah. No, I was going the same direction as you, Ed.

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

I don\'t know if (indiscernible) for biosurveillance we really need to
survey based on insurance type, do we? At least not for the scenarios we
looked at.

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

I would agree.

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

Yeah, agree.

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

It\'s not in our glossary, either.

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

So are we looking for a different item than patient type? Patient \-- we
need to find the right term for what Ed just described as inpatient,
outpatient, emergency department, or observation short-stay. We have a
description without a name.

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

I\'m not connected to the internet, but I\'ll look it up. I think it is
patient type, though, if I\'m not mistaken. Rather than class.

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

Okay, let\'s presume we find the right term. This is feasible, it\'s
part of the ADT message, right? And it would not require filtering,
because the filtering would occur at the level of the diagnosis.

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

But I \-- just to be clear, we\'re looking for the term that specifies
inpatient, outpatient, emergency room, those type of patients, correct?

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

Okay. So if we could move on to 4.6. If there are no comments on 5.

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

Okay.

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

The date and time of illness onset. Is this feasible? I don\'t know that
it is. It would be a rare system that has this recorded.

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

Yeah, that\'s what I would think, it would be in an admitting note,
but \-- somewhere, probably, but not \-- and I must admit I quibble with
the term illness onset. I mean probably the best we can do is symptom
onset.

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

Right.

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

These things are routinely required on triage forms in paper. And I
think as more and more people move to electronic record systems for that
step, it will get recorded.

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

Well then, maybe the issue is that it\'s not really feasible \--

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

I think that comment you put in is currently captured on paper, in most
institutions. May become feasible as electronic record systems are used
to document (inaudible) patient in the future.

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

Yes, that sounds right.

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

But given what Marty added as a description for "N," which is not in the
short term, meaning one year, or even if we said one to two years, it\'s
not feasible in most places at this point.

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

In three years from now, it may be very different, but \-- because I
think a lot of places are starting to implement these electronic
systems. But it\'s certainly in a state of transition.

And I would certainly say no for the first year.

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

Okay, and I think that\'s what Marty was at, was "no" for the first
year. I have to go back to the other document to see that, hold on a
second, I think that\'s what we left it at. Yes, not feasible during the
one-year timeframe.

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

I wonder if our feasibility column should say "yes" or "no" for one
year, "yes" or "no" for years two through five, and beyond, or
something.

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

Well, we could organize it that way. Maybe, Scott, maybe take a note on
that and see if we want to come back to these tables and organize it in
what we had before as our short-term and long-term. For functionality.
Maybe we want to do the same sort of thing here for feasibility.

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

We could play around with it.

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

You can say, you know, one year or less, years two and three, and
years \-- you know, beyond year three, something like that. The trick is
that, you know, there\'s always cutting edge institutions that are ready
to do it right away. So it\'s feasible for them today.

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

But aren\'t we thinking in terms of sort of the \-- the general case?
Neither the cutting edge, nor the organizations that may be really way
behind the time, but are sort of the bulk?

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

I know, that\'s where the whole feasibility definition becomes
difficult. A binary "yes-no" is difficult to say.

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

And I think that goes back to what is our definition of feasible. And I
tend to think what we\'re going for is what would be the sort of middle
ground, the more general case. Neither the exceptionally good nor the
exceptionally bad, but the most likely scenario.

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

And maybe that\'s what we\'re going to end up having to go to,
eventually, is saying all right, it\'s feasible in less year means
greater than one-third of the hospitals could feasibly implement this in
less than one year. And actually quantify it both on \-- from the time
access as well as the percentage of hospitals able to implement access.

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

Yeah, that might be a useful way to frame it.

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

And then feasible for years two to three would be, you know, greater
than one-third of hospitals across the country would be able to. Because
you\'re never going to be able to get all of them, no matter what we
say.

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

Exactly, you\'re right. And there\'s always early adopter.

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

There are always early adopters that are ready to do it right now.

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

But they\'re not the norm, either.

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

Yes. Well, I keep adding these comments to this feasibility
precondition. So \--

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

Sorry to do freeform thinking on the conference call, but \-- trying to
help us all think along the same lines in terms of these definitions.

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

It\'s helpful with the clarity, here, it\'s important.

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

Yeah. So I think we\'ve agreed that date and time of symptom and/or
illness onset is not immediately feasible, but I\'ve got captured on the
right-hand side, that this is data that is available on paper, but may
be feasible as greater penetration of electronic data capture.

There\'s no need to filter this. So there may be a need to process it,
if it\'s in a free \-- you know, if it\'s data captured in a free text
field. You know, three weeks ago or \--

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

Yeah, may need to be reformatted somehow, or transformed \-- as you say,
three weeks ago. A lot of it may be in a form like that.

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

Okay. So I don\'t know if that\'s \-- that\'s not our definition of
filtering, that probably relates more to feasibility.

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

But that might be something, yeah, that we want to add as a comment.

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

Yes, I just added it. May need significant reformatting or some natural
language processing.

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

Yep.

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

Okay. Chief complaint. Or is there more on this 4.6?

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

No.

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

I think these same principles are going to apply to all these clinical
data items in this table now.

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

Yeah. I think the same sort of thing, it\'s not necessarily really
feasible at this point, it\'s going to require some of the same sort of
natural language processing, maybe captured on paper, so we can
basically copy that section down again?

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

Yep.

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

Okay. Now, we have a comment there about feasibility for 4.8. Now, who
is that from? That was from someone in Texas, was that not, Scott?

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

Yes, it was. I will go back real quick and look it up while you all
discuss, and let you know who that is.

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

So what do you think about that, Ed?

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

About the 1 in 67 statement? Which one are you on, 4.8?

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

Right 4.8, and 4.9. If these are 1 in 67 \--

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

That means it\'s feasible for that hospital, but not for the other.
That\'s why I\'m saying, if we define our feasibility as maybe saying a
decent chunk, like a third, is that a reasonable number? I think you can
have a pretty good biosurveillance if you have a quarter or a third of
the hospitals reporting on any data element.

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

I\'m trying to follow your line of thought, now we have less than two
percent capable of doing this currently.

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

Right.

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

So is it feasible.

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

Feasibility would be "no" if we say one-year feasibility, is that a
quarter of the hospitals could do it, potentially. What do you all think
about a number, a percentage number, that we say is our feasibility
cutoff? Because if we can move toward a consensus on that number then we
can really \-- help speed us along in our discussions.

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

Okay, I thought the last part of the discussion said one-third, but I
can move it to one-quarter, I\'m happy to do that.

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

I\'m just throwing out different options, I don\'t know if anybody else
has an opinion.

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

Those numbers sound reasonable to me.

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

So then if we do work on these columns saying one year or less, two to
three years, greater than three years, something like that, should we
use that same quarter for each of those?

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

Yeah.

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

I think if you use 25 percent, if you get 25 percent of hospitals
reporting on a single data element I think you\'d have a pretty powerful
system for analyzing that data element. You could have a lot of data.

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

Uh-huh.

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

As opposed to two percent or five percent.

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

Actually I think that\'s a great idea, because it provides some
differentiation within all these variables and gives some idea of how
difficult each one is. I like the 25 percent \-- I agree with you, 25
percent of hospitals reporting in one year would be an astronomical
success, that would be great.

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

Right. Okay, we\'re getting some clarity about this feasibility, here.

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

Well, it\'s \-- you know, it\'s such a serious issue that I think it is
worth our or digressions.

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

Yes. So I think based on that report from Texas we should say "no-no."
To both 4.8 and 4.9.

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

Right. Well, I don\'t think \-- I mean, filtering \-- oh, yeah. Yeah,
filtering would be "no" anyway so \--

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

And nurses notes is going to be "no-no," too.

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

I missed what we said on 4.7 for chief complaint, is that a "no-no"?

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

That is "no-no," also, that is correct.

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

In one year.

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

Let me just play devil\'s advocate we have contacted all our hospitals
in upstate New York, and we have over two-thirds of them, I would
estimate or nearly two-thirds of them reporting chief complaint
electronically to us. And it turns out to be fairly easy.

Now, and they all do it generally within 24 hours. So I\'m not sure why
we\'re saying it\'s not feasible.

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

Okay, so are you doing the natural language processing?

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

Yeah, it\'s just text fields that they\'re sending us, is that not what
we\'re talking about here?

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

That is what we\'re talking about.

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

Yeah, this is, I don\'t understand why we got to "no," either.

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

Okay, so we can change that back to the "yes."

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

Yeah, I think with the RODS implementation and some of the other State
and local implementation you may be up to a quarter.

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

I\'m pretty sure New York City also does \--

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

That\'s right, New York City is also ahead of us so \--

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

Again with the caveat that it\'s free text. That nobody is being forced,
that I\'m aware of, or \-- force is the wrong word, but nobody is being
required to do it in a coded form.

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

That\'s correct.

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

Are Web forms being used for that?

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

No, that\'s coming off direct entry into the registration system.

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

We\'ve transiently used Web forms to report like numbers, in other
words, what was the number of fevers of the patients you saw in 24
hours, but that\'s a little different from what I think we\'re thinking
of here.

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

So it\'s a "yes-no."

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

For temperature everybody? What was that under, the "yes-no"?

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

Chief complaint, 4.7.

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

The feasibility statement under temperature is from Dr. Shaun Grannis,
the Indianapolis group.

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

Okay, they obviously have their manner of experience in this area thank
you Scott.

Okay, how about nursing notes?

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

No, no.

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

It\'s the same as the date and time of illness discussion.

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

Right.

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

I think this \-- I mean, there has been some success in getting nursing
notes or triage notes. North Carolina gets it in their (indiscernible)
detect \-- and BioSense is getting \-- is capturing it if it\'s there. I
think the piece here is it\'s just not consistently there
electronically.

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

I think it was the concern about transmitting that where there may be
some revealing of protected health information.

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

Right.

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

Does that make it infeasible? Again are we talking about technically
or \--

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

Well, are we just about technology, or are we also about \-- why do we
take away the (Inaudible) month day and year in date of birth? Isn\'t
that because of HIPAA protections?

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

Right.

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

Where does it come to filtering of this, what\'s in this, then?

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

Yeah, but filtering free text, is a very, very complicated thing.

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

Right.

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

I mean, NLP is a wonderful thing, but it\'s not a plug and play process
for all \-- you know, any and all text you might encounter. At least not
today it isn\'t.

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

Right, no, I don\'t disagree with you. I guess just trying to be
consistent across how we\'re determining feasibility and filtering,
there\'s nothing technically infeasible about getting the nursing notes
data element in a data system. It\'s, in my mind, it\'s more of a
can \-- do we need to filter it before it\'s appropriate to send to
public health.

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

Uh-huh.

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

So it would need filtering. For sure on this one. Because we do not want
to release PHIs, is that correct?

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

Yes.

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

And it\'s feasible?

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

Well, I would question \-- I\'d defer to others who have more
experience, but I\'m not sure that nursing notes are readily available
electronically, are they? Unlike chief complaint.

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

I didn\'t think they were, but \--

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

My thinking is not, but I\'d defer to others who may know more.

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

I think it\'s not likely that you\'re going to get to 25 percent in a
year.

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

Yeah.

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

So not likely.

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

Okay.

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

So we can say that this is a "no" here, right?

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

Yeah.

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

\-- so (indiscernible) columns?

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

A "no" and "yes."

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

And I would say "yes" in the next two to three years, but just not in
the first year.

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

Meaning that you think the penetration of nurses notes to being
electronic would exceed 25 percent?

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

For triage, yes, in the next three years, over three years, yes. But
just it\'s not going to happen this first year.

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

Okay.

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

That\'s my crystal ball view of the future.

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

Good.

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

Good, okay. And we have the last one. I think there was some debate
about this earlier. It remains on our list, the provider identifier. I
assume this is feasible, that\'s what we typically associate with one of
these records is an identifier. And it would be no need to filter it.

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

Well I think some of the concerns here had to do with exactly what the
identifier is. And I agree with you there\'s no need to filter it, but
there were some questions raised in the HITSP by some of the commenters
and also by some of the members about \-- I mean, it was a big
discussion of the identifiers, and how they were going to be created and
tracked.

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

I think you were talking about the identifier from an institution. So it
would be unique to the institutions from which the record is being sent.
It\'s not a national ID for all providers.

I think HITSP \-- I think I heard John talking about this last week.
That using the national identifier for each provider, national provider
ID, isn\'t it, what HITSP was thinking?

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

Actually they were talking about wanting OIDs.

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

OIDs at a provider level?

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

Well, some combination of OID, and they \-- there was a very intense
discussion that took nearly an entire day over OID versus NPI, and they
said, well, CMS could get a top level OID. But because of wanting it to
be compatible, it would require sort of \-- I guess a prefix, probably,
to the NPI, to make it compatible with the OID standard.

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

My bias says we just drop it. I think it\'s going to be one of those
things that would give providers a reason to be suspicious about
submitting their data and cooperating.

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

Should we take it off the list entirely now?

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

Yeah, I wouldn\'t argue with that.

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

Yeah, I would agree, too.

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

Anybody opposed to that? Okay. It got deleted.

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

All right.

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

Okay, we\'re down to \-- well, how are we doing for time, now?

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

Let\'s do a time check, here. We have said in the rest of the agenda we
were going to talk a little bit about preconditions, and then do update
of the next step for the reports.

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

Now, I have to get off in about another 15, 20 minutes. I think \-- we
are scheduled to adjourn at 4:00 or 4:30?

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

I have 4 o\'clock Eastern, is that correct?

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

Yes, it is.

And we have not gotten through the laboratory microbiology results. We
went through the order set, but not the results. So that would be
section 6.

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

Well, we\'re on a roll, it would be nice to move ahead with the
feasibility. And we can \-- we have to update the preconditions anyway,
with the feasibility definition.

Art, what do you think?

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

Yeah, I think we should finish this out and then circulate the
preconditions document within the next couple of days, with this
additional comment about feasibility. And then solicit comments back by
e-mail. I think that would probably make more sense. It\'s easier to
have the discussion about this feasibility and filtering as a group
rather than, you know, the simple comments, it\'s easier to edit the
preconditions document rather than to kind of do this discussion that
we\'re having now. So I agree, we\'re on a roll, we should finish this
out.

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

Okay with everyone?

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

Yep.

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

Yep.

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

Fine.

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

Okay, Art.

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

Actually, before we leave the order elements, if you\'re saying we were
done with those, I did have one comment I wanted to add under the test
procedure code. Or were we going to starting about through those again
anyway?

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

Is that the code or the name, Eileen?

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

Code.

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

Okay.

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

Given we\'ve discussed feasibility, Art, how about if we just run
through the three that is right on the 5.1, 5.2, 5.3.

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

Sure. Eileen?

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

Okay, just with respect to the code, the only issue has to do with the
fact that a lot of times, tests are put into production, there\'s a lag
time before you get a LOINC code assigned. So that you can\'t
necessarily limit the data to only LOINC. I mean, obviously you don\'t
want to give people an out and say LOINC or local, because then why
would anybody bother to go to LOINC. But they have to be able to use
local coding if there really is not a LOINC code available.

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

Eileen, within ELINCS I think they address that with the LOINC
committee, that they would get them LOINC codes within 24 hours of
submission.

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

Did they really?

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

Yeah.

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

Well, well, well. Usually we\'ve been waiting way longer than that.
Well, you know, if that in fact is upheld, then my comments go away.
But, you know, that\'s just a \-- just a caveat.

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

Yeah, I think we should capture that, I\'ll check the ELINCS back,
though.

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

And also ELINCS didn\'t cover everything.

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

Correct, it was a subset.

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

That may have helped.

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

I fully remember that discussion within the Workgroup.

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

I think ELINCS may not cover a lot of like investigating, new tests and
things. Anyway, it\'s just an issue we have to keep in mind. And it
probably applies to everything, where there\'s a code set involved.
It\'s not unique in any way to LOINC. The world evolves faster than our
coding structures can keep up.

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

 \-- now going into this, what are we expecting from the institution
that\'s reporting? (Indiscernible) tests? Is that really feasible?

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

I\'m sorry?

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

Now you\'re making me wonder about the "Y" in the feasible section of
the test/procedure code.

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

Uh-huh.

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

That is actually an additional burden for a hospital lab that has not
LOINC-ized all its tests.

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

Oh yes, absolutely. I mean, and we haven\'t LOINC-ized our tests, so
it\'s not just hospitals. But yes, I think there are quite a few people
who have done, and I think along a continuum of feasibility this is
probably, for many people, somewhere well along.

In terms of the percentages, remember what we were talking before about
maybe 25 percent, I \-- this is something maybe I could take to ACLA and
potentially get an answer, if they have some idea of how many of the
laboratories who are members use LOINC or not. Because I really
wouldn\'t know percentage-wise what that would be. But you\'re
absolutely right, LOINC is not, you know, used uniformly, in fact I
think it\'s perhaps \-- the smaller the lab I think the less likely they
are to use it.

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

So I think we should change the "Y" for test procedure code to a
"Y-asterisk." Because there\'s some additional work that would need to
be done to expect them to provide a LOINC value.

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

Yes, I think that\'s absolutely correct.

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

Good.

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

And there\'s also a question about the order number versus the specimen
ID. Which is a big issue, because there was a very significant
discussion in the HITSP EHR Workgroup about unique specimen IDs. Some
orders come with multiple specimens, and many laboratories do not create
unique IDs for each individual specimen that are carried electronically.

They may \-- they\'ll assign one order number to the entire test, and
then have another way internally that they identify the different tubes
or the different samples. But they don\'t actually create a unique
specimen ID. And so there\'s some discussion or issue here over the
order ID versus the individual specimen ID.

And the order ID is I think eminently feasible. A unique specimen ID is
probably not right now. And you know, I\'m not going to argue whether or
not it\'s advisable, because I think that\'s a completely different
question, but whether or not it\'s done today or available, I think that
would be very problematic.

Particularly because that would \-- not just the data transmission or
transformation, but actually an operational change, so that would make
that a very significant change to a facility.

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

Okay, so how do we \-- is that a "Y" in feasible, or not?

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

Well, I think it\'s still a "Y," but it has to do with the comment, the
description, that HITSP uses the term "specimen ID." And basically what
I\'m saying is specimen ID and order number are not the same thing.

If you want order number to be a unique specimen ID, then it\'s not
feasible. If you\'re willing to accept an ID for a test, that may not
identify each individual specimen as part of that test, then it\'s
eminently feasible.

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

Okay.

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

So Eileen, in the spec, would the order for receiving multiple
specimens, it would be the same order number, but we would have
different specimen types, correct?

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

It might be different specimen types, or it may just be a series of
specimens. Like for a culture we\'ll often get four tubes. They\'re all
the same, they\'re all blood, but they\'re four samples. So it can be
different sample types, or it can be just multiple tubes.

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

Just to clarify, each four of those tubes would have the same order
number, for what you\'re telling us.

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

You know, I can\'t necessarily speak for every single laboratory, but I
know in our world, they would all have the same order number. And we
would \-- I mean, we would distinguish between them when we did the
results, and we would indicate that we had the results for \-- this was
the result from tube one, tube three, so on, so forth, or if there were
specimen types for each specimen type. So it wouldn\'t be that we would
just sort of gloss over the fact there were multiple specimens, but they
would not be given unique IDs for each \-- just for the whole order.

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

I\'ll add something about that towards the end there. Thank you. Now I
think unless you have a comment about the procedure name.

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

No.

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

So we can move on to Table 6.

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

Yep.

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

I think we need the lab identifier. Someone said I question the need.
Feasible without filtering, right?

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

Yes.

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

Okay, performing lab, that should be "Y-slash-N," right?

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

The only question I have about feasibility is when you\'re doing
referring work, I\'m not \-- referral work, I\'m not sure \-- if you\'re
the reporting lab, I don\'t know \-- I mean, I know that we do not
electronically carry the CLIA number. If we send a sample out to NRL, we
don\'t carry NRL\'s CLIA number in our message. We carry a text string
that indicates the test was performed by NRL.

So I do have some concerns about \-- I mean, the reporting lab will have
no problem with giving you their CLIA number and the performing lab will
know what it is, and if it\'s the same, that\'s no problem. But I\'m not
sure how that would work with reference testing. If the reporting lab is
different from the performing lab.

So that could be a feasibility problem.

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

Okay. Okay, I\'ve captured that as a feasibility comment to the right.
So that would be "yes" and "no." But a comment off to the right. Is
that \--

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

And it may not be that big a deal, because most laboratories don\'t have
send-out relationships with an unlimited number of partners. I just
don\'t know what would be involved.

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

Okay, the report date and time, we need a definition here, or some
descriptor.

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

I actually looked it up and one of the HL7 sites gave me date and time
of report, and that\'s all it said.

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

So this is just a transmission time. Or is that the report to the \--
where this was ordered from?

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

I think we usually think of it as the time we stamp the report as sort
of ready to go. And ready to send to somebody.

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

So that\'s the date and time of reporting from the laboratory to the
requester?

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

I think so.

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

Okay. That should \--

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

I think one of the issues might be you report \-- you may report data
multiple times to different entities, and so I think that\'s where you
need to have the definition, is do we mean when it was initially ready
to be sent to somebody, or do we mean when this copy got sent to whoever
this receiving entity is.

And probably either of those is feasible, the question is the sending
system has got to know which is the one you want.

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

Okay. Can you say that one more time?

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

Okay, the question is, do you want the date and time that the report was
considered final, versus the date and time of transmission of this
instance of the report?

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

It\'s the latter. Because we have a report status, and that\'s \-- when
you say that the report was the final, is that the final report, or is
that the \-- how does that relate to status, that follows?

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

It may not be, because we would send out a preliminary report, for
example on a culture \-- couple (indiscernible) after we get it we\'ll
send out a preliminary report with the organism, and then a few days
later send out the sensitivities, but each transmission would have a
report date and time associated with it.

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

Right, that\'s where I think it\'s the latter of the two that you
offered, it\'s the date and time of the transmission of this
instance \-- oh, okay, now I \-- not the \-- not which status it is,
you\'re saying the time when the report was being sent?

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

Yeah.

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

Okay. Okay.

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

Basically is this an electronic time stamp or is this the date that the
report was considered final by the lab.

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

Okay. This is both feasible and not filter \-- not needing filtering?

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

That sounds right to me.

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

Okay. The report status. "Yes-no" also?

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

I have no idea what this description means, about SNOMED. Does SNOMED
offer codes for preliminary, final, amended, corrected \-- I mean,
isn\'t that what we mean by report status?

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

That\'s what I would mean.

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

Would that come \-- I guess we\'ve never used SNOMED for that.

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

What do you use?

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

I think there (inaudible) \-- to be honest, I mean, there\'s so few
categories, I never really thought about whether or not there was a
coding system associated. And if anything, I guess I assumed they were
from CLIA. But I just don\'t know.

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

What goes in the OSU field? What we need to find out, what the code set
is. Maybe, Scott, you could pick up on this.

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

Already writing it down.

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

And it may be SNOMED, I\'m just not \--

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

I\'m thinking it may actually be an HL7 table somewhere.

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

You know, that sounds more likely. To me it sounds like it either should
be a CLIA, code list, or HL7 table.

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

Okay.

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

Okay. Well, that\'s not filtered.

The collection date, do we have a definition for that?

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

Art, I actually did some \-- I\'d like to add the slash time to that.

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

Okay.

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

So it\'s consistent with the rest of the time stamps that we\'re
collecting. And what came back on a search was date, and in parenthesis,
and time when appropriate, of the specimen collected.

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

I can tell you for some organizations this can be somewhat problematic.
Ironically. In that organizations that may be picking up specimens from
different medical sites, such as ours, we have couriers who go around,
if the physician does not indicate on the requisition a collection date
or time, all we know is when we got it. We don\'t know when it was
collected. And so we may \-- and I would say in most cases we do not
actually have a collection date and time. We have a received date and
time.

And that I can tell you for a fact can differ by a calendar day. Because
we do most of our work in the middle of the night, and so we will often
get requisition \-- specimens that we suspect were collected on one day,
and they\'ll get accessioned and recorded as received, you know, like
sometime after midnight. I mean, most get \-- I would say the vast
majority get the same date, but conceivably it could be off by a day.

And if you have a date and time, it\'s probably more like off by a
matter of hours. But I do think that\'s an issue for anybody who is not
originating a specimen, is that if you\'re collecting it, you really \--
and I don\'t mean to use the same term, but I think you know what I
mean, if you\'re just retrieving it from somewhere, you really cannot
know when it was collected. If the physician does not record it on the
requisition.

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

Would the lab record that time when received as the collection time,
date and time? Will they fill in a different field?

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

We fill in a different field. We call it our accession time. We\'re not
going to call it the collection time, when we know it probably isn\'t.
Or almost is guaranteed not to be. So we don\'t actually use a
collection time. Nowhere in my database do I have a collection time, in
fact.

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

You don\'t have it, or most of the time it\'s not filled in?

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

No, we don\'t even have a field because it\'s so routinely empty in the
informatics \-- mind you, I work with the informatics data warehouse,
not the laboratory information system. The LIS I believe has a field.
But because it\'s so often blank, we left it out of informatics.

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

Okay.

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

So in terms of the feasibility, of getting literally the collection date
and time, I would say it\'s basically not feasible.

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

At least in a large laboratory like yours.

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

Yeah, and as I said \-- or anybody who gets \-- who does not originate
the specimen, you know, anybody who is getting a specimen through some
other means, I don\'t think that\'s unique to us.

In a hospital laboratory they probably know that pretty close.

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

Yes, because I know that I\'m obliged to write down my name and the date
and time on the specimen that I collect.

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

Right, but I can tell you that it\'s blank when we get the specimens
from the doctors. In most cases.

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

I think we\'re past time now. Are we not?

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

We are.

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

We should stop this, and go to just quickly wrap up.

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

And Scott, we need to open up for public comment?

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

Yes, Matt, could you please open up for public comment?

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

Sure.

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

Thank you.

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

Art, should we sort of talk about next steps, here?

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

Yeah.

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

We\'ve got some reformatting to do on this, and updating of the
comments. Reformatting to the multiple feasibility columns.

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

Right.

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

And then perhaps a couple of us could give a shot at this last few, and
then walk through it in our next call.

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

Our next call is when?

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

We do not have a next call.

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

Ah.

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

Probably need to think about that.

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

Do you have a calendar?

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

Let me look at the AHIC Workgroup calendar real quick.

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

We\'re going to need to have one for final comments on the final draft
of the report.

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

Right.

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

And have a \--

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

Hello?

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

Yes.

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

Hello?

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

Hello.

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

We\'re still here, we\'re just trying to figure out dates.

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

Are there any comments out there from the public?

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

No, there\'s not.

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

So it\'s just the rest of us here. How about \-- Scott, are you looking
at the AHIC calendar? Are you there, Scott?

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

I\'m here, I\'m sorry.

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

Do you think that there\'s a chance we could schedule another meeting?
We were supposed to have the presentation to the Biosurveillance
Committee \-- Workgroup, rather, on the 17th. I wonder if that\'s still
open for us to have a conference call.

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

Since biosurveillance has moved to the 20th, I think the 17th is open.

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

I will not be able to make it, but \--

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

Was that Perry?

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

Yeah. I\'m tied up Monday, Tuesday, and Wednesday of that week, that\'s
a bad week for me.

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

And the 17th is also when the NHIN \--

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

Oh, forum is, correct. What about the 10th?

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

The forum actually be adjourning just after probably 12:30 or 1, so
it\'s possible to do a call until in the afternoon, although some people
may be traveling.

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

That might be the problem for how do people \-- although \-- we have an
office in D.C., I can probably get to our office, so that actually would
work for me.

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

So the 10th or 17th was that, Eileen?

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

Either day would work for me, actually.

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

Okay, can I hear you all discuss the 10th, then?

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

Can\'t make it on the 10th.

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

Okay, Art cannot. So the 17th is better for both of you, Art and Marty?

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

Yes, I can make the 17th.

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

Okay, anybody \-- in the afternoon?

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

Yes, afternoon.

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

Or we can do it in the morning, it\'s not going to matter.

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

Remember that\'s the day \-- that\'s the NHIN meeting. That may not
affect a lot of folks on this call, but \--

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

What time does that finish?

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

Was it Laura who said around noon or 12:30?

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

12:30 currently. There are a few things going on in the afternoon, a
workshop, probably, but most of us won\'t be involved in that.

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

How does 2:00 to 4:00 sound?

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

Sounds fine to me.

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

Sounds good to me.

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

Would you all like to have a planning call then \-- kind of a
prefatory \--

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

One of the other concerns is does this have to be public?

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

These are prefatory.

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

For the 17th, correct?

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

No. No, the 17th could be a closed meeting if we\'re going to be
presenting everything on the 20th and having a public discussion on the
20th. So that seems fine.

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

Okay, no need to have another one on the 10th, you think? An additional?

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

It really depends on whether \-- Art is not available, so \-- Marty,
it\'s up to you, if you feel we need to touch base on sort of \-- you
know, generally what the recommendations are going to be, and maybe get
some agreement on the scope of the letter of recommendation. And then,
you know, we can try to do the work, you know, from \-- over the next
two weeks to get a good draft to the group well in advance of the 20th.

I\'m sorry, well in advance of the 17th. I think we\'ll have to shoot to
something done at that point. It\'s a matter of whether or not we need
some working time on the 10th to move that along.

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

Is another day possible, Art? Is there an option for you? The 9th?

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

The 12th would work for me, if you had some time \-- I have time between
about 10:00 and 1:00, my time, which would be 12:00 to 3:00 on the East
Coast. Would that work for you, Marty?

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

I think I can make that work.

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

So the 12th? Any particular time? And I\'m asking the whole group, too.

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

I can\'t do anything on the 12th after 1:00 p.m.

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

That\'s East Coast time?

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

Yes, East Coast time. Sorry.

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

I could start as early as 11 o\'clock East Coast time.

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

11:00 to 1:00?

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

11:00 to 1:00 works.

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

That works for me.

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

Perfect. So I have on the 12th, at 11:00 to 1:00 p.m. And October 17,
2:00 to 4:00 p.m. With the caveat that these are going to be closed
meetings with our \-- with the public being invited to the
Biosurveillance Workgroup meeting, and we present our findings there.

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

That sounds good.

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

Very good. Matt, do we have anybody for comment?

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

No, we don\'t.

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

I think that\'s it, then.

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

Very good. Thank you, everyone.

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

Thank you.

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

We\'re in the home stretch, here.

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

Bye.

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

Thank you, bye-bye.