American Health Information Community

Biosurveillance Data Steering Group

July 7, 2006

10:00 a.m. EDT

**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.*

\>\> Welcome to the Biosurveillance Data Sharing Group meeting. I would
like to begin by just mentioning who we have involved in today\'s call.
On the phone we have Marty LaVenture, Art Davidson, Dick Melton, Daniel
Jernigan, Eileen Koski, Dr. Barthell, Steven Hinrichs, Perry Smith and
Laura Conn.

And on the road here in Washington, the Office of the National
Coordinator, we have Ben Steel, Kelly Cronin and Scott Poser, as members
of the group.

And I'd also like to mention that the public will be given an
opportunity to chime in at the end with comments.

At this time I\'ll have to turn it over to Scott, who will introduce the
Co‑chairs for the call.

> \>\> Scott: Hello and welcome. I\'d like to just introduce Dr. Marty
> LaVenture and Dr. Art Davidson, as our Co‑chairs for this committee.
> We thank you all.
>
> \>\> Kelly: Well, Chris, before we get started, why don\'t we go over
> just some general ground rules for those on the phone so they
> understand their ability to contribute to this. I think you know
> there\'s the option of having the closed line or open line and if you
> could just review the very basics.
>
> \>\> I\'ll make the announcement. Actually everyone\'s lines are
> currently open, and we\'d like to ask that all of the members that are
> going to speak would say their names before speaking so that we can
> have those for the record. The first time you could perhaps say your
> first and last name, and then each other time if you could just say
> your first name or how you would like to be referenced throughout the
> meeting. And again the public will be allowed to speak at the end of
> the call, and we will provide additional instructions at the end
> before we adjourn.
>
> \>\> Kelly: With that, why don't we just turn it over to Dr. LaVenture
> and Dr. Davidson to get us started.
>
> \>\> Marty: Great, thank you. This is Marty LaVenture, and I
> appreciate the opportunity to participate on this call with my
> Co‑chair Art Davidson and we\'ll be sort of passing, I think, the
> chair baton back and forth as we proceed with the meeting today.
> Everyone should have the materials \-- thank you for sending those
> out, Scott \-- with the proposed agenda for today. And, Art, do you
> want to proceed with the first item on the agenda and the
> introductions?
>
> \>\> Art: This is Art Davidson. I\'m from Denver Public Health,
> pleased to be part of this committee as well. We thought we would
> start out by \-- I don\'t know if \-- Marty, if we completed the
> introductions of all. We heard names but ‑‑
>
> \>\> Marty: I think that would be good to go around, that\'s great.
>
> \>\> Art: What would be a good way to start? Alphabetically. So
> anybody start at the early part of the alphabet and can we just kind
> of move down by last name.
>
> \>\> Ed: This is Ed Barthell. \[Inaudible sentence.\] I\'m an
> emergency doc in Milwaukee. My friends think I\'m an informatics geek.
> I\'ve been working with the American College of Emergency Physicians
> on a number of informatics and surveillance issues. I\'m on this
> committee representing the American College of Emergency Physicians. I
> think I\'m representing clinical medicine, where I think I believe the
> other people are representing by various public health roles.
>
> \>\> I\'m (inaudible) one of the HCVE biosurveillance committee.
>
> \>\> I think this committee was supposed to be constituted with at
> least one member. So you\'re that representative.
>
> \>\> That\'s correct.
>
> \>\> Thank you. Any C's or D's? I don\'t have the list in front of me.
>
> \>\> Kelly: This is Kelly Cronin. I\'m not officially a member but
> I\'ll be an ex officio member and stay involved in this group and
> I\'ve been closely involved with the other work of the American Health
> Information Community and in particular the Biosurveillance Workgroup
> over the last 6 months. So I should try to provide some continuity
> between those groups.
>
> \>\> Hi, this is (inaudible). I\'m actually ex officio as well from
> the CDC but on detail to ONC for the next 6 months and will be helping
> to work with this group in the Biosurveillance Workgroup as well.
>
> \>\> Dr. Davidson, how about yourself?
>
> \>\> Art: I\'m a physician. I\'ve been working at Denver Public Health
> for the last 20, 25 years and I work in public health informatics. I
> direct that at the Denver Public Health Department, and I\'m involved
> as principal investigator in one of the arc regional demonstration
> sites for developing a health information exchange in Colorado.
>
> \>\> One of the BioSense developing sites at Denver Health where I
> work.
>
> \>\> Next.
>
> \>\> Dr. Hinrichs.
>
> \>\> Steve: I\'m Steve Hinrichs. I wear two hats. One, I have a
> university professorship at the University of Nebraska. I\'m also the
> director of the Nebraska Health Laboratory. Particular relevance to
> this committee, I\'m the previous Chair of the Informatics Committee
> for the Association of Public Health Laboratories and currently the
> Colead on the data harmonization project which is a collaborative
> effort between the HPHL and CDC.
>
> \>\> I believe Dr. Jernigan, you\'re next.
>
> \>\> Dan: I\'m Dan Jernigan. Trained in internal medicine but have
> been serving as a medical epidemiologist at CDC since 1994 in
> respiratory disease and hospital infections and most recently have
> become the deputy director for the influenza division here in the
> National Center for Immunization and Respiratory Diseases. I\'ve
> worked on various aspects of surveillance integration in the past.
> Have worked on implementation and design of electronic laboratory base
> reporting and development of data standards and served for two years
> as a board member for the health level seven standards group.
>
> \>\> Eileen.
>
> \>\> Eileen: Informatics research at Quest Diagnostics. We\'re
> responsible for managing a large corporate data warehouse of all our
> data. We\'ve been involved in a number of surveillance projects
> jointly with CDC and others. And I\'m here representing the point of
> view of the providers and laboratories in general and conversation
> with ACLA and others to try to make sure that that viewpoint is
> incorporated.
>
> \>\> Dr. LaVenture.
>
> \>\> Marty: Marty LaVenture, Director for the Health Center of Health
> Informatics at the Minnesota Department of Health, and my background
> is in epidemiology and public health informatics. I\'ve been involved
> through also the Public Health Data Standards Consortium and Vice
> President of that group and involved a bit in some of the standards,
> HCVE standards development activity and the Director of the statewide
> e-Health Initiative here with Health Information Exchange as well.
>
> \>\> Thank you, Dr. LaVenture.
>
> Dr. Melton.
>
> \>\> Dick: I\'m currently the Deputy Director for the Utah Department
> of Health. I\'ve been very active with ASTO over the years in
> information exchange. I\'ve been Deputy Director here for about 14
> years. Seventeen years prior to that, I was Laboratory Director for
> South Dakota and Utah, and then all of that, I was very involved in
> laboratory information exchange. So I\'m representing I think ASTO on
> the committee.
>
> \>\> Dr. Perry Smith.
>
> \>\> Perry: Hi. I\'m the State Epidemiologist for the New York State
> Health Department, trained in internal medicine and epidemiology, and
> over the years have increasingly gotten involved with informatics
> issues regarding public health surveillance such as national
> electronic laboratory reporting for public health surveillance. I also
> head up our New York State Public Health Workgroup, working with RHIOs
> and the exchange of clinical information with clinical settings. And I
> also chair the Public Health Informatics Team for the Council of State
> and Territorial Epidemiologists, which I\'m also representing on this
> Workgroup and also sit on the board of directors and work on issues
> with the Public Health Data Standards Consortium.
>
> \>\> I\'m Lynn Steel. I\'m the division director of the division of
> emergency preparedness and response in CDC\'s National for Public
> Health Informatics. My background is health care epidemiology. I
> worked as an epidemiologist in CDC National Center for Infectious
> Diseases. But after the events of 9/11 focused on terrorism
> preparedness and exchange of information between clinical medicine and
> public health. I\'m currently the Division Director overseeing the
> BioSense program.
>
> \>\> And Bill Stephens.
>
> \>\> Bill: Yes, good morning. I\'m the director of the advanced
> practice center here, which is NACHO CDC program here focusing on
> emergency preparedness. I\'m in the north central Texas region here
> and in charge of the development of a large area of biosurveillance
> system here that\'s being utilized by both the State health department
> as well has the four large metropolitan local health departments here
> in north central Texas. Among others, we are working with Lynn and her
> group for the implementation of BioSense here across this region and
> getting a number of our hospitals on the regional network to begin
> reporting into BioSense and we\'re also working with a couple of other
> outbreak detection systems as well in the area of syndromic
> surveillance.
>
> \>\> Scott: Very good. Just so you know I am. I\'m Scott Holter, a
> laboratory technician by trade for Bearing Point. My particular
> background is I do, I\'m an expert in Wellington and SNOMED coding. I
> sit on the HCVE panel as part of the e-Links Technical Workgroup, so
> I\'m very well aware of the standards going on. So thank you and
> welcome.
>
> \>\> Marty: This is Marty, and thank you everyone for the brief
> introduction as we get acquainted with the voices of everyone on the
> phone. We appreciate your noting who is speaking and appreciate
> everyone\'s really commitment to this I think very important effort.
>
> In the agenda today, Scott, is there any additional procedures or
> ground rules for the meetings that we need to cover?
>
> \>\> Scott: No, sir.
>
> \>\> Marty: I think we\'ve covered them. Basically if they come up as
> we move along we\'ll try to identify those and make sure they\'re
> clear to everyone.
>
> One of the key objectives on this meeting is really three key areas,
> and that is what we hope to achieve in the rest of the time on the
> phone call is common understanding of really the scope of the work
> that we\'re charged to do. That includes the context of which this is
> coming from.
>
> From the AHIC committee as well as the HIT Standards Panel. And what
> will be our respective role with regard to that effort.
>
> So I would hope that we can come to that common understanding. We can
> review what our particular role is, and then spend some time focusing
> on both how are we going to approach the addressing the issue of the
> common dataset and what is that minimum dataset that we need to
> address.
>
> Art, do you have anything to add to the meeting objectives for today?
>
> \>\> Art: Well, I did want to just kind of open it up a little bit to,
> since we do have a representative from the ‑‑ we felt we needed to be
> aware of as we start to set the agenda for the rest of the meeting.
>
> \>\> Marty: Art, I lost part of the statement there. Is it possible to
> repeat that? Did anyone else lose that?
>
> \>\> Yes, Marty. We lost you again.
>
> \>\> Art: I\'m here again. There\'s an awful lot of background noise.
> Nothing in my area just on the phone. I was going to say as we start
> to set the agenda I wanted to be sure since we do have someone on the
> call from HCVE, ask Ed if there\'s something that we should add to
> this agenda.
>
> \>\> Ed: I can respond by saying there has been some frustration, and
> I think it\'s okay. It\'s a healthy frustration that HCVE has had just
> because we\'re all trying to move parallel tracks on this whole
> process this year. But when you get a group of standards people in a
> room, they want to have a very well defined focused goal in front of
> them. And sometimes they felt like it\'s a little bit of a moving
> target, the HCVE Surveillance Group. We have this unified use case
> that we\'ve been working off of. But have also been faced with some of
> the realities that we\'re trying to develop systems that are going to
> be able to roll out this year as maybe an interim step on a broad
> basis and trying to balance that against maybe the wished for long
> range systems that are going to be more robust or structured. And so
> that\'s been a struggle at HCVE is to get a good sense of what our end
> goal is.
>
> \>\> Marty: Discussion. I think that\'s important context. And in fact
> our next key item is to make sure that we fully understand the context
> in which we\'re proceeding with our part of this work. And I think,
> Ed, that HCVE context should be very important in that as well. Art,
> did you have another piece?
>
> \>\> Art: No, that\'s fine. I just wanted to be sure that we did get
> that contextual piece here as well. This should move on for a little
> while and have Kelly fill us in maybe a little more about the
> background.
>
> \>\> Kelly: Sure. I think it\'s probably important to note that the
> initial broad and specific charges were set by the American Health
> Information Community, and the Secretary several months ago that
> guided the Biosurveillance Workgroup initially in its work. And in
> your handout materials, or the links that were sent to you, these
> charges were specified. So if you have anything in front of you, you
> can refer to the background and option briefing on the minimum and
> target data elements. So the broad charge to the Biosurveillance
> Workgroup was to make recommendations to the Community to implement
> the information tools and business operations to support real time
> nationwide public health event monitoring and rapid response
> monitoring across public health and health care delivery communities
> and other authorized government agencies.
>
> So starting off in January and February, this subcommittee or what
> we\'re calling a workgroup under AHIC, was given this charge, but was
> told initially to focus on the specific charge, which is to make
> recommendations to the Community so that within one year essential
> ambulatory care and emergency department visit and utilization of lab
> result data from electronically enabled health care delivery and
> public health care systems can be transmitted in a standardized
> anonymized to authorize public health agencies within 24 hours.
>
> So that charge was really the focus of not just the Biosurveillance
> Workgroup but it translated to a much more detailed use case that was
> prepared based upon input from a variety of groups that are working
> with the Office of the National Coordinator.
>
> So those groups include the Certification Commission for Health
> Information Technology, the Health IT Standards Panel that we just
> heard about, along with the Nationwide Health Information Network
> Consortia. So they proposed their own use cases that get into a much
> greater level of detail about you know what are the exact processes,
> what\'s the work flow, what are the events, what are the public health
> high level data elements that would be necessary to meet this specific
> charge or to be consistent and in alignment with this specific charge.
> So from that point on the office of the national coordinator tried to
> take all of those different inputs and come up with one common use
> case for biosurveillance based on this very narrow, specific charge.
>
> So really, again, trying to focus on essential ambulatory care and
> emergency department visit utilization and lab result data. From the
> parts of health care that we now are already electronically enabled
> and could automatically transmit data within 24 hours to public
> health.
>
> So as the Biosurveillance Workgroup started to get into their work,
> and have some public discussions around this, it became evident that
> there\'s not only a lot of complicating factors with what\'s
> realistically, can we capture in the short‑term, but there\'s also a
> certain level of concern around sharing data across jurisdictions,
> across local State and Federal jurisdictions in a real time basis.
>
> We did in the end, you know, in presenting recommendations that were
> expected by the American Health Information Community and the
> Secretary we did get to a point where there was an agreement on how we
> could achieve a biosurveillance effort that would allow for the
> sharing of data across jurisdictions in real time.
>
> And one of those conditions was to have a much more detailed
> determination of what exactly are the data requirements, what is
> necessary to get from emergency departments, from labs, both clinical
> and reference labs and public health labs, and also from ambulatory
> care to the extent feasible.
>
> So there\'s a lot of back and forth about what would be the right
> dataset to start off with, and the process that initially was started
> and completed by the Biosurveillance Workgroup involves the careful
> evaluation, examination of data elements across four existing
> biosurveillance efforts. And those programs included the New York City
> Biosurveillance Program. North Carolina. Their State-level
> biosurveillance effort. The front line initiative that Ed Barthell has
> been involved with, more emergency room focused as well as the
> BioSense program.
>
> So based on those four programs, what they\'re currently capturing and
> a series of assumptions around what public health functions we were
> serving, there was a minimum dataset that was derived and discussed
> that included both the minimum data elements at a high level and also
> target data elements. And there was a discussion between those and
> they got to a point where there was agreement, not unanimous consent,
> but there was a basic agreement that those data elements were
> accessible based upon, you know, the public health functions and the
> scenarios that were presented.
>
> I think that it\'s now understood that if we are talking about sharing
> data across jurisdictions, and we\'re wanting to serve public health
> functions such as situational awareness and outbreak management that
> we need to have now a more focused view of what are the specific data
> elements and try to develop a process for their workgroup, for this
> group to follow, the data-steering committee to follow, to identify
> what is currently missing from the data elements that have been
> already identified at a high level and try to allow for the health IT
> standards panel to understand what might be currently missing so they
> can take that into account as they continue their work. But that we
> also have time to consider refinement of that list.
>
> So if you refer to the draft Scope of Work that we put together, and
> have already reviewed at least with the Co‑chairs, the functions lay
> out basic steps we need to consider in coming up with a process that
> everyone can live with and gives us some clear sense of what we need
> to do for the first step and ‑‑
>
> \>\> Kelly, I\'m sorry to interrupt, but there\'s interference on your
> end so you\'re coming and going a bit. I don\'t know if there\'s
> anything you can adjust there.
>
> \>\> Kelly: Please let me know when you can\'t hear and I\'ll repeat
> myself. We\'re trying to fix things on this end. Can you hear me okay
> now?
>
> \>\> Yes.
>
> \>\> Yes, that\'s better.
>
> \>\> Kelly: Okay. So again getting back to the draft Scope of Work,
> and really this is just a rough draft of a document to try to help us
> organize our thinking and our process so that we have a common
> understanding of what we need to accomplish and we can work together
> to agree on you know what are the steps we should be considering over
> the next 2--3 months and what do we need to be providing in terms of
> recommendations to the Secretary.
>
> So as you see, starting off with Step 1, we want to, you know,
> obviously have some clear understanding of the assumptions that we\'re
> working with so based upon the biosurveillance use case and the public
> health functions that we agree that we need to be serving, such as
> situational awareness. That we would identify the data elements that
> have not previously been identified by the Health IT Standards Panel
> Technical Committee or the AHIC Class Workgroup. So that\'s a first
> step for us to start with. The second one then could be the
> consideration of the data elements and what has been identified as a
> minimum dataset by the Biosurveillance Workgroup that really are not
> necessary for biosurveillance as the data-steering group is currently
> thinking about it. So according to the public health functions that we
> think are most important to meet, what data elements really are not
> necessary. And based upon refining what data is really needed, we
> would then have to consider what would be the necessary filtering of
> that data. So those from a confidentiality perspective or sensitivity
> perspective what might we not absolutely need to share with public
> health, given some of the high level sensitivity around certain data
> elements, or from just a value perspective, what lab results, for
> example, might not be absolutely essential for public health. We
> don\'t want to necessarily want to say all lab reports have to be
> reported to a State and local and Federal jurisdiction, but what
> subset of labs are most important for public health or for
> biosurveillance in particular.
>
> And the fourth step that we\'ve talked about here and with the
> Co‑chairs is to take what we\'ve tried to identify as what\'s really
> needed for public health and biosurveillance and do a feasibility
> assessment of what can we really do in the short‑term, what can we
> really capture in the short‑term versus the midterm and long‑term, and
> how might we plan for what could be implemented in the next year
> versus subsequent years.
>
> So that\'s an initial attempt to try to create some sort of process
> for us to follow but again this is a proposed way to handle this and
> we\'d like to get your input on what you think is reasonable and would
> allow us to move forward in an organized way.
>
> I also wanted to specify that when the recommendations were put forth
> to the American Health Information Community and the Secretary to
> establish this steering group, we hadn\'t necessarily clearly
> identified it as another subcommittee or working group under AHIC or
> under AFACA in general, although I think the Department has realized
> how important this issue is and you know we feel it\'s important in
> particular to have an open and public process so that our
> deliberations are transparent and that if members of the public do
> want to weigh in on anything that\'s being discussed, they have the
> opportunity to do that in any of our meetings that involve important
> delivery.
>
> So in the end we decided to add this under the American Health
> Information Community. We will have an opportunity to discuss what
> this group recommends with Dr. Gerberding and Chip Kahn, Mitch Cobb,
> who are all Co‑chairs of the Biosurveillance Workgroup, and there will
> be an opportunity for those workgroup members to consider our
> recommendations prior to advancing them to the Secretary and the full
> committee.
>
> So there\'s an awful lot of work that needs to be done, and I think
> between myself and Judy Sparrow, our new director for the American
> Health Information Community we\'ll do our best to make sure there\'s
> good communication going to all of you about what\'s happening with
> the Biosurveillance Workgroup. They are now moving to the broad charge
> that I talked about before. So they\'re really taking on what can be
> prioritized with real-time public health event monitoring as we start
> to build the Nationwide Health Information Network and we have
> subsequent use cases going to the Health IT Standards Panel and the
> certification commission.
>
> So they\'re moving, and looking way into the future how we build the
> infrastructure of the future to meet public health needs. But for this
> particular group now we really are focused on what, at least in the
> short term, what should we really do with biosurveillance and what can
> we all agree on in the way of specific data requirements.
>
> \>\> Ed: This is Ed again. If I could respond just briefly. First of
> all, thank again for those comments, because I think you\'re
> navigating somewhat difficult job here trying to balance the interests
> of the local and the Federal agencies, and that wasn\'t real easy in
> some of those calls with AHIC earlier that I was listening in on. I
> think the temporal component is the key thing that\'s caused some of
> the stress, because even though we\'ve got this use case we\'ve
> addressed at HCVE, part of the tension is that we\'re hearing some
> very public comments by the Secretary and others about the importance
> of rapid breakthroughs and having all the ERs in the country linked
> over the next year and yet balancing that against the realities of
> trying to put in a much more structured maybe long‑term desirable
> system. And so I think maybe if we can try to go through these data
> elements in terms of what can we achieve say over the next year versus
> other things that we want to achieve but maybe over a longer time
> course, say 3 years or 5 years, it might help settle things out a
> little bit, just trying to balance the practical realities of getting
> some of these systems in place and getting some short‑term benefit,
> even if we\'re working toward a broader long range goal.
>
> \>\> I think that\'s actually a perfect comment for explaining some of
> the confusion that exists now and I think that a lot of people
> throughout HSS are involved in this area really do understand the
> realities and the challenges. And I think for this group to be
> grounded and understand what is realistic within the next year, but
> also have a focus to what could be accomplished as we move forward and
> we do have more infrastructure to work with, it would be very valuable
> to have as you say that temporal sequence. And would provide I think
> enable a much more rational discussion at a higher level, too.
>
> Did everyone hear what I just said?
>
> \>\> Yes.
>
> \>\> No.
>
> \>\> Sorry for the technical difficulties today. We\'ll make sure by
> the time we get on our next call we\'ll have worked them out.
>
> As I say ONC is in a relatively new office. We have new more
> sophisticated equipment in our conference rooms yet we seem to have
> consistent technical difficulties. So our apologies. But we\'ll try to
> get that worked out.
>
> For those who didn\'t hear me, I just wanted to say that Ed\'s
> comments were right on and I think that it will be really helpful for
> this data-steering group to identify both the short‑term requirements
> that are realistic as well as think about what we can accomplish in
> the mid-to-long term as we have more infrastructure.
>
> \>\> Art: I don\'t know if there are any comments from the group in
> general about the Statement of Work that Kelly has referred to and the
> discussions so far.
>
> \>\> Terry: This is Terry Smith. Can you hear me?
>
> \>\> Art: It\'s a little faint.
>
> \>\> Terry: Can you hear me now? I\'ve got an echo on my end. Are you
> able to hear me?
>
> \>\> Yes, we can.
>
> \>\> Terry: I just had a couple of comments. One was the Scope of
> Work, I was unable to download. So I don\'t know whether that\'s been
> distributed electronically to the group.
>
> \>\> Kelly: Yes, it was. Although it really is just a draft document
> and really the most important part of that I tried to work through in
> our comments. It was really sort of talking about the steps that would
> guide our workgroup process.
>
> \>\> Terry: My other comment or question is that in your description
> of our charge and Scope of Work, you mentioned our trying to define
> data elements for then detection of situational awareness and I think
> you mentioned outbreak management. And it brought to my mind the fact
> that what we need to collect in terms of data is obviously driven by
> what we\'re going to use the data for. And those three terms that I
> just used kind of conjure up slightly different data needs in my mind.
> So my question is whether there is a fairly explicit definition of
> what the data will be used for, because I think that will help us all
> be on the same page as to what we would need to collect as a minimum
> dataset.
>
> So I was wondering if there\'s any definition, fairly specific, of the
> goals of the data for this first year or for this first pass.
>
> \>\> Kelly: That\'s a great question. We, I think ‑‑ I think the
> steering group is really charged to get their own definition around
> what they think the data should be used for. But I think in a previous
> conversation with the Co‑chairs, and based upon what we heard over the
> last few months from the Biosurveillance Workgroup, since there\'s a
> pretty significant concern about the appropriateness and you know
> under what situations do you have simultaneous data flow across
> jurisdictions, we wanted to make sure that everyone was comfortable
> with agreeing on a definition that would have public health functions
> that would be consistent with cross‑jurisdictional data flow. So, for
> example, if we know that an outbreak has gone beyond a local
> jurisdiction and maybe even beyond a State and is in several States,
> then there\'s a need to do outbreak management across many
> jurisdictions.
>
> For situational awareness, we want to be able to track what might be
> happening across a region of the country, then there would be a reason
> for you know cross‑jurisdictional data flow. So I think we need to be
> mindful of what has been agreed to and if one of the assumptions is
> that we need to be thinking about public health functions that are
> consistent with sharing data across jurisdictions, then perhaps the
> steering group could start off by trying to agree on what exactly
> those functions are.
>
> \>\> Art: Thank you.
>
> \>\> Marty: Are there questions for Kelly in terms of back ground or
> other context you\'d like to add relative to the work here today?
>
> \>\> Art: I have a question. This is Art. I was scanning the
> biosurveillance data matrix that you sent out. Who defined what ‑‑
> what is the term \"minimum\" versus target mean and is that one
> defined? We may need to spend a little time defining some terms here.
>
> \>\> Kelly: Just to respond to the latter part of your comment first.
> I think there\'s been a lot of confusion in general with many of the
> public discussions we\'ve had on this subject. One thing that would be
> incredibly useful to put forth in recommendations as we move forward
> is a nomenclature or glossary so we can all speak the same language
> and then ask, you know, the Biosurveillance Workgroup to adopt that
> and we\'ll all have sort of a common understanding of what we\'re
> talking about.
>
> Because even when we\'re getting down to describing data requirements
> or data elements, there\'s various ways we could be, you know,
> detailing that or describing various levels of granularity. So that\'s
> just sort of FYI. Something we probably should be mindful of as we
> move forward.
>
> And if Laura Cline is on the line it might be easier for her to
> explain how the minimum and target dataset was derived or what they
> represent.
>
> \>\> Laura: Sure. I think our approach was to in the workgroup process
> was to define the functions which Kelly has talked about and the only
> one that I don\'t think we\'ve talked about yet today is response
> management as well as outbreak management.
>
> And then to think of scenarios and think through some scenarios and
> determine what data elements would be helpful in answering some of
> those scenario questions. And then we looked at the four ongoing
> biosurveillance projects that Kelly described. And then we tried to
> look across those projects and look at our specific charge and come up
> with minimum. And out of that, when we were doing that, we looked at
> some of the elements that some of the four projects we\'re collecting
> as well and thought, you know, that would be really nice to get if it
> was easy to get. And doable. But let\'s not consider that in the
> minimum, so let\'s put that in the target. So I wouldn\'t say the
> target is all inclusive of everything public health would ever like to
> get, but it was more an outgrowth of looking across some of the
> existing systems, thinking they were nice but not necessarily needed
> to address the specific charge in the first year but if they were
> available and easy to get might be useful.
>
> \>\> Marty: Thank you, Laura. Getting back to the question that was
> asked a little bit earlier, now that you brought up the response as
> well, is there a starting definition that you had been working with
> before for the four areas that we should be looking at, event
> detention, situational awareness and outbreak management? Does FIN
> have those, Lynn, within BioSense, do you have those defined?
>
> \>\> Lynn: We have working definitions of situational awareness, which
> encompasses all of those, it encompasses the use of the data for
> outbreak management and response management. We can share those. I
> don\'t have it with me.
>
> \>\> Marty: Okay. I\'m just kind of thinking through about what we
> might be looking toward. Are these target data elements different for
> the four and should we be creating a matrix that allows us to look at
> which ones we\'re going to do for those, of those four target
> activities.
>
> \>\> I think that would be a useful exercise. But I think the
> definitions we\'ve had before are pretty broad and high level and it
> would probably be ‑‑ we would want to get to more specific definitions
> in this Workgroup.
>
> \>\> Marty: Thank you.
>
> \>\> Kelly: There\'s also the possibility of having a working
> definition of situational awareness that encompasses both outbreak
> management and response management. But it\'s a separate consideration
> to consider initial event detection and scope. So it might be helpful
> to get feedback from the members on whether or not that should be in
> or out of scope.
>
> \>\> So our task was not to cover all four items mentioned in the
> first paragraph of Statement of Work, or are you now asking us to
> confirm which of those we want to work on?
>
> \>\> Kelly: I think it would be best for you all to come up with your
> own determination of what you think you need to serve, or what are the
> needs that need to be met.
>
> \>\> Marty: Any comments from the members?
>
> \>\> Bill: I can tell you we\'re looking at this on a consolidated
> basis because regardless of which phase you\'re looking at there are
> sort of overlapping or areas of commonality that can be used and that
> are being used even, I mean even with the area that we\'re working on
> in primarily outbreak detection at this phase, as we\'re folding in
> the BioSense implementation here, we\'re seeing a lot of opportunities
> for, you know, sort of consolidation and effort and sort of especially
> as regarding the expansion of the data pipe here and what, and making
> the different data elements feasible as far as the hospitals and the
> other data sources that we\'re looking for. So we want to use this
> data as, I guess you\'d say as smartly as possible. And so I think, at
> least the way we\'re looking at it, we\'re looking at this in more of
> a consolidated perspective.
>
> \>\> Art: I want to get back ‑‑ this is Art again. I want to get back
> to one of Ed\'s comments here what\'s feasible in the short‑term. And
> while BioSense is, if you look at the data matrix is sort of a
> comprehensive list here, is that feasible in the short‑term for us to
> think about regarding health information exchange and RHIOs around the
> country? I totally agree with you, Bill, that it\'s good to think of
> this in the comprehensive sense. And I think that\'s where BioSense
> started. But is it that this group in the BioSense use case is
> expecting to be able to put forth BioSense, or are we looking at steps
> towards biosurveillance?
>
> I don\'t know if I\'m being heard.
>
> \>\> Kelly: You\'re being heard. I think it may be the later. The
> determination is the short‑term goal is to have standards that can be
> implemented broadly across the country in a very short time period.
> There probably is a dataset.
>
> \>\> I think that\'s right. I think we\'re not necessarily ‑‑ we\'re
> really focused on not necessarily one program anywhere in the country.
> We really want to figure out what really can be the requirements that
> would work for everyone. Ideally. I mean in a program that would be,
> again, involving the sharing of data across jurisdictions.
>
> \>\> Eileen: I have a question about the requirements and the
> implementation of this. Because I want to be sure that I\'m clear
> about whether we\'re discussing right now what minimum data, in terms
> of the minimum dataset, what are the data elements we really want
> versus what is the mandate for the data providers, because I know, and
> I don\'t want to get into specifics right now, but I know, for
> example, looking at some of the elements and the minimum dataset, they
> don\'t exist in our ‑‑ and I\'m thinking about things that apply to
> laboratory. Not just the stuff that doesn\'t apply to us. So if a
> provider is being asked for data that they don\'t have access to
> provide, what is the expectation, or is that a completely separate
> discussion and something that we\'re sort of putting aside for a
> future topic?
>
> \>\> What I mentioned before as the potential step for what\'s
> feasible given the realities of current reporting burdens or as you
> say mandates, you know we can take all that into account once we have
> identified what\'s really necessary for public health first.
>
> Again that\'s a proposed approach and we want your input on what\'s a
> good process.
>
> \>\> Lynn: I also think we need to learn from the experience of
> BioSense, which of the data elements that are listed here are easy to
> get or would be able to be implemented broadly, quickly. And I think
> we have enough experience now with 20 health systems and the hospitals
> to be able to inform these discussions that probably wasn\'t possible
> several months ago.
>
> \>\> Was that Lynn?
>
> \>\> Lynn, I think it would be helpful for us to get an idea even
> though on this data elements matrix, just about everything fills in
> for BioSense really what is practical in the hospitals and systems
> that you\'ve worked with so far. Where they you know it\'s for
> instance in my institution, we don\'t do all the X's. We\'re trying to
> get some of them, and you\'ve been very accommodating for that. But it
> would be helpful to know what\'s the likely elements you would get
> from those hospitals.
>
> \>\> Lynn: Right. And the fact that this document is dated is quite
> telling. BioSense specification guide has evolved. Since February,
> certainly. And having, just as an example, the occupation of someone
> presenting for health care. Every health IT system has that as a
> field. That was not made up. But it\'s not filled in. So is that
> important data? And as we think about connecting existing systems no
> one is getting that data. And even as we make a place for that in a
> biosurveillance program, you just anticipate that it could be
> important to public health and would be utilized in an event. So you
> establish a place for that message to be transmitted, or do you just
> say this isn\'t a data element that\'s used?
>
> So I think again we can talk through a number of those.
>
> \>\> Bill: I don\'t have a copy of the matrix you\'re referring to.
> But I\'ve actually built one here in our team that we\'re using really
> in three different ways. We have, we\'ve actually developed a proposed
> consensus, what we call a proposed consensus dataset across the area
> health departments and in conjunction with some of our hospital
> partners. We\'ve compared that in a matrix to what our current
> regional surveillance dataset looks like. In the third column we\'ve
> compared it to the BioSense data requirements. And it\'s very telling.
> The one that\'s the consensus dataset is one we put together here in
> north central Texas area that we believe contains what you would say
> easily available or readily available data that we can get from
> hospitals and other data sources. And I\'d be willing to pass that
> along if you think it would be useful in at least establishing one
> data point here for comparisons.
>
> \>\> Scott: Bill, this is Scott. You should have those links on the
> bottom of the agenda.
>
> \>\> Bill: Okay. I missed that.
>
> \>\> Scott: They should be hyperlinked right to the pages.
>
> \>\> Bill: I\'ll go back and check that.
>
> \>\> Scott: Let me know if you don\'t.
>
> \>\> Bill: Okay.
>
> \>\> I think that would be helpful Bill if you could share that with
> the group and we can take a look at what\'s happening on the ground
> level.
>
> \>\> You bet.
>
> \>\> As you might expect it\'s a significantly smaller dataset than
> what\'s contemplated in BioSense, but I\'d be interested to see how it
> compares, and I\'ll go ahead and download that and see how it compares
> to this target dataset and the minimum dataset here that\'s specified
> in the attachments there.
>
> \>\> Lynn: And Laura can chime in, but I think in some ways there are
> going to be data that are incredibly important to public health that
> aren\'t necessarily easy to get yet, because they\'re not
> standardized. Or not standardized enough. And specifically laboratory
> data. So I really do think we have to keep considering the specific
> charge as we make these deliberations as well. Because by ensuring
> that they\'re part of this minimum dataset, then we\'re driving
> towards the implementation of those standards to make it easier for
> really important data to be transmitted and useful.
>
> So I think there really does have to be this balance. Laura, can you
> say that in a ‑‑
>
> \>\> Laura: I totally agree with you. And over the last 5 years or so
> and the emergencies du jour, at least at the national level and
> certainly the State and locals have much more experience in local
> investigations, we have seen the need, more and more the need for some
> of these data that are hard to get and certainly not available to be
> turned on and passed on to public health easily and during an
> emergency. And I think this is an opportunity for us to help drive
> that, recognizing, you know, we need to determine what we can do in a
> year\'s time and what we can do farther out.
>
> I don\'t know, Dan Jernigan from CDC has been involved in some of the
> responses as well, if you want to chime in.
>
> \>\> Dan: I agree that improved standardization would be great. It\'s
> just working it through at the detail level is the hard part.
>
> [\>\>]{.mark}
>
> \>\> Kelly: Marty, I have a suggestion. I think it might be helpful to
> have this group be clear on the sort of working assumptions for what
> we have to accomplish. And maybe going back to this concept of having
> a real definition of, you know, the public health functions that we
> need to serve would be helpful, and try to sort of create sort of the
> set of assumptions that we should all be clear on before we get into
> perhaps a more detailed discussion on what exactly, what data is
> needed.
>
> \>\> You mean getting back to the four definitions?
>
> \>\> Kelly: And any working assumptions you think we need to really
> have sort of a cohesive conversation around this.
>
> \>\> Marty: How does that sound to the Workgroup? Or are there other
> elements that we need to define here, these assumptions that, as
> someone mentioned earlier, getting some nomenclature or glossary for
> the group to be able to refer to.
>
> \>\> I think it\'s a good idea.
>
> \>\> Barry: I agree. This is Barry.
>
> \>\> Dick: I agree.
>
> \>\> Marty: How might we start that? Is that something that ONC can
> begin the process for us? Do we need to deliberate here on the phone
> about this? Should we pull up some of the definitions that may be
> embedded in BioSense or elsewhere? What would be some proposed methods
> for us to start this? Kelly, any ideas?
>
> \>\> Kelly: Well, I think we certainly have some definitions from some
> existing programs we could draw from. For example, I think Lynn
> already mentioned there\'s a working definition of situational
> awareness from BioSense. Before, when we\'ve talked about data
> elements, we\'ve discussed them both at sort of a high level and then
> recognizing that there\'s, you know, a much more detailed level that
> we need to discuss data or have terms for the way we describe data.
> For example, when we get to specific laboratory values or results that
> would be at the code level, for example. We need to just be clear on
> what we want to call that, what type of data, or how do we describe
> that data at that level, versus, for example, if you look at the draft
> minimum and target data elements, one of the documents that was
> hyperlinked in our agenda we have a higher-level description of data,
> the category starting off with institution data so one way of
> describing sort of a high-level data element is the hospital system,
> the main facility or ID or name, the location address and the number
> of facility beds. So I think it would be helpful to maybe have a
> conversation of just how do we want to be talking about data at a high
> level and a more granular level and perhaps get some agreement around
> that today.
>
> In the interim, we can try to pull any working definitions that we
> might have available internally from HHS or CDC, also have some of the
> Workgroup members get back to us off line.
>
> \>\> Ed: Kelly, at the HCVE level, we parsed out on the use case
> somewhat into two main categories, one being for situational awareness
> really specifically about resources. And resource availability and the
> other being more clinical event detection or clinical event
> assessment.
>
> Because they seem to be two different sets of data that don\'t
> necessarily overlap that much with one another. And the standards for
> those two types of data are certainly very different from one another.
> So we did not have, and we ended up breaking it out into different
> building blocks, trying to split those two, or make that distinction.
>
> The other thing I guess I wanted to mention, maybe it\'s certainly
> appropriate if you want to say it\'s just out of scope. But one of the
> other concerns is the use case did not have surveillance in the
> context of what I consider a communication system. I like to think of
> surveillance as not just a one way data flow from clinical medicine to
> public health but rather as an interactive communications system. And
> there wasn\'t necessarily any capability in the way the use case was
> structured for talking at all about messaging back from public health
> to clinicians or for having maybe some kind of a flexible query
> structure that goes back to clinicians when you include response
> management in our spectrum of work that we\'re trying to accomplish
> here, I think it\'s very difficult. Sometimes we\'re going to have
> situations occur where you need to ask questions or query for data and
> it\'s going to be on a topic that we can\'t predict in advance. I mean
> if you think about SARS and asking if you\'ve got patients in your
> emergency department that came from specific areas of Asia, we\'re not
> going to have a standards set up to do that in advance.
>
> So you really need to have a flexible query capability in the broader
> solution, I think.
>
> So I don\'t know if you want ‑‑ if I\'m opening a can of worms,
> that\'s fine we can narrow back down our scope. But I think that\'s
> what\'s not addressed with this structured data approach.
>
> \>\> Kelly: Good observations. I think the subsequent use cases will
> very likely incorporate biodirectional communications, since it\'s so
> essential. But starting off we wanted to do something that we know
> was, that was realistic and something that would be able to be
> implemented in the next year or so. I mean obviously biodirectional
> capacity or communication is happening out there in many instances.
>
> I think it would be helpful to stick back to the specific charge in
> terms of trying to identify the scope of data elements or data
> requirements. But not lose your thought in terms of what do we need to
> be thinking about in terms of trying to identify all potential data
> elements that might be necessary for the public health functions we
> agree on.
>
> \>\> Or maybe when we look at the data elements, specifically look to
> see if they could be altered during an emergency event. And there\'s
> examples of this during Katrina, where one of the hospitals asked the
> physicians to write the word "Katrina" in the chief complaint, because
> we\'re working with a lot of free text data. So, no, it\'s not
> standardized. It\'s text parsing at the user end. But as you think of
> these kind of scenarios, I think we can look at the existing data
> elements and see how they could be accommodated for specific emergency
> functions.
>
> Is that kind of what you were referring to?
>
> \>\> Sure. It\'s being able to be adaptable to the situation of the
> day, and my only concern is if you drive too hard for completely
> structured approaches, you don\'t have that flexibility you need.
>
> \>\> Marty: So in a sense that becomes one of our assumptions to our
> model, perhaps, is that how we could look at this as a model, the
> assumption may be we are starting what we can collect in one year but
> there are some components to the implementation that would be
> important such as the flexibility to either query or to add elements
> as necessary in specific functions, as specific functions are needed.
>
> \>\> I should add there are ways to do that within a standard
> structure. And in the have specification that grew out of the
> (inaudible) project, I\'m not sure how much you know about Steve
> Cantrell\'s project. There are specific data elements that are just to
> be named. Additional resource within an associated descriptor that
> says what that resource is. So essentially the structure is set up to
> be able to be flexible. But it may be that one of the data elements on
> our data element list is data element yet to be named or future data
> elements.
>
> \>\> I think that would be worthwhile for us to capture as an idea, as
> a recommendation back. We may not be able to specify at this point
> other than it\'s leaning toward that flexibility you described
> earlier.
>
> \>\> Perry: This is Perry Smith in New York. Can I bring up another
> area of possible discussion?
>
> \>\> Yes.
>
> \>\> Perry: I haven\'t gone through all of the documents maybe some of
> this is addressed in it. But one area that I\'m wondering about is to
> whom the data will be accessible? And this raises patient
> confidentiality and security issues. We\'re talking about sharing data
> across jurisdictions. We in New York have been wrestling with this
> because in the greater New York City area, we\'re talking about a ‑‑
> we actually have developed an outbreak management system where we
> would be sharing line listed clinical de-identified data with New
> Jersey, Connecticut, New York City, counties around New York City, et
> cetera. And the question arose ‑‑ let me say that the data obviously
> comes from providers and hospitals. And the hospitals have an interest
> and a stake in seeing some of this data. At least seeing their own
> data. But they were concerned about seeing regional hospital data and
> other hospital\'s data so they can get a better idea of what\'s going
> on and obviously surge issues arise. So the whole question of to whom,
> who is going to see this data, was raised and presented a fairly large
> challenge in terms of differential, deciding differential access to
> different elements.
>
> So my question is whether that should be part of our discussion or
> should we just assume that the only people we\'re talking about having
> access to this data is bona fide public health officials.
>
> So I think there\'s an assumption there that we want to make or we
> need to address if we don\'t make an assumption.
>
> \>\> Kelly: I can tell you what our previous assumptions have been. We
> have considered that the only people that would receive this data, and
> potentially act on this data, would be authorized public health
> agencies.
>
> So we have restricted sort of our scope in terms of the other, you
> know, Biosurveillance Workgroup and they had discussions to date to
> really just data going to authorized public health agencies.
>
> \>\> Perry: I think that\'s fine. It does ‑‑ I think somebody
> mentioned this a few minutes ago. The biodirectional flow of
> information will come up and the providers of the information will
> find, you know, that kind of an assumption not completely to their
> liking but as a starting point that definitely simplifies the
> discussion for us.
>
> \>\> Eileen: I think in terms of the biodirectional information, I
> think not to their liking is one way of putting it, but a lot of it
> just has to do with the capabilities of systems. And I think most of
> the systems that we\'re looking at that are sending data are just not
> capable of accepting inquiries like that, but perhaps one of the
> things we might want to consider is the small adjunct to the minimum
> dataset that\'s essentially a contact dataset, that when you get a
> whole file from an organization should there be follow‑on questions
> about it? What are the entities you would contact to pursue that with
> for the near term solution, assuming that the ability to actually
> electronically directly query is sometime away.
>
> \>\> Lynn: Going back to Dr. Smith\'s point, this idea of who will
> have access, it\'s not even in our view I think public health agencies
> but rather identified users within jurisdictions or within those
> public health agencies. So that the appropriate people should have
> access can act on the information.
>
> \>\> Art: Maybe I\'m presuming something here but it would seem that
> the public health agencies would have the responsibility to review all
> the data and figure out, I don\'t know that they would be sharing line
> listings, but more some sort of aggregate data analysis and summary to
> say these are the steps that you might take in your environment, which
> is not the detail that I assume you were talking about in the greater
> New York area.
>
> \>\> I agree, when I mentioned two‑way, that\'s exactly ‑‑ you\'re
> hitting it on the head. I think what you want to do is be able to give
> clinicians feedback so if you\'re asking them to take the step of
> submitting their data in return you\'re going to say, gee, you know,
> you\'re not looking at line item data but we\'re seeing an outbreak of
> salmonella, keep an eye out for it, or whatever the scenario is.
>
> \>\> Are we talking about building that capability as part of the
> biosurveillance activity that we\'re talking about, or referring to
> the add on system that would do that, the health alert networking
> function, or another way? Not putting it into the biosurveillance
> development, but ensuring we\'re capturing that there has to be this
> capability for two‑way communication.
>
> \>\> Ed: I\'m comfortable referring to the importance of that being
> part of the system. Because it helps to sell to the providers why
> they\'re submitting data.
>
> \>\> Right.
>
> \>\> Eileen: You might say a minute or two the capability through
> BioSense that providers have to see some of the data that they\'re
> providing now. Not to say that we think this has to be the
> functionality of this broader biosurveillance effort, but perhaps
> could be in a separate system.
>
> \>\> Kelly: Yeah, one of the benefits to the health care system and
> joining BioSense or being part of that, is that is they can see their
> data. So they are authorized users as well. And it becomes even more
> powerful when it\'s at the health care entity level where there might
> be 10 or more hospitals where they can then do comparisons across
> their facilities or their outpatient clinics or what have you. And so
> to provide this platform for that use has made it a lot easier to get
> interest from the hospital communities, specifically the hospital
> epidemiologist, the infection control community, the emergency room
> department physicians.
>
> So it\'s not the use of the data in BioSense is not just the direction
> of providing that health care data or subset of health care data to
> public health, but allowing the hospital to also be able to see what
> public health may be knocking on their door for, or to become a more
> active participant in looking for issues that might be of public
> health significance.
>
> \>\> Perry: Just to explain a little bit more. Hospitals were not
> asking, I don\'t believe, for line listed data from other hospitals.
> But they were asking for regional information on their neighboring
> hospitals.
>
> In other words, aggregated data. And just from our experience here in
> the Greater New York area, it can bog down the discussion. So my
> recommendation to the group is that we acknowledge that there has to
> be two‑way communication and there\'s an issue of getting information
> back to reporters, but as our first task we weren\'t addressing that;
> we were only addressing what data should be collected with access to
> selected authorized persons in public health. The issue of back flow
> of information is a complicated one, was my main point. On the surface
> it seems self‑evident and simple, but it turned out not to be.
>
> \>\> Marty: Other assumptions that we need to be considering as we
> look at the data elements and the processes associated with really the
> collection and use, I think, was our theme here.
>
> \>\> One thing I\'m kind of struck by in this list of data element
> matrix, maybe I missed it, but it doesn\'t get down to this issue that
> we were mentioning in the Scope of Work about in Step 2 about how the
> code sets are aligned with these results from institutions, how that
> happens. I know BioSense has got a whole vocabulary tool for that. And
> it\'s not listed in this data elements matrix. Is that something that
> we need to be working toward? I mean is it even in question that it\'s
> not LOINC or SNOMED or is it just assumed that we\'re going to go with
> those?
>
> \>\> Kelly: We were anticipating that this group would get down to the
> level of identifying what this specific labs are, for example, that
> would need to be shared with public health, so not just lab results,
> but let\'s say everything that would be, you know, a CDC or a
> differential or specify what the specific labs are with microbiology
> or whatever it might be. And then as a part of the filtering exercise,
> specify what is not needed because it\'s too sensitive. So anything
> you know serology around STDS or HIV or whatever it might be, that
> isn\'t essential for the functions that you all agree on and then
> specify at the code level what would be helpful. But I think it\'s not
> expected that you get down to the very detailed technical standards
> that are needed. Because that\'s what the health IT standards panel is
> doing. So we\'re really talking about trying to identify the more
> granular data element level, what kind of data is necessary, not just
> for describing what standards you\'re going to use to transmit that
> data but what specific data is needed for public health. Does that add
> any clarity?
>
> \>\> Yes. So I haven\'t read the U.S. case carefully. Is there a list
> mentioned there or a list of diseases mentioned. Because you said STDs
> may be too sensitive to include but they are reportable diseases. This
> is supposed to be an anonymous reporting system. So at least from what
> I understand from the use case. So I\'m trying to get some clarity
> about what are the diseases we\'re looking for, if we\'re supposed to
> get down to the granular level to the diagnostic tick level to
> identify them.
>
> \>\> Having discussions on filtering with BioSense last summer with
> multiple groups. Decisions were made, just for the reason you said,
> not to filter. It was, it was this type of data is important. So
> procedure is data. And are there sensitive procedures that might be in
> there, yes. But would they serve a public health purpose. And as you
> suggested, yes. This is a different platform for a different way to
> look at reportable diseases in the future to have a balance between
> what a clinician is reporting and what could be identified from
> existing health data.
>
> Having STD data, there\'s a hugely compelling case to keep that in. So
> I don\'t think that was addressed in the harmonized use case. But
> rather the part of the charge of this Workgroup as I understand it to
> say what are important data elements to get to there a so that HCVE
> can move toward looking at the standardization of those elements or
> the recommendations for standards. And then if we think of the data
> element we pick that things are so sensitive that it\'s going to be,
> it\'s not going to be useful enough to public health to be able to
> justify receiving those data on a regular basis from a privacy or
> whatever other concern.
>
> \>\> Right. It\'s up to this group to determine what is really needed
> for public health. And in terms of what diseases are we really most
> concerned about, that would also be a good conversation to have, and
> add that to our working assumptions.
>
> Marty, I know we had discussed with Art the other day about some
> pathogens that might be of greatest concern at this point. So we could
> have that discussion and get some agreement around that.
>
> \>\> Dan: I\'m rather new to some of the discussions, and so is there
> any difference between, and this is directed at Perry and Marty.
>
> Is there any difference between what\'s requested now in terms of the
> pathogen list and a set of public health elements of interest? Is
> there any difference between that and what we\'ve discussed in the
> past with regard to the Dwyer tables and that type of activity? Is
> this a different discussion or is it a revisit of public health issues
> of importance? That\'s directed to Perry or Marty or anybody that
> might ‑‑
>
> \>\> Art: I\'ll jump in. I think it\'s maybe a little bit different
> because I think the example given earlier by Lynn about putting in
> Katrina in the free text field or adds suggestions about flexibility
> is that there may be things we don\'t know we need to be collecting
> yet. But that list of important public health pathogens certainly on
> our target now, but there may be something bigger than that.
>
> \>\> So the addition of Katrina in a text line is a request in a
> manual sense for a doc to do something versus a data element which
> might be chief complaint. And so I guess I\'m seeing, I\'m trying to
> figure out at what level, when we talk about granularity, what are we
> really talking about? Are we talking about those bins we want data to
> go into. Or are we talking about the identifiers that go into those
> bins? What is it ‑‑ what should we tackle first, I guess, is the
> question.
>
> \>\> Marty: I\'m sorry, I\'ve been coming in and out here on the
> phone. So I may have missed part of your question. But if there\'s ‑‑
> it seems like we have the challenge of the dual path of being prepared
> for the reportable conditions, such as the previous Dwyer table type
> reporting components, as well as the broader context for the
> biosurveillance with the data elements. So if we look at. One way to
> look at the filtering issues is filter in terms of what do we ‑‑ what
> is feasible in the next year among the pathogens that are of greatest
> significance and that our level of detail I could at least be similar
> to the electronic reporting that has been attempted in the past
> related to disease reporting.
>
> I don\'t know if Perry has any other thoughts on that.
>
> \>\> Perry: Yeah, I\'m trying to get my head around the question as
> well. I think I\'m coming down on the other side of the fence Marty
> from where you are. The Dwyer tables and the list of reportable
> diseases in each State for which we tried to identify the LOINC or
> SNOMED codes that are useful for reporting, all of that activity which
> I will term traditional public health surveillance for reportable
> conditions, is pretty indicated upon identifying information systems
> so local health can go back and know who the person was reported and
> obviously pulled the chart and called the doctor using the patient
> name, et cetera, et cetera. I look on all those activities as
> different from asking a provider or a hospital to provide a minimum
> set on everything in their emergency department or in discharge
> diagnosis or laboratory data system. And they need to be complementary
> so that the providers and facilities are not having to do extra work.
> But I don\'t ‑‑ I don\'t think I see a role for coming up with the
> Dwyer table like approach to the biosurveillance, the new kind of
> biosurveillance they're \-- ah, we\'re talking about today. So I\'m
> coming down on the other side, but maybe I\'m not completely grasping
> the question.
>
> \>\> Maybe the way I asked the question it was completely incoherent.
> That\'s a possibility as well. I was trying to get a sense of looking
> through the minimum dataset they are, they\'re essential, they\'re
> bins that you put data into and the filtering is an activity of having
> a set of criteria that are not the bins themselves but are the
> contents within the bins, you have to choose some things to look
> through these bins, I\'m presuming, whether you\'re talking about
> filtering. So to me those are very separate activities, and I was
> having a hard time getting a sense about are we trying to finalize or
> bring some coherence just to the classes of types of information that
> we\'re trying to receive, or are we trying to get down to the granular
> level of identifying those diseases. My comment was prompted by having
> more granularity about the kinds of things that would need to come
> through.
>
> \>\> Lynn: Just two comments to your comments, Dan. Maybe we\'re using
> the word binning differently. But I think being able to group data
> elements into syndromes or whatever grouping is the really helpful in
> the analysis part, in looking through large datasets in an ongoing
> way. But that if we\'re talking about situational awareness, you would
> need that patients data level. In order to drill down and ask those
> specific questions as they arrive. So you have to consider again the
> use case of the data.
>
> The other issue is filtering, once data elements are decided,
> depending on the way they\'re captured and the HL7 message may
> actually be harder to implement. It may take more time to filter.
> It\'s not specific blank codes we can ask for specific codes. I think
> the group should also consider that.
>
> \>\> I think you possibly were talking about binning in two different
> ways. Dan, your bins are like laboratory data and utilization data and
> other things.
>
> \>\> Yes.
>
> \>\> You were potentially talking about on the analysis side, Lynn.
>
> \>\> Right. Sort of like chief complaint is a bucket, if you want to
> call it, instead of a bin.
>
> \>\> Right. And I think to your question, Dan, the charge to this
> group is at both levels. The first is to talk about what kinds of data
> elements should be here and the second is if we do thing at all, there
> needs to be filtering to determine what that filtering is. And once we
> do that then experience in BioSense is potentially it\'s harder to
> filter. We want to consider that. But one of the things that came up
> in the broader steering group is can we justify under the
> biosurveillance umbrella for public health getting, for example,
> psychiatric diagnosis and discharge diagnosis or should those be
> filtered out. Those are the kinds of questions that should be
> distributed to this group to weigh in on.
>
> \>\> Okay. So the psychiatric diagnosis as a subset of data element of
> discharge diagnosis, that\'s a discussion about the things in the
> bucket, not the bucket itself, right?
>
> \>\> Absolutely. There\'s no question there a public health would want
> a discharge diagnosis. Do we want every discharge diagnosis that comes
> out of a health facility or should some be filtered out.
>
> \>\> Okay. And so I guess just to then to revisit Eileen\'s comment
> about are the minimum datasets data elements, rather, driven by what
> we want or what we think our data sources can provide? Or is it both?
>
> \>\> I think it\'s probably both. I think in the process that Kelly
> went over, the feasibility of what they can provide comes a little bit
> later, after we determine what public health would like. And goes back
> to Lynn\'s comment as she said, it\'s to drive this forward. I don\'t
> think we want to be constrained for what we have today. Target may not
> have the right word, but have that goal and then come back and say
> that this is what we can really did right now.
>
> \>\> Eileen: That\'s a fair approach. But I would definitely reiterate
> everything everybody said about filtering especially, when you\'re
> working with very large quantities of data. Filtering on content is
> enormously more difficult than filtering on data elements.
>
> \>\> Getting back to the list of assumptions, it would be helpful to
> understand the assumption regarding the time line. You know, again
> that we referred to one year, or is it really the charge of this group
> to come up with a list of data elements that make it feasible to
> implement this broadly across the country within one year. What does
> that really mean?
>
> \>\> I think there\'s clearly an intention to try to demonstrate, you
> know, the value of sharing data simultaneously across jurisdictions,
> and as many jurisdictions as we can feasibly reach within the next
> couple of years. And you know there\'s a lot of ‑‑ Lynn, you\'re
> probably more familiar with all the barriers that might exist now,
> particularly in clinical care and middleware to get all the data out
> of clinical care.
>
> But we are talking about in the near term, meaning in the next couple
> of years what are the set of data elements and what are the
> requirements really that we need, that this group needs to decide on
> that should be accessible from clinical care and transmitted
> simultaneously to local, State and Federal public-health-authorized
> agencies.
>
> \>\> Art: You know, this kind of makes me wonder, since it\'s probably
> not going to all happen in a year, and it would be a staged approach.
> I think this gets back to Ed\'s point earlier, even though we kind of
> said we\'ll do our best in terms of feedback and biodirectionality.
> But you bring up the word value. And what is really the value of this
> to the data provider? And I think if we think, look at this has a
> staged approach, that we need to see some way to get feedback to the
> data sources that wants to make them want to continue to play in this
> arena, and the next phase after that. Because we\'re not going to get
> everything done in 1 year, obviously. And we probably need to kind of
> lay out some phased approach. To keep the data providers engaged.
> We\'ll want to have something that they perceive as valuable.
>
> \>\> I think that\'s probably an important consideration when we get
> to the feasibility consideration, if we want ‑‑ we need to be agreeing
> on data elements that will be available over time and they\'ll be
> accessible over time if in fact clinical care partners see value in
> this effort. But I think that we don\'t really need to be overly
> concerned with at what point do we sequence in biodirectional
> communication or making sure that we have data elements that will be
> available for biodirectional communication. Because that\'s really out
> of the scope of the specific use case, or the specific charge. We\'re
> definitely going to go there. It will be in subsequent use cases,
> coming from the American Health Information Community, but right now
> we\'re really just, we have to try to stay focused on what\'s been
> asked of us, which is really trying to figure out how we\'re getting
> data from clinical care into public health.
>
> \>\> Paula: I think we\'re kind of talking a little bit in circles.
> And I\'d just like to propose maybe a way to move forward. I think
> we\'re at a little bit of a stale mate because we don\'t all have a
> common understanding of the definitions of what we\'re trying to do.
> So I think that\'s probably the first most important thing to move
> forward. And then decide, based on those definitions, what are the
> functions that need to be performed, basically what does public health
> need to do, what do we have to do under each one of those definitions,
> what does outbreak management mean?
>
> And then from there we can decide what data we need. Because if we
> don\'t really understand what the definitions are, have a common
> understanding of the definitions, have a common understanding of what
> functions are required to perform those things, then we can\'t really
> get to the data piece.
>
> And that\'s my two cents' worth anyway.
>
> \>\> I\'d agree.
>
> \>\> You don\'t believe the harmonized use case ‑‑
>
> \>\> The definitions aren\'t there and the functions that need to be
> performed ‑‑ just talking with colleagues and members, I don\'t feel
> like there really is a common understanding of what biosurveillance
> is. And I think we really need to get to that point and what are the
> functions that are that need to be performed by biosurveillance. I
> think everyone understands syndromic surveillance very well. I think
> some of us understand situational awareness a little bit better maybe
> than a year ago.
>
> I think we all have an understanding of what we need at the State and
> local level by outbreak management. But do we all mean the same thing
> when we\'re saying that? What is it that we mean by each one of these
> and then at the different levels what does the Federal Government need
> to be able to do with the data. What does the State need to do with
> that data and what do locals need to do with that data. So rather than
> continue talking without a whole lot of direction, maybe this can add
> at least some framework for what we\'re talking about.
>
> Any reaction to that?
>
> \>\> I think you\'re right on. It\'s this idea ‑‑ Kelly asked if we
> could get a working definition that biosurveillance is using. I\'ll do
> that sitting here. But in some ways it comes out here and it\'s not
> specific enough. When we first started talking about BioSense, we had
> to define biosurveillance. There were a lot of slides that talked
> about various use cases. I didn\'t necessarily use those words,
> outbreak management and response management. But we have described a
> set of uses for that day that would take you there.
>
> \>\> I think we need to go back and revisit that. I think use cases
> are the best way to go to get to this kind of data because it brings
> everybody to a common understanding of what we\'re trying to do and
> then move forward.
>
> \>\> And the one working assumption we\'ve tried already that\'s
> articulated, and is very clear and been sort of talked and agreed upon
> at the American Health Information Community level, is that we\'re
> talking about a multi‑directional biosurveillance program. It\'s not
> just a biosurveillance program there, Texas, North Carolina, or New
> York City. We\'re talking about one that\'s really going to work
> across public health.
>
> \>\> Right.
>
> \>\> Marty: Any other questions from Paul\'s suggested framework?
>
> Is that information available? Those definitions, or is it something
> we need to put together?
>
> \>\> Art: I think we need to continue to work on this. I think earlier
> Kelly said she would help out in collecting some of those or the staff
> would. And we would come back and work on that. And I think Lynn said
> there are some available. I\'ve been looking at the CDC Web site and
> trying to see what is available from the FIN documents. Because
> obviously Paula we need definitions here otherwise we\'ll continue to
> go around in circles.
>
> \>\> Laura: This is at a high level and it\'s kind of a little
> embarrassing to suggest it to this group with all of you doing it
> every day. But for outbreak management, I\'ve used it over time:
> supports and manages activities associated with an outbreak or an
> event, that include case investigation, contact tracing and
> monitoring, exposure source, investigation, et cetera.
>
> Now that\'s at such a high level, I\'m not sure it\'s a useful working
> definition for this group. I think we have to break that down and
> really determine what we mean about some of those activities.
>
> \>\> And biosurveillance isn\'t all about outbreak management.
> Biosurveillance data form a part of outbreak management.
>
> \>\> Right.
>
> \>\> So I think it is sort of defining the use for biosurveillance as
> part of the tools for a comprehensive outbreak management program.
>
> \>\> Scott: If you would like I already started a list when I first
> came on board. And I\'ve added several of our tick marks. So far I\'m
> up to 41 terms so far that we need to go through and define and help
> out along with some acronyms that some people may be familiar with.
>
> So if people would like to e‑mail me those definitions that they have,
> I will compile them and give them to the group so that we can kind of,
> I guess, agree upon or start discussing those elements and what we
> like about some and versus the other and start coming up with a
> combined or a biosurveillance data-steering group definition moving
> forward.
>
> \>\> Dan: Looking at the harmonized use case and another term that\'s
> been used describing the public health care functions. Was there a
> model or set of functions that sits behind this use case, was used to
> derive this use case?
>
> By that I mean that in the past, a long time ago, I mean we tried to
> come up with a functional model that basically described what happens
> in public health and part of that was outbreak management.
>
> Is that something that we can draw on so that we have a common
> understanding of what we think the function of outbreak would be or
> the function of situational awareness would be.
>
> \>\> Dan, I don\'t think there was one that was given to the NIHN
> Consortia, the Certification Commission, or HCVE. And they initially
> drafted these. We did try to work with some experts internally to come
> up with, the harmonize of the common use case and take into account
> the functions of public health that are relevant but we didn\'t start
> with a functional health system model.
>
> So I don\'t know that that would be helpful. It\'s not available for
> us to refer to. But maybe it would be possible for us to have a
> conversation around, you know, what the working definition that Laura
> just proposed for outbreak management, and just get people\'s feedback
> on how we think biosurveillance should relate to or enable situational
> awareness, so we have some clarity. Not necessarily that we have a lot
> of specifics to work from at this point in time, but if we could get
> all of your opinions on what do we think we\'re talking about when we
> refer to biosurveillance and situational awareness.
>
> \>\> The other possibility is a data model. And I know a lot of folks
> had to develop them in the past. Is there a similar kind of data
> model, even a conceptual data model that folks have been referring to,
> or using?
>
> \>\> Not that I\'m aware of.
>
> \>\> Okay.
>
> \>\> Marty: Dan, can you describe a little bit more about the
> functional model you had for public health that you used in the past?
>
> Dan: It\'s been it traded in many different ways. It used to be
> maintained out of FIPO, the public health practicing, something and
> something office. It\'s turned into something else, I don\'t know what
> it\'s called now.
>
> And I think ASTO and NACCHO participated in these in the past. But
> they were high level. Eight separate functions that were identified
> with public health. And within those there were greater and greater
> granularity about activities that happened.
>
> You know, what is the goal of surveillance and how does, what is the
> data that\'s collected as part of surveillance and so that was a
> functional activity. A description of the functional activities within
> public health on a very broad set that you know just informed
> integration of activities so that folks understood the broader context
> of public health so that when we were talking about one particular
> area, we knew how it fit within the roles and responsibilities of
> different members of the public health community.
>
> And I haven\'t seen that in years. So I don\'t know where it is. But I
> was thinking that perhaps that was some activity that was going on,
> because of the larger AHIC activity. The conceptual data model that
> incorporates a lot of the functional stuff was commissioned back when
> NED was first happening. And you know it\'s a high-level model but at
> least it break down things into recognizable terms and it also
> connected it to the larger modeling activity that was happening at
> HL7. And so I mean there\'s a lot of work of describing what happens
> in the clinical environment in a standardized way that public health
> had worked to try and link to through the HL7 modeling process. And I
> left that activity 2 or 3 years ago. So I don\'t know what\'s happened
> since that time. But that\'s a place where people have thought about
> sources of data or how data gets moved, how it gets represented. You
> know, who are the receivers of the data, that kind of information that
> I think is useful in getting a coherent approach to it.
>
> So when I see a use case, to me that\'s often the end of an activity
> where you\'ve worked toward this by, you know, having a common
> understanding of different underlying issues like the functions and
> the data. That\'s what I was trying to see, if this use case actually
> represented some other activity that had gone on.
>
> Sounds like it hasn\'t, so that\'s okay.
>
> \>\> Sounds like we have to fill in those two pieces.
>
> \>\> It\'s a huge task, that\'s right. I\'m reluctant to bring up any
> of that. Because it\'s a lot of work. But I guess a lot of this work
> has been done already. Perry and Marty can chime in. They I think have
> been more connected to some of these activities. But I mean
> biosurveillance and connecting data automatically, you know, is one
> component of a larger public health activity that just seems like
> somebody may have been trying to put it all into context. But maybe
> not.
>
> \>\> Marty: I think it reflects part of our dilemma here, which is
> we\'ve, we have a request for the data-steering committee and the four
> steps with our Scope of Work to look in part of where can we go in the
> short term, working definitions of some basic functions. While we
> concurrently in our assumptions are saying we want to look at it in a
> more comprehensive way, which may get to the more exhaustive detail of
> data modeling and the whole more in detail looking at the
> biodirectional flow needs, for example, some of the issues that have
> been raised in our assumptions.
>
> I think that\'s part of the tension at least that I\'m hearing with
> the work that\'s gone on and what, how much, what is it the words of
> Wayne Gretsky, we skate to where the puck is or where it\'s going. And
> the balance between those two is what I\'m kind of hearing in some of
> these comments. And I guess I\'ll ask the question is this: Where do
> people see where that balance is? Is there a portion of this that we
> can make some working assumptions on that while we still make the
> recommendation that this is some ongoing work in the step for the
> evaluation is really the difficult part.
>
> \>\> Those are two hard things to balance. But you\'re right we need
> to define whether we\'re (inaudible).
>
> \>\> Marty: I think this discussion so far has been right along
> actually our agenda looking at really refining our Scope of Work in
> terms of our process for reviewing refining the minimum sets. And
> I\'ve heard we certainly have to be gathering a little bit more of the
> working definitions, listing our assumptions that we need to be
> making. If there is some background material as Dan had suggested
> related to some of the functions, such as the modeling that would be
> an initial background, that would be helpful.
>
> If we look at the Scope of Work itself, do the four steps still make
> sense in this context that we\'re describing or this process that
> we\'re describing as well, which include the identifying of elements
> and I\'ve heard at least two that we need to be exploring that are not
> here yet. The notion of the yet‑to‑be‑defined concept and the notion
> of getting back to people context.
>
> First question is do those steps still make sense in the context. If
> there are, are there any steps of 1 and 2 that aren\'t working as
> well?
>
> \>\> With the added work and the definitions, I think it makes sense.
>
> \>\> That\'s Part 1. Framework is part of Step 1. It just needs to be
> expanded. It\'s got to be the next iteration we work on our charter,
> if you will, our Scope of Work, include that as part of the Step 1,
> would that be okay?
>
> \>\> I don\'t see why not.
>
> \>\> Great.
>
> \>\> Marty: Other pieces related ‑‑ this is Marty ‑‑ in terms of the
> assumptions or pieces we need to add to that step one in our process
> here?
>
> Okay. Art, other thoughts or suggestions? I hear ‑‑ it\'s hard to hear
> on the phone everyone nodding or looking up on the Web site
> independently.
>
> \>\> Art: I\'m just kind of reading through these myself as well. I\'m
> just studying them to see if there\'s some other points from the
> discussion that we want to add to this in the next iteration. Calling
> this our charter is probably meaningful at this point being sure that
> we\'re all on the same page about this. Were there any concerns about
> what is stated in step one or things that we want to remove from it?
> Or Step 2?
>
> \>\> Dan: What is the process by which we will identify these data
> elements that have not been previously identified?
>
> \>\> Good thought. Just coming up with ideas. Possibly you know coming
> up with some scenarios, I guess, where we test: Have we have the
> capacity to identify an event in a community, you know. I could get
> back to the idea about Katrina. Some environmental issues may surface
> at some point and would we be able to identify it from the typical
> data models that exist in health care today. And if not, if that\'s a
> biosurveillance activity that we think is required, how do we make a
> recommendation about that?
>
> \>\> So basically I guess one thing is to identify how is it that
> we\'re going to test ‑‑ one thing is to test the use case. The other
> is to send the use case out to constituents that have, you know,
> stakeholders or whatever, people that are involved, and ask them to
> say whether or not they have their needs represented by the list, is
> that, has that activity already happened where we\'ve sent it out to
> people that we know will be impacted for their comment, or are we at a
> stage before that?
>
> \>\> Joy, can you respond to that?
>
> \>\> Joy: Have we e-mailed this out for people\'s comments? This was
> sent out on Monday.
>
> \>\> I mean, if the point is for us to identify additional data
> elements that need to be added, is that ‑‑ am I understanding Step 1
> correctly?
>
> \>\> Joy: Yes.
>
> \>\> Then one way is to test the use case, and I don\'t know if we
> have tests for the use case, hurricane tests, anthrax tests, influenza
> test, I don\'t know. That\'s one approach. That\'s where we think the
> data elements are stable and we want to test it against a set of real
> world activities. The alternative is to take the data elements, not
> assuming that they\'re stable yet, and send them to key reviewers,
> either at ASTO. NACCHO blah, blah. The people we think will be
> impacted. AMA. I don\'t know. The people we think may be able to
> appropriately inform the list of the data elements. That\'s another
> way to get a reading on whether we think the data elements are
> appropriate. The third is for us to just simply look at it and say
> yeah, it looks all right. Which is, that\'s okay, if that\'s what we
> want to do.
>
> \>\> Eileen: I think some scenarios are really a good idea, and it
> goes to a comment that was made earlier I think by Perry Smith about
> specific goals, and I think some scenarios would really help us
> identify how we\'re using the elements of the minimum dataset.
>
> \>\> Laura: I think we\'ve done a little bit of this in the broader
> group. There are some very high level scenarios that we can share if
> they haven\'t been shared with these group. And we did, you know in
> the broader group, ASTO and NACCHO and we\'ve had testimony from AMA
> and gotten input, but not necessarily potentially a sufficient data
> element level. So it\'s possible that we would want to try and take
> that next step and ask key people to specifically run this through
> some of their, what they look as their scenarios for their
> jurisdictions. Specific tests like you mentioned for specific
> pathogens, events.
>
> \>\> Marty: With the biosurveillance data elements matrix, certainly
> New York City, North Carolina, has there been any experience there in
> terms of testing or validating the scenario? Use case?
>
> \>\> Laura: I can\'t speak specifically. Obviously Tom Frieden and
> others from their jurisdiction have been participating in the broader
> Biosurveillance Workgroup. And giving input there.
>
> \>\> Marty: Is it a fair assumption then to say that from at least
> their jurisdictions these minimum datasets work?
>
> \>\> Art: I have heard FARSAD talk about identifying, there was a 757
> that crashed in Queens shortly after 9/11, sometime in the late fall
> of 2001, and the surveillance system was able to detect visits to the
> ED after that event. So I don\'t know whether it\'s going to answer
> our question or not. I know that they\'ve been able to find things.
> They\'ve been identifying things, but will it for a test scenario be
> useful, I think that\'s one of the points about Step 4 is, you know,
> what is identifiable using whatever minimum dataset we decide to
> propose.
>
> \>\> Ed: Art, I think that was a smoke inhalation they detected. I
> know the New York City folks had a fairly detailed response to this
> proposed list of data elements, and I know that one of our purposes of
> this Workgroup is to try and mitigate some of the concerns that were
> expressed between New York City and BioSense. I wonder, since there\'s
> nobody from the New York City group on this panel if we shouldn\'t at
> least circulate the response that Tom Frieden gave on the data on the
> list. Is that something we might do, Kelly?
>
> \>\> Good idea.
>
> \>\> Kelly: From the New York City program?
>
> \>\> Yeah, Tom Frieden wrote a pretty detailed letter that included
> line by line going through these data elements. And commenting on
> them.
>
> \>\> Kelly: Yeah, I think we also have, yeah, certainly his opinions
> are expressed in that letter about a variety of things, many of which
> go beyond the data elements. But we can certainly make that available
> to you all. I think we also have the data elements that are already
> captured by New York City in the tables that we included as hyperlinks
> in the agenda.
>
> \>\> Marty: So in this last discussion, do you think that scenarios, I
> think Dan was talking, I can\'t be sure, that we need to create some
> scenarios by which we can compare these data elements to those
> scenarios to see if we think they would match up to identify stuff?
>
> \>\> Dan. My question really what is the ‑‑ the step is that the
> steering group will identify the data elements needed that have not
> been previously identified. And my question was how is it that we ‑‑
> what\'s the process for us doing that. And is it that we review
> comments from those that have reviewed the data elements, or do we
> need to initiate review of the data elements by key folks that are
> currently doing syndromic or other kinds of electronic surveillance.
> Or is it that we commission somebody to try and test these data
> elements using different scenarios, because maybe giving that to
> others who have that knowledge and simply doing a tabletop run
> through. That\'s what ‑‑ I\'m trying to get at how do we achieve step
> one.
>
> \>\> Bill: I think both of those steps are good. And one of the things
> that came to my mind as we were talking about the scenarios ‑‑ this is
> Bill ‑‑ have we vetted any of this or matched any of this into any
> data requirements that might be required by appropriate scenarios out
> of the 15 national planning scenarios from Homeland Security. A number
> of those involve, obviously, biosurveillance types of issues.
>
> \>\> That would be an integrated, thoughtful way to start.
>
> \>\> Lynn: We also have as part of our evaluation plan for BioSense is
> to test scenarios based on actual events that have occurred in the
> past. And we have an enormous amount of data in the form of after
> action reports regarding a lot of our emergency response activities
> and the question is what data would have been useful to improve
> timeliness. It\'s a project. It\'s not a ‑‑ it\'s not an activity that
> can be done in a couple of hours. It needs to be done. I think that\'s
> what we\'re all saying.
>
> \>\> Right.
>
> \>\> I\'m wondering if maybe we need to start with at least a couple
> of scenarios that we can refer to as we have these discussions, just
> the same way we\'re trying to get clarity about the terms and some of
> our assumptions. Should we have some reference point by which we can
> continue to think about things. Maybe the one you\'re suggesting,
> Bill, is well enough developed that we just use those.
>
> \>\> Yeah, that\'s probably more well developed than we wanted. It\'s
> about a 157‑page document here. But like I say not all of them have
> probably specific biosurveillance relevant things. But a lot of them
> do have things like pandemic flu, aerosol anthrax, toxic industrial
> agents, nerve agents, hurricanes, food contamination and foreign
> animal disease. Those are a sampling of ones that are in there.
>
> \>\> Can we have a conversation around that list that you just
> mentioned and try to agree on what we think are the top three
> priorities for scenarios?
>
> \>\> That would be great.
>
> \>\> Did you mean now or in the future?

(Laughter)

> \>\> We still have an hour and 45 minutes if we want to do this all as
> homework.
>
> \>\> No, let\'s do as much as we can now.
>
> \>\> The list you have, that\'s not some classified thing that we
> can\'t look at, is it?
>
> \>\> I can e‑mail it. It\'s a PDF document. I can e‑mail it to you.
>
> \>\> There\'s a big classified section that goes behind that. But
> these were the national planning scenarios that led to the universal
> task list and things in order to get all the Federal players on the
> same page in regard to what are we preparing for.
>
> \>\> Exactly.
>
> \>\> Why not just use that list?
>
> \>\> Probably I think what Kelly\'s point was we probably don\'t need
> to use them all.
>
> \>\> No, we don\'t.
>
> \>\> They\'re redundant. Is pan flu or influenza really important? I
> think we would say yes. It\'s a transmissible. Inhalation anthrax
> represents the quintessential exposure that could affect populations
> and then a natural disaster.
>
> \>\> Chemical spill, something, you know, hurricane.
>
> \>\> Chemical spill, the radiological exposure. Those are interesting,
> because I\'m not even sure that the vast data element sets that people
> describe as part of BioSense would pick up some of those things.
>
> \>\> Right.
>
> \>\> Kind of take the animal-mineral-vegetable approach to, you know,
> get our bugs in here, get our chemical agents and get our
> environmental working that maybe we can encompass that into all three
> or you know try to encompass these elements so that we can span all
> three of these scenarios and make sure that we\'re hitting all three.
>
> \>\> Kelly: Can we actually have, just to go through each one, and
> have everyone vote on whether or not we should have it as one of the
> top priorities or not?
>
> \>\> Who\'s got the list?
>
> \>\> Is there a place we can find this list on the Web, Bill?
>
> \>\> Bill: There is. I don\'t have the link. It\'s a 2.47-megabyte
> file. I could probably just send it to somebody for distribution if
> you\'d like.
>
> \>\> Kelly: Can you pull it up and read the list of scenarios?
>
> \>\> Bill: Sure. Let\'s see. Let me start out here. It\'s got 15
> scenarios. Not all of them apply. Scenario 15 is a cyber attack.
> Scenario 1 is nuclear detonation. Scenario 2 is biological attack,
> aerosol anthrax. Scenario 3 is biological disease outbreak, pandemic
> influenza. 4 is biological attack, plague. 5 is chemical attack,
> blister agent. 6 is chemical attack toxic industrial chemicals. 7 is
> chemical attack nerve agent. Number 8 is chemical attack chlorine tank
> explosion. Number 9 is natural disaster major earthquake. 10 is
> natural disaster, major hurricane. 11 is radiological attack with RDD,
> radiological device or dirty bomb. 12 is explosive attack, bomb using
> improvised explosive device. 13 is biological attack, food
> contamination. 14 is biological attack, foreign animal disease. And
> they say specifically foot and mouth disease. And then, of course, 15
> is cyber attack.
>
> \>\> So basically you\'ve got really 1 ‑‑ you\'ve got biologic is 1.
> Chemical is 2. And radiologic is 3. Natural disaster is four.
> Explosive, I guess ‑‑ there\'s really like five or six different
> categories?
>
> \>\> Correct.
>
> \>\> We may want to think about naturally occurring disease and
> biological. I don\'t know if you said both of those, Ben.
>
> \>\> The natural disaster like earthquake would be more like the
> explosive IED thing, I think. Which is trauma‑ish and biologic whether
> it\'s intentional or natural occurring I don\'t believe would impact
> the information gathered in a system, I don\'t think.
>
> \>\> Ed: If you drive it all down it really comes down to wanting to
> be able to measure the resources that are available to respond. Both
> on a hospital level and on an open-and-closed and also maybe details,
> do they have ventilators, do they have other special equipment. And
> you want to measure the patterns of illness or injury that occur over
> time. Isn\'t that the two things we\'re going to want to measure?
>
> \>\> Right. And I guess ‑‑ well, I mean contact information and so
> forth which I don\'t know if that\'s even addressed in the minimum
> dataset. I mean that\'s really what you want in saying the influenza
> one, you want to know who was exposed. But that\'s not the kind of
> thing that you\'d be easily able to capture automatically or
> electronically.
>
> \>\> That gets to ‑‑ are we really trying to address the traditional
> reportable disease reporting and investigation of individual cases? I
> didn\'t have the sense that\'s what we were trying to address.
>
> \>\> I don\'t think so. That\'s just getting back to that notion of
> the functions. Contact tracing is a public health function that\'s
> critical to response. And this is not addressing that function, I
> believe.
>
> \>\> Dick: This is Dick Melton, the minimum dataset however allows
> that with the ability to back track through the data, although it
> doesn\'t come directly in that fashion.
>
> \>\> Exactly. Right because there\'s next of kin kind of data that can
> be collected from the information systems that can assist in that kind
> of thing or alternative names and things like that, but I just
> don\'t ‑‑ I don\'t know to what degree of, you know, trying to get at
> those kinds of issues are helpful for this overall project.
>
> \>\> Marty: What I\'ve heard from the list in terms of making an
> assumption here for our scenarios, is we can either pick a few of the
> 15, like the ones that were mentioned pan flu, and inhalation anthrax
> and natural disaster or pick the categories upon which are we will be
> sort of basing our initial assumptions for this step one. Is there a
> direction on the table whether we pick the three versus the categories
> on which we\'re basing these?
>
> \>\> I guess that brings up the question then if we pick just say one
> of biologic, one of chemical, that kind of thing, are they going to
> serve to be illustrative enough for us to test the system with? Seems
> like they would be.
>
> \>\> I think it would be a good start.
>
> \>\> Are we saying that a good start would be to select some in
> different categories?
>
> \>\> Yeah, like pick biologic influenza. Pick natural hurricane. Pick
> radiologic dirty bomb, and is that going to be adequate enough.
>
> \>\> And chemical nerve agent would be another one.
>
> \>\> So I think with those four you\'re going to get the breadth, I
> think, of the differences between these kinds of events that would
> make sure that we have adequately, that what we have in the minimum
> dataset will automatically capture what are the critical information
> that\'s needed for situational awareness.
>
> \>\> Dan, can you say those again.
>
> \>\> I chose biologic influence, chemical nerve agent, natural
> hurricane and radiologic dirty bottom.
>
> \>\> What do people think about that?
>
> \>\> The only one that\'s left out there and I think somebody said
> this before, so the hurricane is going to do capture the data that
> we\'d otherwise need for explosive attack; is that correct?
>
> \>\> Yeah. Because if what you\'re looking for is injuries or
> presentation of a lot of people to health care, you could make any
> natural disaster scenario, right?
>
> \>\> Trauma.
>
> \>\> Yeah, trauma.
>
> \>\> The other thing I might suggest is something in chemical that
> might have a slower presentation rather than something, because
> you\'re going to have two different kinds of elements. One where
> there\'s sort of a dramatic introduction into a population and a lot
> of people would expect to be exposed kind of simultaneously, versus
> something in the food or water that may give a slower presentation and
> it might change our assumptions a little differently.
>
> \>\> That was my concern, too. There was an outbreak, pick and pan
> flu, an outbreak there. And some of the attacks tended to have
> varying, of course, in chemical there\'s a toxic industrial chemical
> which implies a slower migration into the population as opposed to
> some of these others that act almost instantaneously. Would there be
> any difference in the things we\'re looking for to detect a more
> slowly evolving thing, in other words, needing more sensitivity and
> having the data elements to make sure that we\'re tracking that kind
> of a thing? Again, this is sort of back to the detection phase.
>
> \>\> Yes, I think there would. And I think the food borne illness is
> appropriate.
>
> \>\> Yeah, I don\'t know the scenarios well enough to comment. But I
> mean we could, you could do hybrid and simply what you\'re trying to
> do, you\'re trying to test not this particular scenario but the data
> issues that these different scenarios raise, and that\'s what we\'re
> trying to get at, one, notion of contact tracing, one notion of
> delayed and one notion of individual that is either themselves the
> source of infection or toxic disease that could be transmitted to
> health care workers. There\'s lots of different issues that each of
> these scenarios bring up.
>
> \>\> Exactly.
>
> \>\> Maybe we could start with just three or four and then as we
> recognize if they do or don\'t work, we can add those additional
> elements that we think need to be sure to be tested. But I mean the
> list of elements right now is so broad that I just can\'t imagine that
> we wouldn\'t be able to represent everything we need, but that\'s
> where somebody that knows this stuff very well, if they were tasked to
> sit down with this list and, you know, test it against this list, I
> think they could do it in their head maybe with a group of people in 2
> or 3 hours.
>
> \>\> And it will be part of that process then to test against what the
> minimum dataset looks like, and in doing so you may also identify data
> that could be useful for helping address that scenario that\'s not
> part of the minimum dataset?
>
> \>\> Yeah, I think we\'ve gotta do both. Exactly as we say in Step 1
> and Step 2.
>
> \>\> Okay.
>
> \>\> So the four elements to recapture so far, have been the pan flu,
> the nerve agent the hurricane and the dirty bomb. Did we change in the
> discussion.
>
> \>\> Food contamination or food borne illness was raised.
>
> I don\'t know that we can rank probabilities, I don\'t know if
> there\'s been any simulations done like that, but I know there\'s been
> quite a bit of concern about the possibility of contaminating the food
> supply.
>
> \>\> Is it specific to a natural food borne contamination such as a
> worker with hepatitis A versus somebody actually poisoning the food
> system?
>
> \>\> Well, the national planning scenario specifically contemplate
> biological attack. In other words, the idea is it\'s intentional.
>
> \>\> Ed: Being from Milwaukee, the epicenter of *Cryptosporidium* a
> few years back, a classic case study for an insidious problem that
> became quite widespread. I\'d be happy to offer that as an option for
> testing, using it as a test case.
>
> \>\> That\'s a good one.
>
> \>\> I was just thinking of the same thing.
>
> \>\> The one thing that might be perceived as positive if we select
> something from these national planning scenarios is it\'s an effort to
> use what has been established at a Federal level already.
>
> \>\> Right.
>
> \>\> And probably the biofood contamination scenario is another one.
>
> \>\> I think that was in there, wasn\'t it?
>
> \>\> Is that in the national planning scenario?
>
> \>\> No. 13.
>
> \>\> That\'s right.
>
> \>\> Was that case?
>
> \>\> No it wasn\'t a case of *Cryptosporidium* but a biological food
> contamination scenario as we walk through it we can think of it in
> terms of being an insidious food or water borne problem.
>
> \>\> I guess I was looking at this maybe a little differently. And
> since we don\'t have the document in front of us, it\'s hard to say
> that these 15 scenarios or whatever number there are, were the ones
> that we were going to select from, and we would take as have been
> mentioned four or five of them and try to use that as a guide. Sounds
> like now maybe at your suggestion we adapt one to fit into one of
> these categories.
>
> \>\> Right. I think we can use 13; it will probably work for the same
> purpose. That would leave us with five. Pandemic flu, chemical nerve
> agent. Hurricane, dirty bomb and a biological or water borne food
> contamination.
>
> \>\> The one that\'s in the scenario, the national planning scenario
> specifically has to do with liquid anthrax bacteria delivered to a
> beef plant, a beef processing plant.
>
> \>\> That specific scenario might be more time specific than
> *Cryptosporidium* was but I think it will raise the same data issues.
>
> \>\> Good.
>
> \>\> I\'m trying to drive the group forward here. Now I\'ve got three
> main categories of kind of data issues. One is resource availability.
> The other is illness and injury pattern recognition and the other is
> individual case reporting and investigation. Are those the three kind
> of meta-level categories we\'re talking about?
>
> \>\> Could you repeat those, please.
>
> \>\> Resource availability. Illness and injury pattern recognition and
> individual case reporting and investigation.
>
> \>\> Lynn: I would say that second one is not just recognition.
> Because I think it\'s, in looking at response management and sort of
> having a data source to know where illness is not or where response
> measures have worked. So it\'s tracking maybe more than recognition,
> right?
>
> \>\> Sure. That\'s a friendly amendment. I agree.
>
> \>\> I\'m friendly. Despite what you might have heard.

(Laughter)

> \>\> Those are our public health functions that I think we\'re
> identifying how it is that we\'re going to track those with these
> elements. So I think that\'s a good start.
>
> \>\> Okay, now who is going to do this work?
>
> \>\> I guess I need to leave the call now, see you guys.

(Laughter)

> \>\> I guess I was more asking is this a function of the Workgroup? Is
> this a function of Federal Government? And I\'m just looking at Kelly.
> Could our staff help?
>
> \>\> Yeah, I think in many ways, certainly we could try to get some
> Federal resources to help with this, but it would be good to draw from
> any ASTO or NACCHO members that have any experience dealing with these
> scenarios like the *Cryptosporidium* outbreak. So I would think that
> it would be good to maybe just have some, you know, volunteers of
> experts to maybe work together on this and figure out before our next
> call what we all could get done.
>
> \>\> If you can outsource these to these people that receive money for
> these centers of excellence and bioterrorism or whatever it is,
> that\'s what they\'re supposed to be thinking about, how to better
> prepare for these kinds of things.
>
> \>\> But that\'s another idea. I know there\'s some thinking that
> perhaps some of the centers of excellence might have more of an
> academic approach and not, their experience isn\'t always based on a
> real world experience, but certainly that\'s one potential resource we
> could draw from.
>
> \>\> There\'s another side of this, which is the hospital side, being
> asked for lots of data during emergencies. And you know so it\'s not
> just what data is useful for public health but what data from the
> health care perspective do you want to make sure is included, because
> it\'s information they\'re repeatedly asked for. And so if it\'s
> available on an existing IT system, should it not be part of a minimum
> dataset if it\'s important for community response. So there might be a
> perspective here that\'s beyond our public health partners. And the
> American Medical Association has a group that deals with preparedness
> issues that may be able to help. Okay?
>
> \>\> And in sort of a limited scope way that\'s exactly we\'re working
> on one of our ATC projects for this particular project is working very
> closely not at the American Hospital Association, but we\'re working
> with regionwide, dealt with hospital council and a number of hospitals
> that are already on our surveillance network to pursue exactly that
> expanded dataset or whatever you call it, expanded or limited dataset
> or whatever. So that fits nicely in our project this year.
>
> \>\> Is that a volunteer?

(Laughter)

> \>\> Yes.
>
> \>\> I was about to volunteer you.
>
> \>\> Yeah, I guess that\'s what I\'m saying is we fit very nicely in
> that category. Like I said earlier, we\'ve already done some work
> along those lines here in the first month of our project year with the
> matrix that we put together here.
>
> \>\> I don\'t know what the rules are but perhaps we can help convene,
> some of the members could help convene the people that want to work on
> this, because I think there are quite a few people that would, say
> we\'ll take this scenario or however we want to divide the work.
>
> \>\> Should we be dividing this by scenario or is there likely to be
> overlap.
>
> \>\> If there\'s overlap, we can certainly work that out when we
> combine this.
>
> \>\> That would be the easiest, less messy way to do it. And
> (inaudible) too, so building in some overlap, we capture all the
> thought processes on each of these.
>
> \>\> Right.
>
> \>\> It would make it more manageable.
>
> \>\> Because when you think, there\'s the advanced practice, centers
> of excellence and public health informatics. There\'s the American
> Hospital Association Preparedness Group. I don\'t think it would take
> us long to say let\'s find five different volunteers to work.
>
> \>\> If we sort of get two groups of the set of experts we need and we
> split up, we could give each two different scenarios, we then, we\'d
> have, if we were agreeing on our five scenarios, we\'d have to figure
> out who would take on the third. But maybe two are similar enough that
> we can perhaps collapse them. And are there any other folks on the
> call who want to volunteer to be part of that?
>
> \>\> A part of what? I\'m not sure where we\'re going.
>
> \>\> I\'m a little unclear exactly how many different tasks we\'re
> going to walk away from this call with before volunteering for this
> particular one.
>
> \>\> I gotcha. Let\'s keep a tally and we can decide at the end. But
> what I was just referring to, is if we do get two different groups of
> epidemiologists and perhaps some clinical care experts who can look
> and evaluate based upon the scenarios that are presented to them, to
> identify and go through Steps 1 and 2, perhaps, and figure out what
> data elements are needed that are not currently represented and then
> what\'s not needed. And then have that list to come back to this
> steering group with for a complete review. So I guess preceding that
> process we\'d have to make sure that we\'re comfortable with the five
> scenarios and that we appropriately divide them up.
>
> \>\> That sounds right to me, what you just said. The assignment is
> doing that, mapping, basically mapping data elements per Steps 1 and 2
> with the help of clinical care as well as epidemiologists for the five
> scenarios. Is that what you said?
>
> \>\> Yes.
>
> \>\> Good.
>
> \>\> Can I suggest we try to drive it through too to have people
> categorize which types of data elements they would need for each of
> the three functional categories, again so specific example. Nerve
> agent, breakout, I\'m going to need to detect what resources are
> available. So what resources do I want to check on? I want to check on
> hospital availability; are they open or closed? And I want to check on
> atropine supplies. And then in illness injury pattern recognition, I
> may want to check on a set of chief complaints related to ocular
> palsies or something like that. And the case reporting and
> investigation I want the data elements that relate to those specific
> cases.
>
> Does that make sense?
>
> \>\> It does. Are the data elements currently structured that way?
>
> \>\> Sorta.

(Laughter)

> \>\> There\'s institution data, which is more your resource monitoring
> like our ventilators in that list, I don\'t even know.
>
> \>\> The reason I\'m pushing for some of this categorization scheme is
> it relates to the HCVE work that\'s been done on identifying potential
> standards that are going to be used. So I have a motive behind that.
>
> \>\> Does (inaudible) address some of these resource issues?
>
> \>\> It\'s the HAV specification. If you think about the old NDMS
> categories that existed, I think HAV is going to basically supplant
> the MDS categories as it gets more widely accepted. But it would have
> an ability to determine this kind of resource information.
>
> \>\> Just real quickly, as a scope issue, is that kind of information
> a part of the scope of what we\'re trying to achieve here? That is,
> you know, the kind of information that HAV was trying to do?
>
> \>\> Absolutely.
>
> \>\> Okay.
>
> \>\> And then in the illness and injury pattern recognition and
> tracking category, maybe that\'s just HL7, registration statements
> that or messages that are sent across from hospital ADT systems that
> includes a chief complaint so we can drive it down to that kind of a
> level. It may also be ‑‑ it might be lab records, but having those
> categories we can drive it down. Case reporting and investigation will
> have more of the demographic detail and that could be one of our
> filtering criteria too saying that you\'re only going to put that
> through if they meet certain criteria of a reportable case.
>
> \>\> All right. I\'ll tell you one ‑‑ go ahead. Just wanted to say one
> other thing that our epis as well as our clinical care experts, et
> cetera, in here already, in addition to the chief complaints they want
> for the tracking purpose is physician notes which is in BioSense, but
> I noticed in the data elements matrix it\'s not listed under the ‑‑
>
> \>\> They found that to be incredibly important in interpreting a list
> of complaints.
>
> \>\> Absolutely.
>
> \>\> Yeah, it\'s an availability issue, because a lot of them aren\'t
> easy to access.
>
> \>\> Lynn: Yeah, we\'re getting working diagnosis. That\'s where my
> money is.
>
> \>\> Right. More of that.
>
> \>\> Yes, wherever we can get it.
>
> \>\> And that\'s something that gets entered into a registration
> system at the time of admission of a hospital from an emergency
> department. They ask us for working diagnosis and they\'ll enter that
> right into the hospital registration ADT system. So that\'s something
> you could get a fairly quick feed on.
>
> \>\> Laura.
>
> \>\> This may be too specific of a question but just curious about the
> HAV system. Is that something that is, the specification (inaudible)
> is it pulled from existing data in hospital systems or is it a manual
> daily entry feed by someone in the hospital?
>
> \>\> The second.
>
> \>\> If there\'s a hospital system that has that data in an accurate,
> and it\'s accurate, you could certainly automate the data feed.
>
> I don\'t know what Lynn\'s experience is but our experience is that
> very often good, solid, up‑to‑date information, is sitting on a
> clipboard in the nurse supervisor\'s hands and is not in any
> electronic system. So it would require her to periodically enter that
> data.
>
> \>\> Early in the context of this, because of the charge to use
> electronically enabled data. And we were talking about phased
> approaches, I don\'t want to take anything off the table but wanted us
> to keep that in mind.
>
> \>\> What we found I\'ll verify with my group is that the data exists
> probably once a day somewhere because they do a midnight census. It\'s
> not moving as HL traffic between various IT systems, but it is data
> that\'s available.
>
> What our issue right now is we get ready to display the first census
> data, that it needs to be validated for all the reasons that everyone
> has just said.
>
> \>\> Thanks, Lynn.
>
> \>\> Can I suggest that we go back to the three functions that I think
> that Dan had proposed and make sure that we\'re all comfortable with
> them, because I think he really pushed us forward by offering those.
> But I want to make sure that before we go off and form any groups and
> have them actually consider data elements by function for each
> scenario, that we\'re all comfortable with those three functions as
> described.
>
> \>\> Yes. This came from someone else, but yeah.
>
> \>\> Ed Barthell put those out. But feel free to beat me up or come up
> with better ideas.
>
> \>\> If you like them I\'ll ‑‑
>
> \>\> Can we type those on the screen on the Webcast thing?
>
> \>\> We can\'t do it in real time, sorry. We can try to do it in an
> e‑mail.
>
> \>\> Okay. That\'s fine.
>
> \>\> Just why don\'t you go ahead and give us those three again.
>
> \>\> Yes. This is availability.
>
> \>\> Ed: Resource availability. Illness injury. Pattern recognition
> and tracking and case reporting and investigation.
>
> \>\> Laura: Can you describe a little bit more about what you mean the
> second category is. I mean to me that\'s just a different way of
> potentially looking at the data, but it\'s still getting in case-level
> data and how you use that, and about how you use that data?
>
> \>\> I\'m backing into that separation with the knowledge of what the
> data sources might be. I\'m thinking that illness injury patterns may
> be syndromic type surveillance. Maybe chief complaints or working
> diagnosis. And those patterns and how they track over time as opposed
> to case reporting which is going to end up being cultural reports,
> microbiology reports of specific identification of anthrax or some
> specific organism that you need to go trace that, or actually it\'s
> transmitted to these that you want to trace or any of the more
> additional case reporting and investigation things that occur already.
>
> \>\> Eileen.
>
> \>\> Eileen: Seems one of the huge differences between the two is that
> you can do Step 2 without patient identifiable data, and you can\'t do
> Step 3 without it.
>
> \>\> That\'s right.
>
> \>\> Correct.
>
> \>\> Perry: So does #3 refer to the data elements that we will need
> public health in order to go back and identify the patient, is that
> the idea behind it?
>
> \>\> Some way of tracking back as I read it. You can have a visit
> record number or something encrypted. Doesn\'t have to be identified
> data but something that allows you to track back to DHI.
>
> \>\> Okay.
>
> \>\> Could we touch on a point we were discussing earlier, this is
> Eileen again, I think it was Lynn Steel made the Community about it\'s
> important to know where illness is not as well as where it is. And I
> think that may also be something we\'re going to have to look at these
> things carefully for in terms of our data elements as well in terms of
> what is the denominator you\'re using to conclude that illness isn\'t
> there. Because simple lack of positive reports for something doesn\'t
> necessarily mean it\'s not there because it could be that the system
> is so swamped that, you know, the reporting has been disrupted.
>
> \>\> So I think that may lead us to another area we\'re going to have
> to consider in terms of the dataset. If the data are only there if
> they\'re entered as part of a normal course of care. So you\'re right
> in a huge search would it change the way information enters possible
> IT systems. I don\'t think that\'s specifically what I meant as much
> as if there\'s an exposure, a few cases and then a bunch of people
> prophylaxed, knowing where you\'re not seeing additional cases or in
> the case of the large pandemic flu scenario, you can think through,
> there\'s a wave of a lot of disease, people will be able to visualize
> or see it\'s packed. There\'s demonstrated results of this during the
> SARS outbreak at the Hong Kong hospitals, the health records they
> could actually make economic decisions and (inaudible) based on
> knowing where there was no longer disease.
>
> \>\> Marty: What specific data more population based? Enumeration
> (inaudible).
>
> \>\> I think it was (inaudible) ambulatory care, the specific
> (inaudible) ‑‑
>
> \>\> Or for Eileen\'s perspective, seeing the overall activity at a
> laboratory and recognizing that the activity has not weighed into the
> category the case number.
>
> \>\> What the CR numbers, it\'s that yes you can really conclude that
> the thing that you\'re looking at is (inaudible) as opposed to you\'re
> just not getting the data from the entity.
>
> \>\> Is that a separate issue? Is that data validity tracking? Or does
> that sort of fall into these three functions?
>
> \>\> Marty: It\'s still pattern tracking.
>
> \>\> It falls into the three functions. It\'s something we might keep
> in mind as we look in the individual data elements.
>
> \>\> Illness pattern recognition and tracking would imply validation
> of the source in some ways. It\'s a type of validation.
>
> \>\> Think of a nerve agent release scenario. Lynn may want to look at
> prevail lens of eye problems as complaints in emergency departments,
> and she knows there\'s a release of botulism in one city and she sees
> the eye problems pop up. She just checks for other cities real quickly
> to see there wasn\'t a simultaneous release of botulism in four cities
> and see botulism hasn\'t popped up. Is that ‑‑
>
> \>\> That kind of rule out analysis is only as good as the population
> coverage of the data.
>
> \>\> Sure.
>
> \>\> That\'s exactly where I think we\'re going. Laura, go ahead and
> tell me what I said wrong.
>
> \>\> No, I just want to clarify that we\'re not just talking about
> aggregate numbers in support in the second category. That we\'re
> talking about how we would use the data and how we would look at it
> and that we\'re still talking about individual admission level data so
> that we get chief complaint and it\'s not aggregate coming.
>
> \>\> That was my understanding.
>
> \>\> Mine too, but I just want to make sure that the difference
> between 2 and 3 is not aggregate versus case-level data.
>
> \>\> From an efficiency standpoint, are you ‑‑ you\'re not going to
> get let\'s say it\'s quest, are you going to want every test that gets
> done at quest or are you going to want to know daily a test
> (inaudible) or something like that, or do you want to keep a couple of
> surrogate tests that can be used as a determiner of activity within
> that lab? Because for let\'s say you want ‑‑ you could check to see if
> they don\'t have eye problems in some other city but to know that
> that\'s not a reflection of their whole health care system being shot
> down because of the same biologic problems, how do you know that
> there\'s ongoing activity that will validate that your eye problems
> are low.
>
> \>\> I can actually give you a real example of how this sort of thing
> happens because you\'re getting data from a whole lot of sources, and
> unless you\'re monitoring subsets of what\'s coming, you know you
> can\'t always know do you have everything, because you don\'t know how
> much you were supposed to get. And so we had a case where we were
> doing an analysis and we had a site had nothing for a particular
> disease we thought how odd is that. The more we looked we finally
> discovered their microbiology subsystem had been swapped out and they
> stopped sending us data for microbiology altogether. So we had to get
> that fixed. But initially it looked like oh, no, there was nothing in
> that region to be concerned about, but that was not the case at all.
>
> \>\> But to answer that question, do you have to have everything about
> microbiology or the aggregate or daily?
>
> \>\> You don\'t have to have everything about it but you have to
> figure out what are the, what are the numbers that you need to be able
> to track on a reasonable level, yeah, this is kind of the running rate
> that we expect for admissions or whatever or tests and it\'s within
> bounds of what we expect. So we can reasonably conclude that this is a
> real negative as opposed to we\'re missing stuff.
>
> \>\> Well, I think that\'s one of the more important functions of how
> we monitor this data, is if you see a real change in the data stream,
> it could be that there\'s a lot more people presenting or it could be
> that somehow there\'s duplicate records, you know, something failed
> and the same on the negative side. That if all of a sudden you\'re not
> seeing any data, of course then you\'re not going to see that specific
> syndrome on these that you\'re looking at. So one of the first things
> you have to do when you\'re monitoring is to understand the volume and
> how it\'s different than it might have been 2 days ago. Or that time
> period, et cetera.
>
> \>\> Maybe I should rephrase Categories 2 and 3 and it might clarify.
> And say second category is syndromic type data and third category is
> specific-type data like microbiology, culture results.
>
> \>\> But all that data gets put into syndromes, still individual data.
>
> \>\> They\'re going to get interlinked.
>
> \>\> That makes it worse.
>
> \>\> Makes it worse?
>
> \>\> I think it\'s two categories.
>
> \>\> Maybe that\'s true. Maybe it\'s just resources is a category and
> clinical events is the other category.
>
> \>\> Perry: I think there are two categories. And again the second
> category I think would be the recognition of patterns based on chief
> complaint or discharge diagnosis or lab requisitions. You don\'t need
> a whole lot of information to put them into syndromes and to track
> trends that we\'ve been talking about. The third one, though, requires
> a different type of data element. And that requires that linkage to
> something that would identify a particular medical chart.
>
> So as we think about the minimum dataset, I think 2 and 3 are
> different in the data elements that we would be collecting.
>
> \>\> Perry how do we know when 2 doesn\'t go into 3 and we have to go
> back on those people that were reported in the second group. Don\'t we
> just want to have the ability to do that, go back and look when we
> need it
>
> \>\> Perry: That\'s right. I think when we review the five scenarios
> and the minimum datasets, we need to make sure that all three of these
> categories are covered. I think I\'m agreeing but ‑‑ yeah.
>
> \>\> We need them on all the records that are submitted.
>
> \>\> You need a way to backtrack on the data submitted for the second,
> the second function.
>
> \>\> That\'s right.
>
> \>\> I don\'t think we\'re disagreeing.
>
> \>\> Marty: And in the data elements matrix, is that the notion of the
> randomized data linker? Is there any other back tracking people are
> thinking about?
>
> \>\> Yes. The concept there, Lynn, you can help, is that the linker
> remains at the data provider, as public health investigation you can
> go back to the data provider and get that linkage, but it doesn\'t
> reside anywhere outside of the data source.
>
> \>\> Marty: In terms of keeping things moving along, perhaps I can
> summarize I hear consensus we\'re going to work towards looking at the
> five scenarios. Three levels of I\'m not sure if they\'re functions or
> sort of meta data categories that people are thinking about in terms
> of evaluating, using those as categories really for ability to
> evaluate the minimum datasets. And that that work would be done by off
> line here by both committee volunteers and staff with other experts
> involved. Is that the direction we\'re headed?
>
> \>\> That\'s what I\'m hearing, Marty.
>
> \>\> Marty: Okay.
>
> \>\> That\'s what I\'m hearing.
>
> \>\> I thought I saw the heads nodding. Okay. Other advice to the
> group that we need to give to staff or other volunteers to help in
> that process and when do we need it? And when is it feasible to get
> it?
>
> \>\> Dick: When is our next meeting?
>
> \>\> That\'s something we\'ve been working on. I think Scott Holter
> has been in touch with all of you by e‑mail or phone or both, and we
> haven\'t heard from I think six of you related to your availability in
> July, but in talking to the Co‑chairs previously about our meeting
> schedule and what would be realistic, we thought that meeting every 2
> weeks would be a good, ambitious goal given that it\'s the summer
> months and we have the NACCHO meeting coming up, among many other
> commitments. So we thought the week of July 17 would be a good week to
> shoot for that would give us 2 weeks to get the work done and come
> back to the group with. So it might be helpful for anyone who has
> access to their calendar now to respond to a couple dates I think
> Scott\'s already identified that might work.
>
> \>\> We\'ll probably wait for Lynn to confirm this, but ‑‑ here she
> comes. Since she\'s in the room. But I\'m looking at the Wednesday the
> 19th and Thursday the 20th. I know Steve that you said you were on
> vacation but you were willing to call in. Dr. Melton, I know you have
> indicated between 8:00 and 11:00 you\'re available or 10:00 to 8:00 on
> Thursday. Mark Rothstein who is not here today indicated he\'s
> available all day both those days, as well as Dr. Barthell. So Eileen,
> I think I have you before 3:00 as well as Thursday after 12:00 noon.
>
> \>\> Thursday I could actually probably do almost any time. I have a
> one hour meeting I could probably get out of.
>
> \>\> Scott: Okay. So the 19th and 20th.
>
> \>\> Either-or. Dr. LaVenture look for either of those days.
>
> \>\> Thursday the 20th will work. The afternoon of the 19th would be
> better.
>
> \>\> Scott: All right.
>
> \>\> Are we getting consensus around the 19th, then?
>
> \>\> The 19th?
>
> \>\> At about what time now?
>
> \>\> In the afternoon.
>
> \>\> East Coast.
>
> \>\> Just so you know, this is Perry. I would not be able to do it on
> the 19th until 2:00. I couldn\'t get on at one.
>
> \>\> Let\'s try from 2:00 to 5:00.
>
> \>\> That works.
>
> \>\> 2:00 to 5:00 East Coast time?
>
> \>\> Perfect.
>
> \>\> Art: I\'d have to leave at 4:00 East Time.
>
> \>\> Who was that?
>
> \>\> Art: This is Art.
>
> \>\> We can talk fast.
>
> \>\> Do we need 3 hours?
>
> \>\> You know, we shoot for 2 hours and do a lot of good careful work
> over the next 2 weeks. And hopefully get whatever we come up with to
> the group in advance of the meeting so there can be some review time
> beforehand.
>
> \>\> Marty: I would favor that to give that a try for the 2 hours. So
> 2:00 to 4:00 on the 19th is what I\'m hearing?
>
> \>\> Laura: I\'m just a little worried about that being Wednesday.
> This being Friday. And giving any time for review means we have to get
> something out by next Friday and can we really get experts convened to
> do some of the scenario work in those five business days.
>
> \>\> That\'s my biggest problem as well, with the two groups that I\'m
> talking about typically it takes them a week just to get on their
> calendar.
>
> \>\> Right.
>
> \>\> The other option is to try to convene that next week but then
> we\'re bumping into another meeting.
>
> \>\> Yeah, we\'ve got if NACCHO \'06 meeting the following week.
>
> \>\> Although most of you responded and said you weren\'t obligated. I
> don\'t know if those who are going could potentially call in for 2
> hours.
>
> \>\> I could do that on the 26th. That would work.
>
> \>\> Art, are you going?
>
> \>\> Art: I am going. I\'m just looking at the 26th to find a time
> when I\'m not scheduled.
>
> \>\> That\'s Thursday, right?
>
> \>\> No, that\'s Wednesday.
>
> \>\> Wednesday the 26th.
>
> \>\> So am I hearing do we want to meet the following week after the
> second meeting?
>
> \>\> I don\'t know if we\'re talking about after a second meeting but
> rather postpone the second meeting to the following week. Isn\'t that
> what\'s on the table now?
>
> \>\> Yes, it is.
>
> \>\> The afternoon of the 26th is currently on the table.
>
> \>\> Kelly, are you okay with that?
>
> \>\> Kelly: Say that again.
>
> \>\> Postponing the next meeting of this group until the 26th.
>
> \>\> Kelly: I think if we can get a lot of good work in the interim
> that\'s probably the best thing to do. And we have another public
> meeting that day but I think it ends at 3:00. So would 3:00 to 5:00
> work for folks?
>
> \>\> Dick: That\'s actually a better date for me than others.
>
> \>\> This is Wednesday, July 26?
>
> \>\> So we\'re not meeting convening at NACCHO, because not enough
> people are going?
>
> \>\> Yeah, it\'s not easy.
>
> \>\> Good, I\'m not going.
>
> \>\> We wanted to make it easy.
>
> \>\> I have to be here again on the 26th.
>
> \>\> I\'ll try to get a room for us so we can do it on a conference
> phone.
>
> \>\> Is that Paula?
>
> \>\> That\'s three to five eastern daylight time?
>
> \>\> Yes. On Wednesday the 26th.
>
> \>\> Right.
>
> \>\> Ed: Okay. This is Ed Barthell. I can try to get a mapping of
> existing HCVE work and ASTAP has done a lot of work in ERs what kind
> of systems are out there and what prevalence so we have matrices that
> show what type of data elements that might be both feasible and match
> up with standards and I\'ll try to get that done this next week.
>
> \>\> Okay. Great. Thanks, Ed. That will probably be most relevant when
> we get to the point of doing some of the feasibility assessment.
>
> \>\> Ed: Great, thanks.
>
> \>\> Steve: This is Steve. I could do the same for matching up those
> tier two requirements for laboratory data with what we are currently
> having available in HL7 various versions across the country. Maybe
> again when you do the validation.
>
> \>\> Okay, great. Thank you.
>
> \>\> Art: Excellent we have the date Wednesday the 26th, 3:00 to 5:00
> Eastern Standard Daylight Time. And we have on the list three things
> that I\'m aware of and maybe there\'s some others. Updated or start on
> draft terms and definitions. Updated scope documents that includes
> some of the assumptions, more detailed to the Step 1. And the third
> will be really the work of this off line activity that will map the
> scenarios to the minimum datasets using the three metadata categories.
> And we\'ll be reviewing that at the, as part of the agenda for that
> meeting. Is that anything else? Is there anything else?
>
> \>\> Good.
>
> \>\> One other question, was that Scott?
>
> \>\> Marty: This is Marty.
>
> \>\> Marty, did anyone want the copies of the national planning
> scenario PDF document that I have here?
>
> \>\> Yes, please.
>
> \>\> Circulate that, yes.
>
> \>\> Okay.
>
> \>\> If you send it to me I\'ll go ahead and zip it up and send it
> out.
>
> \>\> Okay.
>
> \>\> Scott: This is Scott.
>
> \>\> I\'ll send it to you, Scott.
>
> \>\> Marty: Scott, did you have anything else on your list we should
> be bringing forward to the next meeting?
>
> \>\> Scott: As of right now, no.
>
> \>\> Marty: Okay.
>
> \>\> Kelly: I want to confirm do we want to make sure everyone is
> comfortable with the final definitions of the functions before we ask
> these other groups to convene, maybe by e‑mail we can just send those
> around and get people\'s, you know, any edits so we can finalize that
> with, you know, greater level of certainty on what we\'re talking
> about.
>
> \>\> Marty: I think that\'s a good idea if we could work via e‑mail in
> the interim here. Is everyone comfortable with that, feedback on sort
> of working drafts that Scott\'s and others have put together?
>
> \>\> Let me just be clear about these functions. Did we decide that
> there are two or three, and if it\'s just two, do we need to clarify
> the assumption that there is a look back capacity in these anonymized
> datasets?
>
> \>\> Again, I think based on the way we\'ve been thinking about
> situational awareness and patient-level data, multiple uses that
> include managing or providing that picture of the community in real
> time, characterizing an outbreak, confirming or refuting an outbreak
> and showing appropriate decision making for public health. So I just
> think there really are only two categories. There\'s utilization and
> there\'s clinical data. And that we use that data across a spectrum.
>
> \>\> So I guess I think it was Kelly who asked, can we work on this
> electronically within the next couple of working days so that we can
> get it out to these other groups to look at. And I think we can,
> Kelly, if that was you asking the question.
>
> \>\> Kelly: It was, yes. Thank you. So I guess what we could maybe do
> is even try to summarize what we heard today, describe the two
> categories and get some specific feedback via e‑mail on what we tried
> to summarize from the conversation.
>
> \>\> Just to revisit the issue of the public health functions I
> brought up earlier. There is a document from the Public Health Data
> Standards Consortium that cross‑maps the HHS activity on the
> electronic health record that was occurring at HL7 that maps that to
> the essential core functions of public health and essential services
> of public health. Folks want that document?
>
> \>\> There\'s a lot of work that went into that.
>
> \>\> Is that a reasonable thing for us to just simply review, because
> there are use cases and all kinds of stuff in there that I think are
> very relevant to what we\'re trying to do. But I\'m not sure that ‑‑ I
> don\'t want that to derail any kind of activity we\'re doing, though.
>
> \>\> I don\'t think we\'ve looked at that alignment specifically for
> biosurveillance. I think that would be helpful.
>
> \>\> Yeah, I mean because they put a lot of high level thought into
> it. And maybe we have a real world opportunity to, you know, test some
> of it. So ‑‑
>
> \>\> Again, if you send that to me I\'ll go ahead and include that in
> the zip file and just compile everything into one file there.
>
> \>\> Okay. It\'s attachment five in this document I\'ll send you.
>
> \>\> Okay. And what I\'ll probably do, this is Scott again, I\'ll
> start some of the e‑mail threads so that we can just let the
> discussion flow via e‑mail and just get it rolling.
>
> \>\> Marty: Sounds great, Scott.
>
> Other next steps. The only other item is whether we want to reserve
> some time into August and at one time Kelly you talked about a
> face‑to‑face meeting potentially, sort of with the calendar. There\'s
> a sense of urgency here, but I don\'t know if we\'ve got all the dates
> identified for when we should do that.
>
> \>\> Kelly: You\'re right. And in drafting this Scope of Work specify
> a couple of dates. I mean as Ed Barthell knows best the HCVE is going
> to be finalizing their work in August. We have only maybe about a four
> to 6‑week period to have some public discussions that might, you know,
> indirectly inform their work. I mean our formal process has to go
> through the American Health Information Community and be recognized by
> if Secretary and acted upon by HHS for us to take any formal action
> internally. But certainly we\'re having public meetings, and HCVE to
> date has been learning from our workgroup process because everything
> we do is public. So I guess it\'s possible that if we have a really
> good meeting on the 26th of July that starts to identify either new
> data elements or takes away data elements that really aren\'t
> necessary, then that may in fact help the HCVE deliverable in
> September. But you know I think realistically we have to work as fast
> and as careful as we can, based upon everyone\'s availability. So I
> guess we just need to hear from all of you to make sure that we\'re
> scheduling dates that work for the majority of the group. And I think
> at this point Scott hasn\'t heard back from all of you but maybe you
> could tell them what you need at this point.
>
> \>\> Scott: What I will do is I\'ll send you a spreadsheet and maybe
> we can start filling that out, rather than individually calling and
> that way I can surmise what the best next meeting is or whether you
> can do it in person.
>
> \>\> Sounds good.
>
> \>\> Kelly: We\'ll try to get that nailed down for the next couple of
> months. Because we don\'t want to have to come back to you for several
> requests. We\'ll try to get a meeting scheduled together as soon as
> you all get back to us.
>
> \>\> Should we be scheduling a second meeting after the 1 on the 26th
> now?
>
> \>\> Sure. If we can do it now it would be great.
>
> \>\> Scott: Do you want to skip a week after that?
>
> \>\> I think so, yes.
>
> \>\> Marty: Are we looking at the week of the 14th?
>
> \>\> Scott: No the week of the 7th, I think it is.
>
> \>\> Week of the 7th.
>
> \>\> Wednesday morning is great for me.
>
> \>\> That works good for me, too. This is Ed.
>
> \>\> Dick: I will be unavailable that whole week.
>
> \>\> What day are you looking at?
>
> \>\> The 9th.
>
> \>\> Marty: I can make that work.
>
> \>\> Eileen: That works for me.
>
> \>\> Perry: Works for me except for 1:00.
>
> \>\> Bill: Works for me.
>
> \>\> What time are we looking at? In the afternoon?
>
> \>\> In the morning.
>
> \>\> Morning, yes.
>
> \>\> Yeah, I have two meetings I\'m supposed to be doing in the
> morning.
>
> \>\> Would early morning say 9:00 a.m. start?
>
> \>\> Dan: I have meetings from 9:00 through noon. But you can meet
> without me if you need to.
>
> \>\> How about the 8th?
>
> \>\> Tuesday?
>
> \>\> Yes.
>
> \>\> Tuesday the 8th.
>
> \>\> In the afternoon?
>
> \>\> Clear for me.
>
> \>\> Afternoon would be great.
>
> \>\> That would be better.
>
> \>\> Afternoon works for me, too.
>
> \>\> Afternoon, that three to five slot.
>
> \>\> If you can move it a little earlier, I\'ll be flying that late
> afternoon.
>
> \>\> One to three.
>
> \>\> Would two to four slot be better, Ed.
>
> \>\> I\'m flying back from your area, Art. I think it\'s a 4:00 or
> 5:00 flight, Colorado time.
>
> \>\> You need to head to the airport. So that would be 12:00 to 2:00
> our time if we did it 2:00 to 4:00 on the East Coast.
>
> \>\> Right.
>
> \>\> Would that work for everybody?
>
> \>\> Yes.
>
> \>\> Yes, that\'s fine.
>
> \>\> Okay. August 8,, 2:00 to 4:00.
>
> \>\> August 8, 2:00 to 4:00 East Coast, right?
>
> \>\> That\'s correct.
>
> \>\> Can I have your availability to meet in person here in
> Washington, DC, the week of the 21st through the 25th.
>
> \>\> Stan: I\'ll be doing clinical time for 2 weeks August 21 through
> whatever that 2 weeks is.
>
> \>\> That\'s Stan.
>
> \>\> I\'ll be on vacation out of town for those 2 weeks.
>
> \>\> I\'m gone, too.
>
> \>\> We\'ve already got two.
>
> \>\> I guess the rest of us get to make all the decisions.
>
> \>\> Or assign the work.

(Laughter)

> \>\> I\'m hearing no objections other than the three that were raised
> from Kelly or Dan or Ed. Correct?
>
> \>\> Yeah, Wednesday afternoon through Thursday afternoon is bad for
> me that week but otherwise I\'m okay.
>
> \>\> Perry: I can\'t do it.
>
> \>\> I thought I heard Eileen say she couldn\'t.
>
> \>\> Eileen: I\'m okay that week.
>
> \>\> We\'re probably going to run into nonquorum issues. Let\'s try
> the 28th through the 31st.
>
> \>\> You\'re still gone?
>
> \>\> Yes, that\'s bad for me, too, Ed.
>
> \>\> Perry: Bad for me, too.
>
> \>\> You folks aren\'t even in Washington.
>
> \>\> What about the first week in September there?
>
> \>\> That\'s the holiday.
>
> \>\> That\'s just Monday.
>
> \>\> That\'s a holiday.
>
> \>\> The rest of the week works.
>
> \>\> The rest of the week is empty.
>
> \>\> Marty: That week works for me, but Friday is out.
>
> \>\> Art: Works for me, too.
>
> \>\> Bill: 6th, 7th and 8th works for me.
>
> \>\> The 7th seems to be the best.
>
> \>\> 6th is better. 7th evening I\'m supposed to be back here.
>
> \>\> The next Community meeting is the following Tuesday. Is there
> going to be ‑‑ do we know if there\'s going to be anything expected
> from this group for that September 12 Community meeting?
>
> \>\> Very good question. I think actually we would be ‑‑ it would be
> best for us to try to even report some preliminary recommendations to
> the Community then if we want them formally recognized. So it may not
> be our complete work, but anything that we have that we\'re
> comfortable with at that point to share it would be best for us to
> share it.
>
> \>\> You\'ll have to have it done before that week before.
>
> \>\> Yeah. So that\'s the challenge.
>
> \>\> I guess I was just backing up to potentially the week of
> August 14, which I\'m not sure people will think we have enough to do
> or talk about.
>
> \>\> Or the time in between, yeah.
>
> \>\> Can we meet by phone by on the 8th should we have enough to do to
> meet in person the next week if that was doable.
>
> \>\> If we did it towards the end of the next week.
>
> \>\> I think so. Everyone goes on vacation.
>
> \>\> Dan, you didn\'t get out of it after all.
>
> \>\> We\'re looking at August 17 or 18 potentially?
>
> \>\> In DC?
>
> \>\> Yes.
>
> \>\> Okay. I\'ll have to check. I\'ll be leaving on the weekend prior
> to the 21st.
>
> \>\> Marty: That week works for me.
>
> \>\> Who are the ones that cannot meet that week.
>
> \>\> The 17th and 18th in particular.
>
> \>\> Should we hold those days until we can all confirm?
>
> \>\> Yeah, the 17th and 18th?
>
> \>\> Yes.
>
> \>\> One day meeting?
>
> \>\> Yes.
>
> \>\> I\'m good for the 17th and 18th. Bill.
>
> \>\> We\'ll hold them.
>
> \>\> Okay. All right.
>
> \>\> Sorry to break in and interrupt, guys, should we give
> instructions for public input while you\'re getting this information
> down?
>
> \>\> I defer to the Co‑chairs to determine whether or not we think
> we\'re ready to wrap up now.
>
> \>\> Marty: Any other issues from the committee members here that we
> need to be working on between now and the next meeting?
>
> \>\> Eileen: There was one ‑‑ this is Eileen. There was one thing I
> wanted to mention. As we look at these data elements, most of the
> elements are actual raw data, if you will. Other than the randomized
> data linker, which is something and that might not be the only one,
> but that one for perhaps reasons that will be obvious jumps out in my
> mind as something that would have to be constructed and maintained by
> the data providers using technology that they may not have in place to
> do that. And so as we\'re looking at these data elements, I think we
> ought to be careful to differentiate when we think in terms of real
> necessity between things that are sort of end raw data and things that
> require creation.
>
> \>\> But there has to be some way for public health to link back to
> the individual or there\'s no sort of point.
>
> \>\> No, no, I\'m not saying, I don\'t disagree with you, but in terms
> of it being an actual data element like this, you know when we\'re
> talking about what we can accomplish in a year, I would strongly
> suspect there\'s probably no data provider that can create such a
> thing very easily, you know, without quite a lot of retooling. I know
> for a fact that we cannot. And so it\'s something that can go in as a
> goal for a longer term strategy, but I think you really have to think
> about what you can expect short term when you\'re talking about data
> that has to be generated as opposed to that\'s going to be reported or
> in somebody\'s system anyway.
>
> \>\> Marty: Is that something we want to perhaps note in the
> assumption but also deal with in our feasibility, our Step 4?
>
> \>\> Yeah, but I think also as we look at ‑‑ I didn\'t want to bog
> this down in the feasibility of getting all the information, but in
> terms of that or and as I said a look through and see if there\'s
> anything else that at least looks to me like something people have to
> create, we might have to class those a little bit differently as
> we\'re looking at the feasibility of getting them.
>
> \>\> Marty: Great. Good comment. Other suggestions or notes for the
> work between now and the next meeting?
>
> Feedback on this call or the work so far from folks? I really
> appreciate all the thoughtful comments that people have provided with
> having gotten the materials, getting up to speed overall has been I
> think and wrestling with sort of the phone conversation, I really
> appreciate everyone\'s careful and thoughtful perspective on many of
> these issues, and moving the whole agenda forward. I thought we did
> make some progress in terms of the process here.
>
> \>\> Chris, are you still on the phone?
>
> \>\> I am.
>
> \>\> Would you like to take public input?
>
> \>\> Was that a confirmation of opening it up to public comment?
>
> \>\> Marty: It is unless anyone else has any other comments.
>
> \>\> Art: I just want to echo Marty\'s thoughts here. As we started
> the call or driving to work I was concerned how far we would get but I
> thought we got farther than I first anticipated. I want to thank you
> all for chiming in and giving good thoughts and ideas about how we can
> move this forward. And I\'m optimistic.
>
> Thank you, I think we can move to the public comment at this point.
>
> \>\> All right. If we have any members of the public who would like to
> make a comment and are already dialed in, all you need to do is press
> Star 1 to get queued up for a question and we\'ll see that. If you\'re
> following along and listening on the Web, if you just look on the
> screen, will you see a slide with instructions on how to make a
> comment or ask a question. Just dial in the number that\'s on the
> screen and once you\'re connected, just press Star 1 to ask a
> question.
>
> If you guys have any scheduling issues you want to firm up while
> people are dialing in, feel free to do that. We\'ll let you know as
> soon as any questions are queued up.
>
> \>\> Art: I want to confirm the things that we\'ll be receiving. I
> think from Ed there\'s a letter from Dr. Frieden from New York, is
> that something we\'ll be receiving as well.
>
> \>\> Sure, we can definitely share that. I think it will be important
> to put it in context, because he was responding to a public
> conversation that we had probably four months ago or three months ago,
> and it may not be directly relevant to what we\'ve been discussing
> today.
>
> \>\> Art: Another item that came up that Lynn mentioned was the latest
> version of the data elements that BioSense is expecting. I don\'t know
> whether that\'s something that we should circulate as well to the
> group.
>
> \>\> We certainly can. And the other piece on my to do list is to find
> our most current definition of situational awareness. In the context
> of BioSense.
>
> \>\> Sure.
>
> \>\> Marty: Mentioned the public health updated standards consortia
> document as well linking to the electronic health record, making it
> available.
>
> \>\> I sent that to Scott.
>
> \>\> Marty: And there was the actual list of all of the 15 scenarios
> at some point. Maybe they\'re available, the links to those if
> they\'re available. It was mentioned also. And what else were we
> queuing up?
>
> \>\> The glossary and the Statement of Work.
>
> \>\> Scott, you\'re the clearinghouse for all of these documents; is
> that right, if we send them to you, you forward them to the group, is
> that how you want to work this?
>
> \>\> I think that would be best.
>
> \>\> Doesn\'t seem like there\'s many public comments.
>
> \>\> At this time we have nobody queuing up for questions. And
> operator is telling us we have nobody dialing in. If you guys want to
> wrap it up and conclude, go ahead.
>
> \>\> Marty: Art?
>
> \>\> Art: Once again I want to thank everyone for participating today.
> I look forward to our next call. And we\'ve got a lot of work ahead of
> us, but it sounds like we have a good plan, and I\'m confident we have
> the right people on the team. So thank you all for the call this
> morning. Shall we pass it back to Kelly or Marty, any other last
> comments?
>
> \>\> Marty: I concur with Art and thank you all again, and yes we\'re
> ready to pass it back to Kelly.
>
> \>\> Kelly: Thanks. I just want to thank all of you for being so
> responsive over the last few weeks. We had to pull this together very
> quickly. And I think we\'re also within OSC and HSS really happy we
> have such great experts across public health to participate in this
> process. And even though we have an incredibly ambitious time line,
> and we recognize how busy you all are, we really do appreciate you
> making the time for this, because we think it really will be an
> important contribution to our efforts and hopefully your efforts
> moving forward. So thanks again for your time and your willingness to
> make this a worthwhile effort.
>
> \>\> Marty: Thank you Kelly.
>
> \>\> Art: We\'ll be speaking with you in another couple of weeks.

\>\> Thank you.