Skip Navigation

Skip Navigation

American Health Information Community

Population Health and Clinical Care Connections Workgroup Meeting #18

Friday, June 15, 2007

Disclaimer

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

>> Laura Conn:

Good morning, everyone. This is the 18th meeting of the Population Health and Clinical Care Connections Workgroup. This is Laura Conn from ONC. I just want to remind everyone that this Workgroup runs under the auspices of the Federal Advisory Committee Act, and therefore is being publicly broadcast over the Internet, recorded, and will be transcribed for later access on the AHIC Website. And with that, I'll turn it over to John Lumpkin, the co-chair for this Workgroup.

>> John Lumpkin:

Good morning. Do we need to do a call-in procedure?

>> Matt McCoy:

Yeah, I can handle a few more things that Judy usually does. So in addition to everything that Laura just mentioned about the FACA guidelines, I'll remind all the Workgroup members, those at ONC and those on the phone, to please identify yourself when you do make a comment, so that we can attribute everything correctly in the transcript. And for those members on the phone, especially, please speak loudly and clearly. And if you're not speaking, keep your phone muted so we cut down on any background noise that gets into the conference call.

I'll quickly read off the names of those members on the phone, and then I'll let Workgroup members in the room introduce themselves. Calling in for the meeting today we have Captain Richard Haberberger from the Department of Defense. Laura Conn from ONC, Lisa Rovin from the FDA, and Theresa Cullen from the Indian Health Service. Are there other Workgroup members on the phone whose names I did not just read? Okay, I think that does it for me, then.

>> John Lumpkin:

Okay, why don't we start off, then, with introductions. My name is John Lumpkin, I'm with the Robert Wood Johnson Foundation, I'm one of the co-chairs.

>> Scott Becker:

I'm Scott Becker, I'm with the Association of Public Health Laboratories.

>> Sunanda McGarvey:

I'm Shu McGarvey, and I'm the lead staff for this Workgroup, I'm a contractor to ONC.

>> Art Davidson:

I'm Art Davidson from Denver Public Health Department.

>> Brian Keaton:

I'm Brian Keaton, president of the American College of Emergency Physicians.

>> Angela Fix:

Angela Fix of ASTHO.

>> Paula Soper:

Paula Soper of NACCHO.

>> Jon Einbinder:

Jon Einbinder, Partners HealthCare System.

>> Amy Helwig:

Amy Helwig, Agency for Healthcare Research and Quality.

>> Greg Burel:

Greg Burel, director of Strategic National Stockpile, CDC.

>> Gary Urquhart:

Gary Urquhart, the immunization information system support branch from CDC.

>> Tom Savel:

Tom Savel, National Center for Public Health Informatics, CDC.

>> Aggie Leitheiser:

Aggie Leitheiser, director of emergency preparedness, Minnesota Department of Health.

>> Tim Wiedrich:

Tim Wiedrich, North Dakota Department of Health, section chief, emergency preparedness and response.

>> Joe Gibson:

Joe Gibson, director of epidemiology at the Marion County Health Department.

>> John Loonsk:

This is John Loonsk, I'm with the Office of the National Coordinator.

>> John Lumpkin:

John, you snuck in.

Okay, we have -- oh, good, Torney Smith has also joined us on the phone and will be presenting second.

>> Dave Ross:

John, this is Dave Ross, I just wanted to make sure you knew I was on.

>> John Lumpkin:

Great. Great, I'm glad you could join us.

Two things. One is some of the importance of the work that we've been doing at the Population Health and Clinical Care Connections Workgroup can be symbolized for some of the discussion that we're going to have here today. I'm reminded often, when I was a State health director, that public health used to remind me of Kevin. Some of you may remember Home Alone 2, there was this great scene where they had landed in the airport in Miami, and they passed this bag from mother to father, and said give it to Kevin, and from father to aunt, to give it to Kevin, and it went all the way down the line, give it to Kevin, and got all the way to the end, and the kid said, well, Kevin's not here. At which point the mother faints.

Well, you know, the public health system kind of is like Kevin. You know, they always expect it's going to be there. And certainly, those people -- I don't need to tell that to the people here in this room that we're -- you know, the care and feeding of the public health system is really essential.

And yesterday I was in a meeting of Connecting for Health, and one of the vendors commented about how, as we were having a discussion about population health, about how difficult it's going to be to build public health interfaces in. And I responded, well, not if we think about it in the beginning, when we're building the system. And that was for him an a-ha moment, and I described a couple of ways that it could happen.

So the work that we do here in this Workgroup, while it seems like, you know, sometimes when there's a small group of people in the room and we don't get our use cases to be, you know, the top priority, but it's one of the priorities at AHIC, the fact that we're raising the public health issues at this point in the development of the national health information technology development process, is extremely crucial.

So today we're going to talk a little bit about response management. And this is an important component of the interface between the public health emergency response system, and its impact upon the clinical care system. The kinds of things that we all hope will never happen, yet we plan because we know they will. And with that, we're going to turn it over to Scott, if you've got any opening comments. Our subgroup chair.

>> Scott Becker:

Just very briefly I want to thank the group for the opportunity to participate. And I think that the first testimony that we heard a few months ago was, was really excellent, and we're expecting to hear additional excellent testimony today. It seems at times that we just meet periodically, but there's a lot of work that goes on in between meetings, by a lot of people, and I think it's really important to recognize that.

John, one of the things you said really struck a chord, which is that I think the general public believes that all the things we're talking about are already there, which makes it more difficult for us to actually make the case for the resources or the need, simply because they know they can go to an ATM anywhere in the world and get money. Well, why can't we have data interchange? I think we're working towards that. I know that bills are furiously being created up on Capitol Hill that potentially may address some of the issues. We don't get into that in this group, but clearly I think there's great interest nationally.

>> John Lumpkin:

Great. We do have one business item before we go into the presentations. Enclosed in your packet are the meeting notes from the May 16th meeting, and we need to approve those. The motion to approve from Brian, got seconded. All those in favor say aye.

>>

Aye.

>> John Lumpkin:

Any opposed? Okay. Great.

Let's move on, we have a very full panel. We're going to have the presentations from the panel listed as in the agenda, starting off with Joe Gibson, you did hear them introduce themselves. Torney Smith, who is administrator of the Spokane Regional Health District, will be on the phone.

After the presentations by the panel, as we move into the lunch hour, we will have a break for lunch, and then we will follow with some discussions by the Workgroup. Members of the panel are invited to stay and participate if you so choose, but if you have to leave we understand. Looking at the agenda, I'm guessing that we're going to finish work early today, if we are disciplined in our work after we discuss the panel. So why don't we start off with Joe?

>> Joe Gibson:

Thanks. Again, I'm Joe Gibson, director of epidemiology, Marion County Health Department. We serve a population of about 860,000 people and include the City of Indianapolis, that's the primary population that we're serving. How do I make the slides go?

>> Matt McCoy:

We'll do it for you remotely, just say next slide, and note that there may be a little lag, but just say next slide and keep on going.

>> Joe Gibson:

Go ahead two slides forward then. One more. Up. One back, sorry. I'll be talking a little bit about what we -- the model I keep in my mind around public health response to disease incidents. Talk a little bit about some of the control measures we take routinely and the authority we have to take those, the information needs related to those, and a bit about how the information flows around between us and other agencies and clinicians. Talk a bit about some of the public health informatics projects that we have going on locally that may be of interest to the committee. And then talk a bit about my vision for public health informatics and response management in public health. Next slide.

I think the committee has already seen some framework around public health response, so I'll just make -- actually, go to the next slide. I'll just make one point around this. Some people talk about a model of detect, identify, and control. In my experience, there aren't really different phases. What we do in public health generally is we see that there might be a problem, we have some sort of signal of a problem, and then we investigate. We usually start to control immediately. As soon as there's enough evidence to indicate that there's some public health problem, we start to control while the investigation continues. It's usually the same people who are doing the investigation and the control at the same time. This is something to keep in mind as we think about information systems and information flow, that investigation and control really aren't two separate things, and identification often never even occurs. We never know what the bug is, but we've gone in and cleaned up a restaurant. Found problems, and tried to address them. Helped people address their illness, and tried to contain the spread of whatever the bug, never knowing exactly what it was. Next slide. Go to the next slide please. The -- and one beyond what's showing.

Some of the countermeasures we do routinely include intensive case management, which would include isolation and quarantine. We do this very frequently for tuberculosis patients, with monkey pox as well, we're using isolation. In some cases it's mandated, in most cases it's voluntary. Most intervention also includes contact tracing. That could be considered investigation, but it's also a means of control. We need to understand where the disease is going, we do that frequently with STDs, tuberculosis, and infectious diseases. We impose restrictions on people, restrictions on movement, restrictions on working. We may disallow healthcare workers or daycare workers from going to their job, restaurant workers from working at a restaurant, until they show signs that they no longer have whatever disease we're investigating. Sanitation measures. We will often immediately in a restaurant do an inspection, and do corrective actions, even if we don't know that they were the cause of a problem. And encouraging schools to encourage hand washing, workers with daycare to improve their sanitation measures. And almost always we're doing some education. Either general education of the population about a problem that might be affecting them, such as an outbreak at a restaurant that may be widespread, or education of the individual cases and their contacts, about the disease and how to protect themselves and how to seek care for their problem.

The intensity of our control measures depends on several things. It depends on the magnitude of the health risk. So if we've got a TB case, we may be doing observed therapy. We actually want to make sure that therapy occurs and is finished. Whereas for shigella we'd just be advising people what kind of care to get. The likelihood of successful control, the available resources is -- in pandemic influenza, if we ever have such a thing, or when we have such a thing, we're likely to do fairly intensive case control for the first several cases, but at some point we run out of resources and just be falling back to a general advisory of the public about how to protect themselves. Next slide, please.

The authorization -- we've got fairly strong authorization to take intervention and control measures in public health. In Indiana our State law authorizes various actions depending on what the disease is. Most of the actions involve what will happen in the investigation, what precautions healthcare providers need to take, whether quarantine is allowed or required in the situation, disinfection measures, how immunization -- how contacts should be treated or immunized. Next slide, please.

And locally, if you just look at the first bullet point there, the health officer is authorized to do what is reasonable and necessary for the prevention and suppression of disease. That's in our local statute. It's very, obviously a very sweeping power, and we've actually just strengthened that to clarify that it will apply in cases of sort of a widespread disease like pandemic influenza as well as specific cases like tuberculosis. So there's very strong authority for us to act if there's evidence of a public health threat. Next slide, please.

An interesting aspect of this, and this has come up in the tuberculosis case, with the fellow who traveled internationally with the treatment-resistant tuberculosis, is that, at least in Indiana you can't be legally required to follow a personal control measure unless you don't follow it. So we can tell you you need to follow it. We have to first tell you you need to do something, and then have evidence of your not doing it before we can legally require that that you do do it. It's probably based something on criminal law and how they approach things there, but doesn't necessarily make sense to tell somebody they need to do something, and only later require that they do that thing. Next slide, please. And one more.

Talking about the information needs we have around control measures. A lot of the information needs we have are probably more related to the investigation than to the control of disease. I've got some bullet points up there about the contact information, which is probably the greatest need we always have when we try -- when we have some sort of outbreak we're trying to track down people, we're trying to get contact information, we're trying to contact them to get information from them. And the greatest effort is usually just around that contact information, be it a clinical person, be it a case, be it a restaurant employee.

The clinical information, as well. Giving symptoms, onset time, laboratory samples, disease-specific information, developing a case definition, again is generally around the investigation side. But the information needs that I can see, moving toward automation on the control side, are assuring that people have received treatments, and that the treatment has been completed. Right now, the day-to-day example that comes to mind is tuberculosis, where we actually do observe the therapy, we go to all sorts of lengths to find people, to make sure that they take the medications, that they finish it. But rabies as well, making sure that somebody finishes their course of therapy. Any of these sorts of things we usually want to try to confirm or assure that the treatment has been completed, or some measure has been taken, like at a restaurant, to address some problem. Next slide, please.

The means of communicating -- the way we usually exchange information is by telephone. Most of our control measures are around -- are fairly customized. We seldom have something that's on such a mass scale that it doesn't make sense to customize our response to the specific situation. And if I -- again think of something like a TB case, what we need to do is find out where they are, find out where they're willing to meet us, so we can observe the therapy. We may have a case that's an illegal alien, and we meet them at a gas station. The nurse goes out there with the medicine, makes sure they take it, and they do that during the entire course of therapy, just to make sure they take it. So some of the control measures can be very customized. And I have a hard time figuring out how to take advantage of information systems to support those sorts of interventions.

Again, most of the information exchange is person-to-person, it's either face-to-face, by telephone, by fax. Another common information flow is the advisories that we would put out. We put out advisories to clinicians to how -- that there might be some problem in the environment, and that they should be on the lookout for it, they should make sure they're reporting it to us. There also -- or advisories out to the public about how to protect themselves from a potential problem in the environment. Next slide, please. And one more.

The committee may be aware of this, but I wanted to go through some of these things that are going on in central Indiana and some of the things that may be important to the work that you're doing. One of them is the Common Ground grant, it's the Robert Wood Johnson grant, which is going to be looking at the key public health processes in two areas, preparedness and chronic disease. Marion County is one of the six health departments nationally that's involved in the chronic disease process definition. The point of the grant is to define what are some common business processes across health departments and then define the information system needs that can support those processes. Next slide, please.

This is a list of some of the processes that we will be examining at least within Marion County, and some of these will be used in the national project as well. You can see they're fairly broad and involve lots of subprocesses within these: incident management, case management, some communication processes. So in a few years we expect to have some very well-grounded local health department system requirements, information system requirements, but it's going to take awhile to get the detail around the processes to get to those very well-grounded requirements for information systems. I get a little nervous now with us trying to move there too quickly without having a good grounding in what's actually going on in the day-to-day business in the local health departments. Next slide please.

Part of what the group is interested in is registries. We had a question, we have a question, as clinicians in Indiana renew their licenses, asking if they'd be willing to volunteer in a emergency. That data is collected by the State, and sent out to local health departments. The local health departments contact those clinicians and collect some more information from them. And in our region, in central Indiana, there are several counties we decided, well, we're all going to be looking at the same volunteers, we need to coordinate this list. So everybody sent in their list to one of the epidemiologists in my group. She's been trying to compile that. We've got data in Excel, we've got data in Access, we've got all sorts of different fields, and we haven't been able to create a useful consolidated list. So certainly standardization is going to be useful there. But also know that there are local health departments that have developed these things, please make sure you are looking at what they have considered important as you try to come up with standards for this sort of thing. Next slide, please.

We do have a, we're very fortunate to have a -- be bringing up an emergency medical services system in Marion County and Hamilton County, the total population served is going to be just over one million. It's going to be automated. The ambulances, all the ambulance systems, and there are about 20 agencies that serve the population, are going to be using the same system. And real-time, putting information into this. So there's good opportunity to take advantage of that for some of the syndromic surveillance, and we'll be putting it into our syndromic surveillance system. Next slide, please.

Within the county health department we have a really nice population health data system. We used to have a lot of little Microsoft Access databases for various programs. We now have a unified system. All the -- it all comes off of one client table, all of our population health programs use it. The challenge this presents is any other system that we bring in, any Federal systems, any registries, we want to have tied into this. We want to be able to make them interoperable with this. And we work a lot with the vendor to adapt it to our various needs. But be aware that there are these systems out there, and as you're developing standards the challenge is going to be not imposing something at the local level that makes us not use what we depend on day-to-day. Next slide, please. Go ahead to the next slide. And one more.

>> Matt McCoy:

To future opportunities?

>> Joe Gibson:

Beyond syndromic surveillance.

>> Matt McCoy:

Okay.

>> Joe Gibson:

The -- we've been using emergency department data for syndromic surveillance for a couple of years now, I guess, and as the director at the epidemiology department one of my focuses is to make sure that my epidemiologist spends as little time as possible in that system, and gets as much value out of that system as possible. It doesn't make sense to us to have somebody spend a lot of time looking for bioterrorism events. Even though they're important and it's something that we want to do, if that's all they're doing with the system I'm not very excited about the system.

So here are some other things that we're turning that system to. We're using it to assure that rabies prophylaxis has been delivered, because it happens to happen to a single emergency department in the city. We're using it to follow up on all carbon monoxide exposures. We've got a query that searches, at the State, they search for any chief complaint with exposure in it and they look at what that is and potentially do follow-up to it. We provided the interface to other hospitals and local health departments, so that more people have the opportunity to find ways to use this data. My main point is it's going to be very important to have multiple use of these systems. Not to build something that just serves one service. At the local health department we need to get as much value out of each system as we can. Next slide, please.

I'll skip over this. We're making more use of the emergency electronic laboratory reporting stream as well. Next slide, please.

And up to the one, future of public health response, next one. I've got concerns and hopes around the future of public health informatics. I'm a bit concerned about over-specification of requirements. I recently saw some requirements around security, and looking at them I'm very concerned that in the effort to comply with these requirements, we're going to stopor prevent data transfer between our State and local health department. Just because they're fairly stringent, and with personnel turnover and identifying users between the two agencies, some of the requirements are going to present some real challenges. So I'm really concerned about over-specification generally when requirements are being developed.

I've seen a lot of large systems be developed at the national level that aren't really adapted to what we do day-to-day at the local level. We've got a couple of systems that have come through that have really set us back in terms of our local operations, and it -- you know, with great intents, but without enough local input there's a lot of opportunity to do more harm than good as we move to standards and more informatics systems. Next slide, please.

But I do think there's a lot of opportunity -- there's -- I think eventually we're going to get there with public health informatics. I think if we encourage multiple-use systems as opposed to focus on single-use systems.

If we can get tools out more than sort of monolithic systems, I want to have something that has the right hooks and sockets so I can link it up to another system. I want to have a tool that I can use in multiple ways. I don't want to have a different analysis interface on all these different systems. I want to have one common analysis interface that's useful and I can apply in a lot of different places.

I think we are going to be developing new ways to be able to drill down into -- in surveillance more quickly, so we can rule out things quickly. And again, my emphasis in surveillance is to be able to rule out the problems. We get a lot of alerts, we need to figure out which ones are false, and to do that we need to get more than just a minimum amount of information. We need to get fairly rich information. Or be able to get to rich information quickly.

And again, reportable diseases, I think that's one of the near-term opportunities, another near-term opportunity in public health informatics is going to be case reporting, and being able to get more information about potentially reportable diseases, or reportable diseases from clinicians, being able to query their systems, get information back from them.

>> John Lumpkin:

Thank you. We're going to take questions after we've gone through the entire panel, and -- I mean if the speakers all adhere to the roughly 12 minute timeframe we should have plenty of time for doing that. At this time, let me just check to see if Torney Smith is on the line.

>> Torney Smith:

I am.

>> John Lumpkin:

And did you have slides?

>> Torney Smith:

I do not.

>> John Lumpkin:

Okay.

>> Torney Smith:

My responses really are to the appendix A questions that were submitted to us. And Spokane, Washington, is a community of about 400,000 people in eastern Washington State. We are a public health system that serves a region of 10 counties on the eastern portion of the State, and we have a hospital-based system that is using a computer system that links 30-plus hospitals in this region, in Idaho, and in Montana.

And so with that as a background, let me address the questions that were presented, just one through nine. In the first one, in terms of the area of response management that we address, I thought of this very much as the system, and so any of the kinds of things that are presented, whether they're local issues or things that could escalate to national significance, we feel that we are a part of the system addressing those kinds of concerns from a public health perspective.

In the general scenarios that existed in question two, looking at a possible case of emerging infectious disease that would be highly contagious and could have national importance, the data flow that would occur for us would really most likely occur originally in the hospital system, we would notify the variety of clinicians across the systems using a product that is called Ramses here, it links on a window dashboard kind of perspective all of the local hospitals, from ERs to outpatient data. Then we would also utilize the Inland Northwest Health Services e-mail system, that would be simply exchange of e-mail to selected individuals. We would look at predominantly, I think as Joe mentioned, using telephone and fax with clinicians. That really is the state of the art at this point. Though we have these computerized systems in place, it's far more likely that it's phone and fax that will continue to be used at this point in time. We do receive certain information electronically from different entities within the hospital systems, but if this occurs in clinics in the community or in individual providers' offices, again, it's going to go back and link to both telephone and fax.

In terms of something like a local outbreak, a vaccine-preventable disease on a small scale that would escalate, the response would be identical to what I just described for something that would be of much more significance, as would something such as the aerosolized release of anthrax, though I think there would be much more attention to the release of information to control population dynamics.

Under question three, on describing existing authorities and laws that permit the agencies to access data. This is a place where I find it is still enormously challenging. The hospital systems’ legal staff are very concerned about HIPAA regulations. And even when public health has a request for information that ultimately gets approved, it goes through quite a long process. And in an emergency situation, that is today an area of concern for us. That has also been the one thing that has kept Spokane, Washington, from being what we heard about for Marion County, that we do not have active surveillance information on an electronic system going at this point in time, predominantly because of the legal concerns over the sharing of the information. We are making progress on that, but it's not moving as quickly as we'd like to see. At this point, we do not have direct electronic data transmission between the hospital system and public health. They do collect data, we have telecommunications sharing of information or faxing, but we are not linked between our systems.

The question about how health information technology could enable an integrated work flow to support the activities, clearly it could go a long way in reducing the reliance that we currently have on manual exchange of information, but I don't think it's ever going to fully replace it. We have, you know, examples where an alert clinician is always going to be a better source of information, and they're going to get on the phone and call somebody as opposed to finding a way to enter data into the system. There's also I think still a number of issues that need to be addressed in terms of electronic data. Those in terms of completeness of information, timeliness, errors in coding, that sort of thing, where when you have a telephonic interchange, the clarity happens very quickly.

Under the fifth question on standards developments organizations, we are currently not aware of any that exist for the kinds of work that we're trying to do to integrate our systems.

Number six on how health information technology can best be used to improve integrated response management, I think that in this situation we have vendors and clinicians that need to work on standards and coding issues. And it was interesting, Joe, to hear your comments about your feelings that as this process moves forward, it could be more damaging than good if not done well, and I would suggest the same is true here. I don't think that it is conceivable that all communities in the way they are structured will respond the same. Our public health agency has given relationships with our hospitals, clinics, and clinicians that is probably different than exists in other communities. I think we can move through the establishment of standards to understand what that commonness is amongst us, but to be too rigid on that I think could be harmful to others while it benefits some.

I think we also need to do a good deal of work on patient identification. The challenge that I think we face most greatly in the work that is being done with our hospital systems is to integrate the monstrous databases that exist in radiology, in lab, and in in-patient hospital data. Each of those systems are very large, they use different coding structures, they use different patient identifiers. And over time it certainly would be a whole lot easier to be exchanging data if we had a unique patient identifier across the systems. And that's something that we have been talking about for years, but we are not moving closer as a community on that. I think that we need to also be able to assure that when we get distinctly different reports that we are sure that they are not referring to or, in some instances, are referring to the same patient.

On number seven, the question is about with which existing registries do you interface or augment as part of a response management. The piece that I find very interesting here is that there are several different registries that are utilized, but they're not utilized across systems. It appears that oftentimes in cases of response we develop registries on the fly, they get developed within a given discipline. So whether it is emergency response, or emergency management people, whether it is public health, whether it is the hospital, fires, or police, we seem to be building these registries, but not in ways that are readily shareable across the various systems.

The Ramses that I mentioned early on is one effort that has been utilized here to give us a windshield view, a single screen perspective that we can get a snapshot of what is going on in a variety of systems, and then drill down. And that has been quite helpful in terms of looking at issues that have already been addressed by your group, which is bed capacity and that sort of thing.

In asking the question number eight, does your jurisdiction maintain or have access to a stockpile of countermeasures other than a strategic national stockpile. Yes, we do. MMRS- and HRSA-funded caches, but they're primarily antibiotics, chem packs, hospital caches for personal and family kinds of use.

And in number nine, in the event of distribution of countermeasures, whether it's SNS or stockpile, are systems in place for tracking and follow-up? The answer would be yes, and no. Yes, there are systems available, but they are not integrated well. All the agencies with responsibility for caches would track their own utilization. So what we would tend to do in public health is primarily at this point use a paper-based system. We have a software called TeleForm that would allow us to scan all of those paper-based records into a database, but it would not happen on-site in a mass distribution kind of scenario. We would be scanning that in, and so data would be delayed to our partners by probably several days. We would also then take that data and put into it our client management system in-house, which is the Kansas Integrated Public Health software, KIPHS, but again, that would be delayed by several days.

The piece that we have not been able to yet achieve is integration across the various systems, and I think it is one that really is crucial when it comes to community-oriented responses. So in terms of Spokane, I think we have the MEDITECH system through the hospitals that is enormously powerful and helpful, it links the hospitals very well. Right now, we have the benefit of what Joe also mentioned earlier, we are participating in terms of the response component of the Common Ground grant, and we are using business process analysis methodology that the Public Health Informatics Institute teaches, to begin to talk about understanding the requirements for systems development on a common ground between all of these systems that we have that are not well integrated.

It is also a challenge for us to recognize that public health is a pretty small point of interest to hospital systems that are advancing their work. We do not provide a financial benefit to them, it is additional work that their systems do not prioritize highly at this point. We, as I mentioned, have been working for almost four years to try and integrate our software systems in the health department with MEDITECH, and though we're working on it, we aren't there yet after four years. I think it has a lot to do with the value of our system to a larger business.

Thirdly, I would suggest that public health funding is a challenge in two ways. We are under-funded, and have been for 10 to 12 years, to carry out basic core functions of public health, and so trying to find ways to advance the technology becomes a challenge between looking ahead or providing ongoing services. And that simply becomes a real stretch.

I think that another piece that I would echo from what Joe's comments were, is that we have differences in system interactions across the nation. The way that Spokane interacts is different than the way other communities interact, and I think that it is really important that as we develop tools, that those tools have the flexibility to capture data in a consistent manner, but allow for the flexibility and variability across communities.

So those would be my comments to those questions that were sent.

>> John Lumpkin:

Thank you very much. We're now going to move to the State perspective, and we'll start off with Tim.

>> Tim Wiedrich:

First of all, I'd like to thank you for the opportunity to be here, and how pleased that I am that the committee has brought folks in at the local and the State level to have these discussions with you and to be able to share this information with you. That excites me very, very much.

What I'm going to do is describe, in just small measure, one of the components of our countermeasure response that deals with people. And then in much larger measure, the stuff part of it, the way we move the things and the equipment and supplies that are necessary. And I want to preface this by saying that in a rural State, in a frontier State like North Dakota with these huge geographic distances and sparse populations, that one of the first things that we needed to get in place was in fact a network, a network that connected the entire State into a Statewide system, and then our local public health and hospital personnel were all part of the development of that system. And so to that end what was created is a wide area network that runs throughout the entire State that is secure and redundant and doesn't rely on public communication like internet or cell phone or telephone. We have had failures in large scale disasters of those types of systems, so we found it was necessary to get that foundation under the system.

From there we began basically building the types of cars or vehicles we wanted to put on this highway, so to speak. The first one I want to talk about is the integration of registries from various licensure boards. Let me say first of all that the things that I'm about to talk about have all been primarily funded by the emergency preparedness and response grants that have come from public health cooperative agreements and also through the what formerly was HRSA, now HHS, hospital grants. So that has been the driving force for what has been accomplished.

Having said that, people -- you know, nothing happens without people, and so we basically went to all of the medical licensure boards within North Dakota, we prioritized them, and actually did this over a three year process, and we're completing that process this year, to create data dumps from those licensure boards that are done on a weekly basis -- so go ahead and advance to the next slide, please.

Those data dumps are basically pieces of information that come from the licensure boards and are uploaded into our Health Alert Network system again on a weekly basis. What that does is during large-scale emergencies we have the capacity to mobilize both public health and hospital personnel through our Health Alert Network utilizing the call-back protocols, such as cell phone, telephone, e-mail, fax, and the system continues to hunt them until they respond, so we can target both geographic areas and we can target specific disciplines through that system and do those notifications.

Right now there are about roughly about 3,000 people that have pre-identified themselves, they've held up their hands and said yep, we're part of this volunteer system, we're a medical reserve corps that is on a Statewide basis. But then more importantly, in my mind, are the roughly 17,000 medical professionals that we have access, because we're getting their licensure information. Not all of it, but those parts that are pertinent to large-scale emergency responses. And we can have that information available on this network at those places where staging is done to make those assignments. So we're making sure that we're not assigning bad actors, people who have had licenses revoked or restricted, into assignments that are inappropriate.

Let me kind of now turn the page, and now talk about another kind of major component. So go ahead and advance the slide, please. And that is -- actually, advance it again. And we're going to move on into-- oh, another advancement.

>> Matt McCoy:

To operational procedures?

>> Tim Wiedrich:

Yes. I'm looking for medical and pharmaceutical access management, then the slide after that that says concepts of operation. So while the slides get caught up with my motor mouth here -- so much to talk about, and so little time. Let me move now to the next component, and that's how we handle the stuff part. And again, these are Statewide systems that are developed through close interaction with our local public health units, 28 of them, and the 50 hospitals. That network that I talked about carries both interactive video, data, and some limited voice over IP. And so we use that, frankly, on a daily basis. We gather these groups together to work out the details that are necessary through the interactive video system, and it's also a major component of our emergency response system. So during large-scale emergencies, what occurs is that system is activated, we physically bring the hospitals, all of them, the public health units, local level, all of them, the State laboratory, our State emergency management system onto video conferences to either share the specific incident objectives and the operational period for that time period, and also to get feedback and discussion in terms of are we moving this in the correct direction to clarify what those incident command objectives actually are. So again, the network is a huge, huge part, in my view, of what's necessary for these to operate successfully.

But now let me drill down into some specific information technology components. At the higher level, there's a management information system for emergencies. And in our particular case we bought an off the shelf program called WebEOC. It's implemented Statewide, so that at the State emergency operation center, at the county emergency operation centers, it's all interconnected on this system I just described. There's also another component that deals specifically with the health, and public health and hospital information. So on a real-time environment we have developed tables in advance that we send out health alert messages to the hospitals, for example. And if it's bed capacity that we need to know the information for, the hospitals can go online, place in the information that's necessary for bed capacity, and also, just as importantly, let us know what hospital beds are available for receiving patients. But it's not limited to that. There are many, many other types of tables that we have pre-developed in terms of equipment and supplies that hospitals or public health can share on this real-time environment.

And to be really blunt, during large-scale emergencies, and we've had some experience with large-scale emergencies, telephone systems do not work. The data is too abundant, in these types of a setting, for us to really assimilate in a way that can work effectively. And so our experience, in both a large-scale flood in GrandForks, an anhydrous ammonia release, and others, have been basically real difficulty in large-scale disasters for telephone systems to function appropriately.

So that's the overarching system. Hospital and public health all intercommunicate on that, can do it on a real-time basis, and we can create those tables on the fly as people have mentioned earlier.

Now let me drill down into the specific software and communications infrastructure that we put in place for medical equipment and supplies. We basically built this on the Strategic National Stockpile, and we use that as the model. But it goes beyond just receipt of those Federal assets. We also have State caches that we manage, and we would also anticipate purchased inventory if that became necessary. Things that aren't either in the Strategic National Stockpile or things that aren't in our State caches, it could be insulin or some other type of product or equipment that we would move through the system, are available to us. So it's a generic system. And the way the system works is that we have -- I'll use the Strategic National Stockpile terminology of an RSS site that can receive whatever assets are coming in, whether it's Federal level or with our State cache. It's scanned in at that point, and so if there are bar codes available on the product, most products there is bar code available, we physically scan it into the inventory system.

From there, we have 65 points of dispensing, and these are for either vaccine or oral distribution of medications. These are located throughout the State. All but one, currently, connected to the system that I just described. So they're all in that secure redundant network. So it's scanned in, the product’s in our inventory system. And then based on advance work that we've done on specific diseases that we can anticipate, we build a profile. And we've identified how many people, a specific POD, or point of dispensing, where this is actually delivered in these 65 locations, what the population base that's handled there is. And so with that system, then, based on our incident command structure, we make the decision about how much product is going to be moving out. And then it's allocated out, based on those percentages.

So for example, if we have an emergency that is just covering one part of the State, and we know what the quantity of product that we have here is, and here are the PODs that we have, and we know what the disease entity is, we put that into the system. It calculates out what the quantities that are going to those 65 points, or those specific points of dispensing that are being utilized. If we have the entire State then it's obviously a different calculation that occurs, but it's done automatically as part of this computer-aided process.

Now, once that is done, basically at that RSS site, it then spits out the actual picking lists. And so the people at the RSS site now know how much product, whether it's anti-virals, whether it's antibiotics, whether it's IV solutions, how much product is going to a specific point of dispensing. And we package it in on pallets in that format. It's scanned in as it goes out the door so we know where it's headed, it's scanned in when it arrives at the destination.

And here's where it really gets interesting, in my view. When people, if we're doing, for example, oral antibiotics, if people are coming to a POD site to pick up that oral antibiotic, we do a head of household process, where we basically have their driver's license, which has a bar code, we scan in the bar code, and the number or quantity of product that that person is picking up. And so within our incident command structure in a near real-time environment we can see if in fact we're beginning to run low in certain POD areas and have too much product in another POD area, and try and anticipate moving whatever limited supplies we have to keep the inventory in an appropriate level at the various POD sites as it's moving through.

The other important part of that is that if we do have countermeasures that are failing, in other words, let's say that we had a lot that was bad product, wasn't effective, that based on the system, we would be able to go back into the system and identify not each individual, but the head of household that picked up that specific lot, and be able to backtrack to identify where we may have to apply some different countermeasures.

It is a system that has had some frustrations. The difficulty that we have had, for example, while we're finding most product now is bar-coded, most bar code does not contain, for example, lot information in it, and so that's had some issues. And there's been some standardization of bar coding issues as well.

And it is a system that, to be really blunt, is untested except for exercise. So we've never had an event large enough that we've actually deployed this in a real world event. We've run exercises, full-scale exercises, to test both at the POD level and at the RSS level, but again, it's largely untested.

Some of the other difficulties that we have is to be, again, really blunt, it's not integrated outside the State of North Dakota. So in my view, we are extremely well integrated within the State, but to reach out to my partner from Minnesota or any other State, or even to the Federal level, there are not good ways at this point to pass that information up, or to pass the information down.

I've exhausted my time, and so let me just stop there, and I’ll be happy to entertain any questions that you have at the appropriate point.

>> John Lumpkin:

Thank you. Great. Heading east.

>> Aggie Leitheiser:

Just a little bit.

>> John Lumpkin:

Just a little bit.

>> Aggie Leitheiser:

Okay, and I would echo Tim's comments about the opportunity to visit with you today, and to talk a little bit about countermeasure allocation, distribution, and response, and some of the work that's going on in Minnesota. Next slide, please.

And what I want to do is talk about our plans and priorities, what we've been working on, talk about some of our information exchange needs and some barriers, and then some recommendations that I have for you as you continue your work into the future. Next slide, please.

Just a little tiny orientation as to where -- there's Minnesota. And as you can see, North Dakota is right next door to us, and we do share some -- we share a CRI community. Next slide please.

Minnesota has 87 counties that are organized into 53 local health departments, we're about 5 million people, and about 60 percent live within that red circle, the metro area. Which means that we have -- we're not a frontier State, I wouldn't call us that, but we have some people who behave that way, and we also border Canada -- I didn't mean that in a funny way -- we also border Canada and four States, which as Tim has already talked about the challenges in exchanging information. Next slide, please.

Well, I'm going to talk about countermeasures in a more -- in a broader scope, and some of the things that we have seen as countermeasures, and how we integrate across those various components. And Joe talked about some of them as well. Social distancing is a big countermeasure. And codeReady, which is our newly launched personal and family preparedness initiative. Isolation and quarantine. Personal protective equipment and healthcare supplies, some of what Tim has been talking about. Of course anti-virals and antibiotics, which we first think of. Vaccines, which we hope we’ll have the challenge of using for pandemic influenza. And then information as an important countermeasure. Next slide, please.

I'm going to talk about each of those in a little bit of brief detail. Next slide please.

Social distancing, which requires the ability to exchange information with public and our partners. Where is the place that you need to avoid, what about the infectious agent, can we evaluate the measures, can we track people, and can we get accurate information about what's going on back to our partners, whether it's emergency management or local public health or the healthcare providers?

Our codeReady system, as I mentioned -- if you could go ahead two slides please.

>> Matt McCoy:

Isolation and quarantine, are we on that one?

>> Aggie Leitheiser:

No back to personal and family preparedness.

>> Matt McCoy:

Okay.

>> Aggie Leitheiser:

With the small amount of money we launched a program for personal family preparedness, which as I mentioned is our codeReady campaign, which is an all-hazard multi-disciplinary effort to encourage people to develop family preparedness kits, to get ready on your own, so that those who can are not as reliant on government. Now if you'd move forward to isolation and quarantine.

We talked about that a little bit about that already this morning, how do you identify who it is you're wanting to track, and how do you provide case management for those people? If you could move forward one slide, please.

But also, how do you track contacts, which could be many dozens of people, if not hundreds of people. Making sure that information about their supportive services, do they have adequate food, healthcare, has their status changed, can we maintain communication with them. And then while we're in the midst of that, can we do information exchange, as we've talked about, up to the Federal level, with other State partners, with local public health, with other emergency responders.

Personal protective equipment and healthcare supplies are also important protective equipment measures and countermeasures. And managing stockpiles. We are working on developing a State stockpile, we are going to launch a contest for naming it, whether it should be the strategic State stockpile or something more creative and whether the Federal Government is going to change their name again. Maybe -- no immediate plans. All right. And what are the priorities for use? If we don't have enough masks for everyone, who gets them, and how? And we've kind of moved a little bit into if you don't have a mask you're going to die feeling out there in the community. And that's a real problem, we're swimming uphill on that one. And I use that metaphor deliberately. Ventilators, how do we track them? We don't have enough for everybody, where are they in the State, if they're available how can we move them around? And we don't have at this point chronic care and psychotropic medications as part of our stockpile. So we may be able to get you an antibiotic, but not your insulin. Next slide, please.

Anti-virals and antibiotics are probably the most developed and the most visible countermeasure component. And Tim had talked eloquently about managing the inventory, and how we do that, and tracking from the Federal Government down to the patient level. And we have varying levels of data needs. Some of our partners don't want to know about Joe, John, and Bill, they want to know what percent of the community has been covered, or what percent of a part of a State, and how do we then summarize the individual information back up to community level. And how do we monitor for adverse outcomes, and can we do that with an information system? And can we do it all within 48 hours? Sure. Next slide, please.

Vaccines are a little more complicated for administration purposes just because of the more invasive nature of the vaccine, or the administration, and that you have to see people individually. This is not a head of household kind of opportunity. And we already have multiple kinds of immunization registries in place, and how do we modify them so that they're useful both on a day-to-day basis and for a large event? And what if you need to do booster doses and recall and making sure that's built into the system? Next slide, please.

This is part of our challenge in managing information about these kind of countermeasures, and this is a busy slide, and it's true. We have Federal material, State material, and private material. And ideally, they all have separate bar codes, so that you can track things. The Federal and State material would go through our receipt, staging, and storage warehouse, down to a regional distribution node, then to the provider, whether it's the hospital, the healthcare provider, local public health. Private material would get mixed in with that. Private material, there's a charge for. Federal material, there is at this point not a charge for. State material we're trying to figure it out. And how do you track it then, do you then have a billing system and a process and multiple kinds of measures? Next slide, please.

I mention that information is one of our challenges as a countermeasure, and from my perspective one of public health's primary products is information. And what we need to get to our partners is very different than what we're going to need to get to the public, in terms of detail, quantity, and accuracy. Those things may vary, but the needs are going to be demanding on both sides. And the third bullet is that we need to do rapid, accurate, timely, complete, concise, science-based, but at the sixth grade level, ongoing but not too much, use up-to-date technology, but have alternate plans in place when that technology is not available, is comforting, and includes information about negative outcome, within a very short period of time. And that's more challenging, and it's something that we'll be doing at the same time we're trying to manage the inventory and the countermeasures activities. And we also will need to push that information out. Sometimes we're more responsive, and that's been some of our challenge is being more on the push side of it. Next slide, please.

I'm not going to go through this next list of things in detail, but I just wanted to give you a sense of some of our countermeasure information tools. Including the Health Alert Network, our MNTrac, which as Tim described their bed tracking system, that's our bed tracking system. And it includes a variety of add-on materials that we're looking at. Minnesota Responds is our volunteer ESAR VHP program, the Emergency System for Advance Registration of Voluntary Health Professionals. MN.TRAIN, which is our learning management system. MNStar, our emergency medical services information system. MNTrauma is our emergency -- our system for tracking people with various kinds of trauma. And one of our challenges is that we've invented these systems somewhat in a silo, and they're driven by various funding streams, they have various kinds of requirements, and they don't necessarily play nice together. And as we move into the future, that is one of our huge challenges, is to figure out how do we-- a person could be in each one of those systems, how do we track them so that Joe, John, Bill, are all indeed tracked so that they're indeed separate.

Let's move on to the next slide, just to give you a sense of -- those are some of the things that are challenging. One of the questions on the -- from the committee was to talk about an event that occurred and how it kind of played out and what kind of information needs there were. So I'm going to talk about an event that occurred this spring, which was a hepatitis A outbreak in a restaurant in a little county with the red circle around it. It's about 900 people in that -- 9,000 people in that county, about 150 miles from the State health department. There was a restaurant that serves between 800 and 1,000 meals a week, and some of the workers developed hepatitis A. So a variety of activities occurred, so that in the end we did about 2,300 people with immune globulin in two days. The restaurant, Joe talked about this, the restaurant was closed, cleaned, reopened, and they had a huge celebration and standing room only lunch crowd. Because this is a huge important resource in this community, and they wanted to show that they supported it. Next slide, please.

Again, not going to go through the details of this, but wanted to give you some sense of the kind of information -- I'm sorry that it's not very readable -- but wanted to give you a sense of the volume of information issues that occurred from this small, somewhat small event. And it was a serious event, one person out of the seven cases that we ended up identifying, one person required a liver transplant. The healthcare delivery system had a variety of needs. The laboratory information, how many cases were connected, what are assessment information, how do we assure that the healthcare providers in the community had similar information about what was going to be happening, coordinating with our partners, making sure that the information was going to be the same, the major media is in the Twin Cities area, which is where a lot of people get their information. They asked -- the local community asked that we do a hotline at the State level, because that was beyond their capacity to manage.

They ended up with doing the immunization at the county fairgrounds, which worked out great, because it was a large area, had facilities, did not have internet access, and we had to work around the first drag racing event of the season. And many people who needed the IG also were drag racing fans, so it worked out pretty good, actually.

A lot of public health information, exchanging information about epidemiology of the case, the investigation, consulting with the Centers for Disease Control and Prevention, getting information out to other healthcare providers. We did an auto-call to restaurants in the area asking them to talk with their employees about their -- whether they had eaten at this particular restaurant or had exposure. Getting the staff scheduled, ordering and managing the IG, so that very quickly they were able to provide this. If we move to the next slide, please.

This is not a very scientific slide, and I can't give you data points, but this is sort of our sense of what's out there. The yellow line is what kind of information exchange we would all desire. And on the bottom access, normal time, small event, and a disaster. And our information capacity I think we would all agree doesn't match up exactly yet with our desired, but as we move into a disaster the gap only grows. What's really possible, and as I mentioned in this event, we were able to do a lot of things, we were able to get the material to the people who needed it, but our ability to track information was much -- was very challenged. Next slide, please.

Then just a little more discussion about barriers, and then a few recommendations. Rapidly changing information technology, which is a wonderful thing, but it's a real challenge to keep up to date and to develop systems that can move with the changing times. Standards, so that North Dakota and Minnesota can share across the border, and to do that rapidly and readily. It costs a lot of money. And some of our policymakers don't understand that. We are fortunate in that the legislature funded a disease surveillance project this year, and really put some initiative into that. However, they gave us two million dollars, once. I think we can buy a TV and it will keep going. The challenge of ongoing funding is out there, certainly, and making sure that we have adequate State and local public health input into the systems that are recommended and designed, so that we don't end up with 18 different silos. Next slide, please.

So that leads to then recommendations. Coordination, integration, and interoperability. And I don't mean to imply that that's easy, by any means, I recognize. And we need the guidance and the standards. And shared expected outcome, so we're all clear about where we're trying to get. That it's a long-term plan. I think one of our issues, and Tim brought that up, is that we can't have a system that you only pull out in the time of a disaster, and expect that people can do it. We need to figure out what of public health, and what of healthcare delivery, works, and issues for daily work, that we would also be using in a disaster. We need a lot of technical support. And I mentioned that ongoing funding. Did I mention funding already? Just wanted to make sure that I didn't forget to mention funding. Next slide, please. My last one.

Uniform minimum data elements, for essential functions, that we're operating off the same page, and that our standards for interoperability, not only to exchange with our public partners, but also our private partners, and that we are indeed able to share across our disciplines together. Thank you.

>> John Lumpkin:

Thank you, and now moving on to the Federal level. Tom?

>> Tom Savel:

Good morning my name is Tom Savel, and I'm with CDCs National Center for Public Health Informatics. It's a pleasure to be here this morning. I'll be focusing on the areas of countermeasure administration and inventory tracking, and we'll discuss how these capabilities assist local, State, and Federal public health response work.

I'd like to begin by providing a brief overview of the needs related to countermeasure allocation, distribution, and administration tracking, focusing on the events in the recent past that have brought to light the requirements we need to address in the present. I'll also briefly discuss the progress CDC has made in this area, and conclude by identifying challenges that we face and recommendations for working together.

Events including the threat of pandemic influenza, the SARS outbreaks, smallpox preparedness, and anthrax attacks have all demonstrated that information systems are critical to managing the response and tracking of the countermeasures administered for containing and preventing further outbreaks. Within this broad categorization I'll be focusing on two primary needs: the need for pharmaceutical and medical materials inventory, and the need for information about who receives the countermeasures, in other words, the administration. Next slide, please.

With regard to inventory requirements, the need to locate and provide critical pharmaceuticals and medical materials to responders and the public quickly has increased significantly in recent years. CDC and the public health community must be ready at all times to respond to and manage public health emergencies, minimizing the impact of these public health threats in terms of lives and property, and money, et cetera. Being able to provide the quantities and locations of selected critical pharmaceuticals and medical materials within the commercial market at any given moment is critical. During an emergency, this information can be combined with corresponding data from Federal stockpiles and vaccine supplies, and its available State and local stockpiles, to provide a full picture of countermeasure supplies. The impact of this capability lies in managing allocations by being able to purchase or redirect these supplies to the most vulnerable at-risk portions of the population. Ideally this inventory functionality would support situational awareness and provide analysis, visualization and reporting capabilities to see the national picture of countermeasure availability. These capabilities are necessary for single events as well as multiple simultaneous events, where containing an outbreak or allocating a supply of pharmaceuticals is critical. Next slide, please.

Moving on to countermeasure administration tracking, the need to track the countermeasures in the population is the second focus topic I'd like to address. When a public health emergency occurs, there's a need to manage information the about the event, not only what countermeasures are available, but also who has received them. In addition, once countermeasures are received there's a need to monitor their effectiveness and identify any resulting adverse events. If isolation and quarantine measures are put into place, it's important to be able to track these measures in the community. Being able to exchange this type of information across systems for identification, confirmation and management, have proved challenging. So capabilities should include aggregate counts, and detailed person-level tracking for any size event, and be able to track any type of countermeasure. For pre-event or early event vaccination, or prophylaxis efforts such as another instance similar to a national smallpox vaccination program or preventive use of an influenza vaccination due to a pandemic outbreak, accurate counts and person-level information will be needed. Person-level information can be used for individual follow-up, and aggregate data can help track the progress of the event. Administration tracking capabilities should be able to integrate with inventory systems, surveillance systems, and adverse event reporting systems.

Countermeasure administration tracking also plays a role in post-event prophylaxis tracking. In a situation such as an aerosolized anthrax attack, tracking mass prophylaxis could be critical. Treatment for anthrax can be a long and onerous process for affected individuals. Having tracking information for a large population of affected individuals would be critical for follow-up care and monitoring adherence to treatment regimens. I'd like to provide two examples of lessons learned which illustrate the need for pharmaceutical inventory tracking and countermeasure administration tracking. Next slide, please.

With regard to lessons learned, in early 2004 the Pre-Event Vaccination System, or PVS, was implemented nationwide to track and monitor the administration of smallpox vaccines as part of the national smallpox preparedness program. The purpose of the PVS system was to track public health and healthcare providers who were given smallpox vaccinations as a national preparedness effort. The system was able to track demographic information, vaccine information, follow-up care requirements, and adverse events. CDC and others quickly saw the utility of a system like PVS, but envisioned something that could be flexible enough for any kind of event or countermeasure tracking, not just a system designed for one purpose.

The influenza vaccine shortage which occurred in the 2004/2005 flu season illustrated the need to establish partnerships with the pharmaceutical industry in order to know details about vaccine manufacturing supplies, surpluses, and distribution across the country. Being able to track selected priority pharmaceuticals and medical materials in the commercial sector and combining that information with existing vaccine ordering and distribution systems and stockpiles within the government could be a tremendous value to public health at every level during an emergency. Being able to purchase or redirect supplies at the most at-risk portions of the population is vital for managing public health emergency responses. Both of these capabilities could be critical during a pandemic influenza situation where a vaccine or countermeasures are in short supply and the need to track vaccine doses administered will be vital.

IT infrastructure lessons were also learned during these two public health situations. System integration and data exchange with other preparedness systems needs to occur, facilitating the exchange of countermeasure data. The data exchange of course needs to be bidirectional and secure, using industry standards, for example, for messaging and authentication. Next slide, please.

Moving on to the data requirements for inventory tracking. The critical elements needed to support the public health response to high priority national threats should be the first functional components conceptually of a system for commercial inventory tracking. These include pharmaceutical countermeasures or medical interventions for pandemic influenza and potential bioterrorism agents considered category A public health threats. This includes smallpox, anthrax, plague, tularemia, botulism, viral hemorrhagic fever such as Lassa and Ebola viruses. These threats are a concern obviously because they are easily transmitted from person to person and have high mortality rates.

Critical medical materials of course include ventilators, masks, and additional personnel protective equipment. But the important data elements would include items such as manufacturer, supplier, and distributor unique identifiers and names, pharmaceutical lot numbers and expiration dates, and of course quantity and units of measure and shipping location information.

And moving now to the data requirements for administration tracking, these are the data requirements that could be beneficial for countermeasure administration tracking capabilities. These categories include organizational information, staff information, product data, patient demographics, actual administration information, and isolation and quarantine data. CDC has collaborated across the agency to choose these elements, and initially they reflected the information needs for the national smallpox preparedness program that started in 2003. But the list has now grown to include information recommended by CDC's National Center for Immunization and Respiratory Diseases as the core data set for immunization information systems. Other events including the monkey pox outbreak in 2004, anthrax outbreak planning and pandemic influenza planning have contributed to and enhanced the field selected. Isolation and quarantine fields were selected by studying smallpox post-event plans and working with a number of stakeholders including partners such as NACCHO and State health departments.

It's at this point I'd like to now provide some details of some of the activities within CDC in this domain. One effort has been the Countermeasure and Response Administration program. Building from the success of the Pre-Event Vaccination System, CDC with many State and local public health contributors is expanding on the capabilities of the PVS for national, State, and local use. Next slide, please.

Wait, go back a slide.

>> Matt McCoy:

Onto the overview?

>> Tom Savel:

Right on this slide, that's right. As an overview, the countermeasure and response administration program includes the people, processes, and tools to increase public health capabilities in monitoring and tracking countermeasures pre-event, early event, and post-event. The program at CDC addresses many of the capabilities I've been describing.

And just to go into each one of those just for a moment. The countermeasure administration tool can track all countermeasures identified for an event with information at the individual or aggregate level. With this tool, CRA is increasing the capability of all levels of public health in tracking and managing countermeasures during an event, so that the delivery of interventions of an event can be monitored, their impacts assessed, and adverse events identified and rapidly handled. This tool is complementary to CDC's Outbreak Management system.

Over on the right, the countermeasure inventory tool in development will be able to track priority countermeasures in the commercial sector. This capability is complementary to other CDC activities, including the Vaccine Ordering and Distribution System or VODS and the Strategic National Stockpile. This capability will impact public health by giving public health emergency managers critical information needed to identify the location and quantities of critical pharmaceuticals and medical materials in the private sector. Next slide.

At this point I'd like to look at the use of the Standards Development Organization's endorsed standards in this domain for a bit of an overview. For the work being accomplished around countermeasure inventory tracking, information data exchange should be simple as possible to entice participation in the commercial sector. CDC has recommended the use of standard pharmaceutical electronic data interchange, or EDI transactions, recommended by the Healthcare Distribution Management Association, or HDMA. Using standards-based manufacture and distributor inventory and shipping data for countermeasure inventory tracking, public health emergency managers will be able to identify the location and quantities of critical pharmaceuticals and medical materials in the private sector.

For administration tracking, existing vocabulary or terminology standards such as HL7 and NIMS and others are being repurposed by the CDC for response management as needed. Where standards do not exist, standards are being developed by CDC. Furthermore, the CDC is actively involved in a number of the SDOs in order to ensure that the needs of public health in general, and response management in particular, are considered, and of course if appropriate, adopted by the SDOs.

The CRA administration tracking tool interfaces with immunization registries. Longer term plans may include augmenting immunization registries and interfaces with other systems such as emergency responder adverse event systems such as VAERS or others. The interfaces at this time are both automated and manual, to ensure the maximum amount of data can be shared across systems. One more slide, please. Next slide. Okay.

So finally, I'd like to finish with looking at the ongoing challenges and the role the Community can play. So in addition to the integration activities that need to take place in the many systems involved in countermeasure management, VODS, SNS, VAERS, the countermeasure inventory, countermeasure administration, in time this countermeasure functionality needs to be incorporated into the expanding EHR landscape. We may need the help of the Community to leverage relationships or partnerships with PhRMA for the inventory tracking capability we're building. We need to understand this industry better and determine if PhRMA can endorse our value proposition for how the industry can support public health, and urge their constituents to participate in the inventory tracking program. In addition, States need funding to support automated administration tracking capabilities and to be interoperable with the registries and potentially healthcare organizations.

And finally, I'd like to conclude by saying that all of you will hear a tremendous amount of information today from presenters and will quickly get a sense this is quite a large and challenging domain. Public health at every level has made considerable progress and is moving forward, but of course much work remains. We'll all benefit from continued partnerships, the work of the Community, and the evolution of informatics applied to public health. Thank you very much.

>> John Lumpkin:

Thank you. Gary?

>> Gary Urquhart:

Thank you. Good morning. My name is Gary Urquhart, and as I said earlier, I'm from the Centers for Disease Control and Prevention in Atlanta. I'd like to thank you for the invitation to provide testimony today on Immunization Information Systems, also known as immunization registries. The focus of my testimony today is going to be on the role of Immunization Information Systems, or IISs, in assisting with the management of a public health emergency event. And more specifically, I'd like to discuss the role of IISs in responding to public health preparedness requirements, how past use of IIS during a public health emergency is being leveraged for pandemic influenza response planning, and finally, how the Community may be able to help facilitate these efforts. Let me begin by providing a brief overview of IISs, their role in public health and clinical practice, and the current status of IISs.

First, a brief definition of IISs. Immunization Information Systems record all shots on all children given by all providers in a geopolitical catchment area, and they have functions and features that are needed by an immunization program. Things such as vaccine inventory management, reminder re-call, et cetera. And they have the interoperability with other health information systems, including electronic medical records, or EMRs.

IISs support parents, immunization providers, and public health with data to consolidate immunization histories; provide an official immunization record; they have reminder re-call functions; they prevent extra immunization, and that's very important these days when we're talking about HPV, that costs 100 dollars a dose; and they provide decision support for immunization schedules and new vaccines. They also provide data to develop policy and priorities and evaluate programs for some of our immunization program grantees.

The status, briefly, of selected performance measures reported as of the end of last year, 2006, include 75 percent of grantees reporting that they have population-based Immunization Information Systems. 76 percent of our grantees report collecting immunization data for all ages, in other words, they’re life span registries. 49 percent of grantees can process and return an HL7 message as well as process and upload a record consistent with HL7 standards. And on the slide here you see almost 15 million U.S. children less than the age of 6, that's about 65 percent of all children in this country under the age of 6, have two or more immunizations and are participating in an Immunization Information System. At the bottom of the slide, the last bullet, almost 37,000 provider sites are participating in Immunization Information Systems. 71 percent of public provider sites and 47 percent of private provider sites are participating in an Immunization Information System.

Now I'd like to discuss the IIS role in responding to past public health emergencies, and more recently to public health preparedness planning requirements. Next slide, please.

In August of 2005, Hurricane Katrina caused massive destruction in Louisiana, Mississippi, and Alabama, and an estimated more, really much more than 200,000 persons were displaced from Louisiana to points throughout the country. And this included more than 60,000 children. Despite the devastation, Immunization Information Systems offered some assistance to the victims by meeting the clinical administrative need for immunization histories of displaced children. Of course, children need to comply with State immunization school laws, and so that's the reason for the need of having histories of vaccinations.

After Hurricane Katrina, the Louisiana Immunization Network for Kids Statewide, otherwise known as LINKS remained operational via a backup server in Baton Rouge. An estimated 60,000 children were displaced to all 50 States, as I said earlier, and Washington, D.C. Most families with children had lost all records of immunization, but still needed proof of immunization to enter school. Within days after Hurricane Katrina, the Houston -- a couple of examples now of some activities that occurred -- within days after Hurricane Katrina, the Houston-Harris County immunization registry in Texas was connected to LINKS using HL7 messaging standards. This linkage provided immediate access to the immunization records of children who were forced to evacuate from New Orleans. Representing an average estimated cost savings of 1.6 million dollars in vaccine alone, and another 3 million for vaccine plus administration fees. These have to do with savings on revaccination costs, of course. And this came from a paper written by Dr. Julie Boom of Baylor, in a recent issue of Pediatrics. Next slide, please.

Another recent paper written by myself as well as Warren Williams and other colleagues was an assessment of more than 21,000 electronic immunization queries that were successful to LINKS, and found that a savings of more than almost five million dollars was saved in revaccination expenses. That paper will be published in the Journal of Public Health Management and Practice in September. Both of these papers illustrate how IISs met clinical and administrative business needs, and that CDC-required functional standards for our grantee IISs, including the use of HL7, work to facilitate interstate data exchange during a public health emergency.

The interoperability of IISs allow public health and clinical data exchange to promote decision support and the protection of the community. IISs have been funded by CDC and implemented over the past 13 years, using core data elements and functional standards as recommended by the National Vaccine Advisory Committee, or NVAC.

Our next slide describes core data elements required by IISs funded by CDC. One of the questions asked in the appendix in our invitation to speak today sought clarification on information used by registries. As I said, NVAC recommends and CDC requires our IIS grantees to use the following core data elements. Patient name, first, middle, and last; patient birthdate; patient's sex; patient's birth State or country; mother's name, including first, middle, last, and maiden name; vaccine type; vaccine manufacturer; vaccine date; and vaccine lot number. And more recently, about three or four months ago NVAC recommended changing the following data variables from optional to required status. And these include patient race and ethnicity, patient birth order for multiple births, and there were a few other things as well.

A subset of this information is typically used for preparedness related responses, and Tom has already mentioned this to some extent. For example, in pandemic influenza response, collecting doses administered data will be aggregated from patient-level data, collected either by an IIS or the CDC countermeasure response administration application that Tom has already discussed. Next slide, please.

In the early stages of a pandemic, doses administered data will be reported to Federal authorities. There are three options for making this happen, and again, Tom has discussed these briefly. For those IIS systems that are mature enough, we anticipate that the immunization information system will be used to report aggregate data for monitoring doses administered data during a pandemic. The focus of IIS and CRA at this point has been on tracking and reporting of pandemic influenza vaccine doses administered. But it's expected that further consideration will be given to the use of systems to address issues regarding vaccine efficacy and safety. Next slide.

The last two slides I have today are -- sorry, I’m not to the last two yet. This slide addresses SDO-endorsed standards. One of the questions that we were asked to respond to was the IIS use of SDO-endorsed standards for preparedness issues. As I mentioned earlier, IISs have adopted and implemented the use of Health Level Seven, HL7 standards for many years, and these have been used during a public health emergency situation, that I just talked about, and to improve connectivity between IIS systems. I've already mentioned in a previous discussion about the article by Julie Boom and colleagues that they reported in Pediatrics that it took less than 24 hours to establish a connection between LINKS and Houston-Harris County immunization, the Houston-Harris County immunization registry. Additionally, these standards are used to improve the interoperability between provider sites and the IIS. Currently, Immunization Information Systems use HL7 2.3.1 standard, and are migrating to the use of HL7 2.5 versions. Next slide.

My last two slides have to do with some collaboration on key issues by the Community, and by this Workgroup. AHIC in collaboration on key issues to ensure complete and accurate information within IISs will help make these tools more useful when used in an emergency response. IISs have immunization records that represent a microcosm of electronic health records, and over the past 13 years of struggle to address most of the same issues that the Community is addressing. This experience up until now has not been tapped by the Community. And so we recommend that this be considered, and hopefully this will help us to continue to be engaged with this Workgroup and others in the future.

Events following Hurricane Katrina have shown that interstate data exchange can take place during a public health emergency because of IIS use of functional standards. This interstate data exchange, as has already been pointed out I think in Minnesota and other places, doesn't happen on a routine basis because of administrative and legal issues. The Community should facilitate the development of national administrative or legal approaches for routine interstate immunization data exchange.

Interoperability, as has already been pointed out, with clinical systems will be crucial for Immunization Information Systems and other public health data systems, if the goal of having EMRs develop and flourish is to be realized. The Community should foster the development of EMR standards to interoperability with IISs. And I think that’s something that’s being addressed, at least initially, anyway.

To date, limited funding has been dedicated to IISs for pandemic preparedness planning. The Community should help ensure that adequate funding is available to CDC grantee IISs to address pandemic influenza preparedness planning. This could be done by ensuring that priorities are established for immunization programs to address the use of IISs for emergency preparedness activities. Last slide, please.

Increased provider participation in IIS will help facilitate the development of EMR and public health emergency planning. The Community should work with the National Vaccine Program Office, or NVPO, to deliberate on the pros and cons of legislative and other approaches to increase provider participation in an IIS.

Similarly, a national implementation of provider performance incentives will help facilitate the development of an EMR. The Community should assist NVPO and CDC to deliberate on the pros and cons of provider performance incentives based on the completeness of immunization data available in an IIS. And actually, this is already being done in a couple of States now. In Michigan, for example, up to 250 dollars is paid for a completed series to meet HEDIS requirements by a health plan. And this is something that's been in place by this particular health plan for more than three years. They've paid providers almost a million dollars over the past two or three years. The catch here is that they have to put the information into electronic format into the immunization registry in Michigan. So this could be promoted nationally, and help provide improved provider participation in these systems.

At present, IIS interoperability with an EMR must be developed on an ad hoc basis with each EMR vendor. And this is really an inordinately expensive exercise. The Community should ensure that IIS reporting standards are incorporated into EMRs that receive Federal funds or that are certified by the Office of the National Coordinator.

That concludes my testimony today. Again, I'd like to say thanks for the invitation, and I hope to remain engaged in the coming months and years. I'd be happy to respond to questions at some point.

>> John Lumpkin:

Great. Thank you. And last but not least --

>> Greg Burel:

Sometimes going last is a good thing. Again, I'm Greg Burel, I'm currently director of the Strategic National Stockpile. And I appreciate the opportunity, as well, to be here today.

We-- stockpile is all about the stuff. You know, we've heard very clearly from our State partners information needs, we've heard from them about things that are going on in various States. And we want to talk a little bit more about the tail end of those needs for us, and maybe some of the front end needs for us. Next slide, please.

The mission of the Strategic National Stockpile is to deliver these critical medical assets to the site of an emergency. We maintain various antibiotics, anti-virals, antidotes for chemical bioterrorist events, and things of that nature. These are configured in many different ways. We have the standard push package, and you've actually seen the picture of that several times in the presentations from the States and also the opening slide to this presentation. We have a configuration called the CHEMPACK, and the CHEMPACK is placed very forward with States through agreements so that it can be used immediately in the event of a chemical attack. We also have other managed inventories. The Federal medical stations are a part of the Strategic National Stockpile currently. We have a community -- a cities readiness initiative which seeks to deliver medical countermeasures quickly to an affected population in major cities, where it's estimated about 53 percent of the national population resides. Minnesota has been a good partner, as have many of the other States in that area. Next slide, please.

In the Strategic National Stockpile I believe that we do a good job of tracking our own inventory internally. We have a very huge inventory of products, we have a very dispersed inventory of products. Some of those are under our direct control, some of those are managed by third party logistics companies, some of these are under State control through agreements. Our Stockpile Resource Planning tool is an Oracle-based tool. This is commercial off-the-shelf software, obviously, and it allows us to track our inventory and to do financial planning. It is not accessible by non-Federal agencies. Much of the data contained in that system, when it's taken as an aggregate, reaches the classified level of information and we can't make that open to everyone. But this does inform us about what we have that we need to push to States in the event of an incident. Next slide, please.

You've heard about our RSS sites and about the points of dispensing. What we do there is we rely on the States to manage the inventory once we deliver a package to those sites. We do offer a tool called the RSS Inventory Tracking System designed around tracking inventory in the RSSs, or RITS. This is free to our various project areas. It's designed to help the States manage the SNS material that we have delivered to them. This is a web-based product. Many of our project areas are currently using this, or interested in this, or are currently in the second phase of the roll-out. The fact that we're providing this, though, is not necessarily the greatest thing. I think it enables States that don't have their own inherent capability to do the tracking of the material in the RSS site after we've turned that over to the State, but as we've heard, integration of systems that do track that down, particularly to the patient level, I think is necessary.

Let's talk a little bit in the next slide, if you will, about where we believe the information gaps that we currently have in Stockpile are, and where I think we could use some assistance and further partnering with other people to assist us there. In the Receipt, Store and Stage sites, the front-end status of those sites is very important. We work with the States to manage those sites, we send out a technical advisory unit to those sites as we deliver material. But these sites are very -- they're critical to us to be able to perform in the State. We need to know before our team even gets there what the status of those sites are. We know where the sites are, we know the State's plans for the sites, but in an event of this nature, of these types, these things can change very rapidly.

We would love an opportunity to have an information system that shows us that the site is open, the site is up, the site is operational, the requisite number of people are already there, and so on. You know, as we've heard, phone calls don't work well here. And to be able to see that as we are inbound into a site with our terror unit would be great. Obviously, the back-end side of that is important to us, too. We need to see as stock levels go down, we need to understand where they're going to PODs, the points of dispensing, and we need to understand what's happening to those materials when they get out.

Which takes us to the next stage in our process, and that is the point of dispensing site. After we release material or the State releases material from the RSS to these POD sites and this material is then further handed off to the population for use, it is important to us that we know what's going out. We need to know what's happening after these medical countermeasures get into the hands of the people that need to apply those and use those rapidly. And I think that there is a large information gap for us there.

We've designed all of our systems and our focus around pushing everything out quickly so that it can be used and administered, but we're not doing a good job of working to get the information back to say how effective are those medical countermeasures, or are there problems with those medical countermeasures. There are some capabilities there, but they are limited, and most are dependent on States and locals. Eventually we would like to know the treatment center status in various treatment centers.

My presentation is brief, and it's because we focus mainly on, at this point, managing our own internal inventory. But the piece we need to work harder on, the piece that we need more interaction on, and the piece that we need more integration with the States on, is what happens after we hand off that inventory. That would inform us better what we need to be prepared for in future events, it would inform us better about what we need to do in an ongoing event to continue to support our State partners in an appropriate way, and to know the effectiveness of what we've distributed. Thank you.

>> John Lumpkin:

Wow. This is -- it's been an excellent panel, thank you very much for a lot of insight. I've got a ton of questions, but I'm going to turn it over to the group. Let me just ask one, one question. And Gary, your comments specifically raised the point that if -- one thing that AHIC could do would be to -- you didn't say it in these words, but if the CCHIT were to include in their certification of electronic health records the ability to pass HL7 messages with immunization registries that would be a good thing. So that's a very specific kind of recommendation we can get our arms around. Are there others that would rise to that same sort of specificity that the, any of the panelists would like to suggest?

>> John Loonsk:

Just relative to that first comment, I would like to note that it is on the road map for CCHIT to have that exchange. So that one that is mentioned is one of the things that CCHIT has put on their road map for this.

>> John Lumpkin:

So we should recommend it very quickly so we get the credit.

>> John Loonsk:

That's one approach.

[laughter]

>> John Lumpkin:

Are there other very specific kind of -- if you could just get one thing out of this process, what would that one thing be? Don't all jump in there at once.

>> Torney Smith:

This is Torney Smith in Spokane. My sense is that having common standards that we all adhere to over time for data interchange, whether it's HL7 or whatever it becomes, is a critical component to assuring that we can exchange that data when we need it. But I think that there's one other piece that we have to always be looking at as well, and that is the comments that telephone doesn't work during the emergencies. Quite frankly, nor does the Internet if it's down. So we need to be able to have redundancies built in, for sure.

>> Tim Wiedrich:

And just a quick response, because Torney is making my point, I started out with the network. And the network that we rely on for our communication systems is not Internet-based, it's not telephone-based, it's not cell phone-based. So part of I think what lies at the base of this are reliable networks that are redundant, secure, uninterruptible, because we cannot rely in large-scale disasters on cell phones, telephones, or the internet. And part of that challenge to me, that's the first step. Once the highway is built, then, you know, the argument about which cars should be on the highway becomes a secondary argument, although very important, as well, not to diminish that in any event.

What I was struggling with is to distill kind of down into one concise point, that's why I was sitting here silent, and probably still should be silent, but I won't be. Part of the difficulty that I see, and we as States, I believe, own this, as well, and I think the local public health units own this, and I think the Federal public health sector owns this as well. We are not adequately dialoguing at this point, in my view. We believe we are doing some level dialogue, but when we're -- what dialogues that are occurring are not effective in actually developing the types of integrated infrastructures. And so on the State level at times we impose systems that might be redundant or stovepiped, it happens at the Federal level, and at the local level systems are developed and not integrated into other larger schemes. So if, you know, in terms of kind of the take-home message, whatever processes are put in place, really is, and it's messy, is getting the necessary stakeholders sitting around the table, rolling up their sleeves, and really developing and providing substantial input into what those systems actually are. We're not doing well at that right now, in my view.

And I'll make one other quick comment. The ultimate success of this is to roll the public health and the medical sectors into a larger emergency management infrastructure. I mean, part of this is we don't also stovepipe the public health and medical sector, but that we can, for large-scale disasters, roll this up in emergency response systems as well. And, you know, to that end there's not a lot of activity that's taking place to make sure that the messaging that we're talking about in these large scale disasters really is appropriately displayed in emergency management avenues as well.

>> John Lumpkin:

Gary.

>> Gary Urquhart:

Just one sort of additional comment to Tim's comments. All of us at the Federal level have a number of grantee programs that we support, and there's quite a bit of money that goes out behind these that should really enforce what you're saying in terms of common standards and data exchange and interoperability with other systems. But it takes, it takes a willingness and the ability to sit down and coordinate how these program announcements go out, and what kind of program requirements are there. And that's a -- I don't know if the Community can address that or not, whether that's something that we, the Feds and the State level, need to spend more time on. But certainly you can make recommendations that might help facilitate that activity.

>> Aggie Leitheiser:

And I would add -- actually, I have two ideas that came to mind as you're looking at specifics. One is that we've done a lot of work on silos, and I think we all know how to do that. As we look forward into the future we need to think about how do we make the -- work with the private sector who are developing electronic medical records, how do they hook into the public sector, and that we have some comparable growth on both sides. That's -- I've seen a lot of energy around electronic medical records, but that ability to exchange that information securely with the public sector is not as robust, I think, universally.

And I actually would pick up on the point that Torney made about privacy issues. That as we're developing these systems, if we have not thought about how we securely exchange information back and forth between the public and the private, and across our borders, and with our -- with Canada, from my selfish perspective, then we've created additional problems, and we’ve just invented more silos, or siloettes, I don't know.

>> John Lumpkin:

Other questions? Jon?

>> Jon Einbinder:

Actually I'd be curious to hear -- as I listen to the presentations I'm trying to think of how to sort of lump or split some of the areas of integration and interoperability that you talked about, and I heard managing material and supplies and things that have to go out, linking providers together so you know, you know, who is available to work from a healthcare delivery point of view in a disaster, patient-level information, everything from immunizations to lab results to other things. A wide range of stuff. And information flowing from local health departments to State, State to Federal, from hospitals, et cetera. So lots of places where there are information gaps and opportunities.

And if you were to kind of -- I guess thinking from a prioritization point of view, and we also heard about the network, so you need to have the infrastructure that's available in a disaster that, you know, when other-- when phones and Internet may not be working. Is the need greatest, I guess, from a priority perspective, to have good interoperable information for -- if I had to sort of force you to choose or order them, for patient-level information -- or person-level, really, these aren't patients, these aren't people in healthcare facilities -- for tracking material, for managing provider resources, so you know who the healthcare providers are and who is available and what they can do, or for communicating from local to State to Federal. Because I think that they're all, obviously all very important, but you know, kind of where, where is the best place to start. Or kind of where is the biggest opportunity. If that's a fair question.

>>

If I could answer that. I think the biggest opportunities are in the -- getting clinical, person-level information into public health. And obviously I'm in public health, so that's where I live, but that's what's going to help us day-to-day, and may be scaleable to the emergencies. Who knows when we'll exercise the SNS system, will we ever do mass prophylaxis for the entire population or a county? I doubt it. We can manage through mid-sized emergencies, but we have right now real needs to be able to take some alerts from surveillance, and investigate them quickly. We've got more data, we need to be able to drill into it very quickly to rule out all of these just noise alerts, and figure out what's going on. And there are electronic systems that have a lot of the information we need. I think there's good opportunity there for some gain, so I think there's a good balance of value and opportunity. And likewise, for the reportable disease reporting, it's another opportunity to start to build an interchange that gets used day-to-day, so we get some real experience in these systems that may be useful in the emergencies as well. And we can start to, you know, establish the actual used connections that we're going to need.

>>

Person-level.

>>

I have a slightly different response, and it seems to me you're asking two questions. One is, you know, a technical part, where we make sure that we have standards between clinical activities and public health activities, especially in the context of this managing response. And then there's also the legal and administrative problems that occur, and that maybe takes more time to deal with than anything else. Because I think we're all assuming that during a public health emergency, data would be exchanged. I wouldn't necessarily want to assume that, frankly. There are 50 States, and Washington, D.C., that all have different approaches and different viewpoints on how data or even what data should be exchanged on a routine basis. Does that translate necessarily into a public health emergency? I don't really know. But to me there's two issues, one technical, functional standards, and the other is administrative legal issues.

>> John Loonsk:

To that administrative legal I would add business proprietary. Certainly one of the things we ran into in the flu vaccine shortage and other circumstances is how to get commercial data to use it for public health purposes in the context of an emergency. And it was one of the things that I think was touched on, but maybe if you have some more comments on, is the relative proportion of countermeasures that exist in the commercial market versus in the Stockpile, or in other stores. And obviously it depends on what the countermeasure is, but maybe you could have a few comments about that subject, either Gary or Greg or both of you.

>> Greg Burel:

I think that's a good question, John. The -- we do have capability in the Stockpile through some prime vendor contracts we have for particular countermeasures, to understand as we deplete our inventories what is currently available in their inventories in various locations to begin to backfill us or to begin to establish some supply chain directly forward on those. But I think there is limited data about that, in a wide dispersion. Again, we can see what our prime vendors have through them. We're reliant on them, though, to provide that information. We don't know what anyone else has.

>> John Lumpkin:

Brian?

>> Brian Keaton:

First I want to thank the panel for an incredible presentation. You make me feel kind of schizophrenic, or maybe bipolar is the right word. I'm an emergency doc at heart, and I also represent 25,000 emergency docs across the country. And what you tell me makes me feel real good, on one side, because this is some incredible information. But it scares me, because I didn't know about it, and I'm the doc that has to take care of the patient, and the people I represent are the docs. There's not a communication that carries past -- you know, it seems to be getting to the local public health, but across the country I hear from my members that it doesn't get to the level of the emergency department, the physician taking care of the patient, the primary care practitioners in the office. There's a huge gap there, and it's a critical one. You know, public health still is largely a 9:00 to 5:00 Monday through Friday operation in the locality, and emergency care is 24/7, 365. So that, I think, is a critical gap that really has to be addressed. Emergency departments have a hard enough time talking within the department, we don't speak department-to-department. Our links are telephone and fax, usually, to the local public health. And I mean, that is just a critical area that I think needs to be addressed. I don't know if there's an answer that you can come up with that, but I want to point out that, when I look at gaps, that is the one that scares me the most.

>> Tim Wiedrich:

If I could respond to that, Mr. Keaton, and this is Tim Wiedrich. I echo that concern. And quite frankly, to be really blunt, we just completed a Statewide, you know, 12 regions pandemic influenza exercise. We brought people at a local level in and State level responders, and walked through a table top exercise. And what that demonstrated, just reinforces your point, is that at the planning level we understand what's going on, and we've got a lot of systems in place. And now we're actually doing exercises. But what -- because of the speed in which we are moving in terms of creating the planning process, putting the systems in place, we're missing a very critical step. And we're going from planning to exercising, and we're forgetting about that whole training component in many situations that are in between there.

And again, part of it is I really do believe the speed with which we're trying to create these planning processes and get these new systems in place -- I don't know if this will soften the blow a little bit, but from my perspective, what we're beginning to believe, in our State, and the way that we're moving forward, is that we believe that much of the types of things, the interventions that we're putting in for very specialized activity, is going to be just-in-time training at the local physician level. The emergency physician level may not need to know, for example, about the North Dakota system which all the hospitals can log into this real-time reporting system. But it's important that a nucleus of people within the hospital have that level of understanding.

And part of the challenge I think that we have, just as, you know, as I sit and listen to this panel and have been engaged in other dialogs, it's very easy to get overwhelmed, because there are so many components, so many tentacles to this. And the challenge to really figure out what is critical information that practitioners need to know at a local level, in order to make the system function. I don't think we have that quite right yet. But I in part blame that just because of the speed with which we're doing this. Hopefully at some point we can slow this process down a little bit and be a little bit more strategic in terms of how we deliver that information and training.

>>

I'm a strong proponent of creating a bidirectional communication. The other problem with the clinical care providers in public health is you guys are a black hole that we dump data in, or maybe not nearly the amount of data that we're mandated to dump, but there's not much that comes back that's useful to us from the other side. I think that bidirectional communication as was stated has to be a day by day by day activity, so that when you have to magnify the situation to a larger emergency, if you would, that it simply is ramping up a system that we're all familiar with.

>>

Actually, we have that opportunity with the syndromic surveillance systems that are using ED data that those can be pushed back to the hospitals for, at least for the infection control people to use.

>> John Lumpkin:

And Brian, you didn't mention the word EMS.

>> Brian Keaton:

I was just getting warmed up.

>> JOHN:

Oh, okay. Scott?

>> Scott Becker:

A couple of things. One, I'm sorry I'm going to have to leave, I won't be here for the afternoon discussion. But it seems like the bidirectional communication might be something we should think about for a use case. Given what we've heard today, and Brian's ongoing dialog with us, it seems like it's a major, major piece.

Tom, I had a question for you about the CRA program, the Countermeasure and Response Administration program. Is it, is it deployed, or is it conceptual, or is it -- where is it in its development?

>> Tom Savel:

The Administration tool?

>> Scott Becker:

Yes.

>> Tom Savel:

So that, in terms of its deployment models, it both has a centralized model, and also a deployable model. And I know that there are certain aspects, I know the centralized is sort of I think it's in -- it is deployed, and I think that the other models of it are sort of, I think they're still being evaluated, so they may be out there. So that's right now in evolution, but it does exist and it's being refined. The Administration-- the inventory tool is earlier in the development process.

>> Scott Becker:

Okay, thank you.

>>

Maybe in follow-up to that question, I wanted to understand a little bit more the relationship between what the SNS has built to track inventory and what Tim described as, you know, the efforts to track inventory as well in North Dakota. Seemed like the system that you were talking about is one that has strong capacities to help CDC manage the inventory, but there's this other piece that talks to the commercial world, in response to John's question, that -- I mean, is that done with EDI, is that done by phone? And then getting to what Tom just said about, you know, the Countermeasure Response Administration, how does the SNS package match to what Tom just said, which might have a deployable component in Tim's world? So I'm trying to see how all these relate. Or are they all not relating, or is there any attempt or desire -- I mean, it sounds like from Tom's comments that there is a desire to make that happen, but at least -- it seems to me like, you know, you're sitting in the middle and there are two people on the ends of the spectrum, and your tool in the middle is not maybe happening. Is that true, did I hear that right?

>> Greg Burel:

So let me go back to the first part of your question. The ability that we have to see what's in the commercial marketplace available to us after we exhaust our supplies is not electronic for us. What we do is once we exhaust our supplies, we have contracts in place with prime vendors for particular product. And we can go back to those prime vendors and say what is still available to us in your current system, can you tell us where that is, can you give us information about how long it's going to take you to get that to place X? We don't have an -- we don't have visibility of what they currently have, we don't have visibility of its location. A lot of that I think goes back to what John Loonsk mentioned earlier with the proprietary nature of some of that data. So --

>> John Loonsk:

There's another complexity there, too, which is at least we were quoted during the smallpox response that as much as 80 percent of countermeasures are in the supply chain at any given time. So they may not be at the manufacturer, and -- or a proportion of them would be there, but a number of them are at distributors and a number of them are in what you could call the retail component, whether it be a pharmacy in a hospital or somewhere else.

>> Greg Burel:

-- rolling around in trucks and places.

>> JOHN:

Rolling around in trucks. That 80 percent, there's a goodly supply of countermeasures that are in the commercial sector, and that -- and a good amount of them are in the supply chain at any given point of time. And so it complicates the awareness issue of knowing where they are.

>> Greg Burel:

As far as the other piece of your question, our system is designed to track and maintain information about our own Strategic National Stockpile inventory. A lot of this goes to requirements that we have for financial reporting and things of that nature, but also so that we know the status at any point of our inventory on-hand, what we have inbound, what we are removing from that inventory because it's expiring and being replaced, or whatever the case may be.

You are correct in that there are tools that are available to States to use, that we can make available. But many States also have implemented or developed their own tools to manage the inventory, once we release that inventory to the States.

This may be the appropriate place for you to speak to your middle needs.

>> Tom Savel:

So in a nutshell, the comments I want to make are, number one, that it's complicated in the sense that there's the vaccine and then the non-vaccine systems, in a sense, and those have to start talking to each other. And then there's -- lost my thought for two seconds. There's a concerted effort going on within CDC to start making these systems start to know each other exist and start talking with each other, but that's, it's going to be challenging, but I think we're going to make progress on that. Just to give you a sense.

>> John Loonsk:

To follow up on our question, just one piece, I know you said, Greg, that there are issues of information and accessibility of information around Stockpile resources. But clearly, at the time when materials are distributed, it would be nice to have a handoff of the data that at that point are no longer classified because they are being -- it's the lot number, the amount of resources that are being distributed to a State, that could then feed into a local distribution and management system. And I guess that's not so much about how much, but about what and at that time.

>> Greg Burel:

We definitely provide that data when we do release materials to the States. They know what they're getting at that point, they know lot numbers, and they know this type of information.

>> John Loonsk:

But is that electronic?

>> Greg Burel:

I have to be honest with you, I'm not sure about the current status of that. I don't believe in all cases that it is electronic.

>> Tim Wiedrich:

I can answer that information, because we've tested it, and basically it is made available to us electronically, and in our system we in fact do upload it. So prior to the arrival of the push pack we would in fact, given normal electronic communications such as Internet, would be able to receive that electronically in advance of the push pack and be able to populate our system with it.

But I might say something that is going to make some people angry, it's not my intent to do that, but we have I think substantial disconnects that you've just put your finger on. And with all due respect to the SNS, we own it as well at the State level, we had a window of opportunity at the creation of this. And when funding was plentiful, not plentiful in terms of all the expectations but certainly more plentiful than it is now, and we did not have national standards for us to gravitate towards. And the RITS system, even though it is now being rolled out and put in place and is a very useful tool, it does not meet the needs that I just described moving it all the way down to the point of distribution.

And the difficulty that we have is that, as Tom's system is being described now, it's another layer, in terms of you know, me sitting on top of this system, not knowing ultimately how all of this interfaces, and what-- I'll just be really blunt here. I would scrap it all -- we spent 400,000 dollars on our inventory management system. I would scrap it all if another system could come in and provide the functionality that's necessary. My concern is I don't think we're having adequate dialog at this point to develop those systems, and so whatever does ultimately emerge in all likelihood I think will not meet local, State, and Federal requirements.

>>

May I ask a question? So maybe what I'm hearing is, and going back to your idea or request for suggestions, is it -- do we have a standard, do we have a vocabulary, to manage the Stockpile from the point of creating the resources, managing those, inventorying them, getting them to the States, all the way down to giving it to a patient, and following that information from where you store it all the way to the provider of the vaccine or pharmaceutical or whatever it is, and back up to your inventory to say this is how it's been used? Is there a standard that we have, is there a vocabulary, is there a data model?

>> John Lumpkin:

And I think that it's important to add another caveat to that: can Brian's 26,000 members speak that same language?

>>

Sure.

>> Greg Burel:

To answer that, I don't believe that there is a standard. We have bits and pieces and parts of that. And some of these are interrelated well, and some of them are not. So I think exactly what you just heard from, you know, the State's perspective, I appreciate hearing that, and I agree with you. I think that at the beginning of this thing we did not have the standards there to be able to do what you're suggesting, and I think that we need to go back and pick that up.

You know, another aspect of what's missing in the visibility of this, you know, we've talked about -- and you asked very specifically about commercial sector, and we've talked about Stockpile. We've not talked about the States' stockpiles, and that's another piece. Particularly when you consider an event that might occur and begin in one area, and then another similar event occur somewhere else. Or an event that's only in one area but across a couple of States, where other States who are not affected may have material that could enable that response. EMAC, the Emergency Management Assistance Compact, would allow the States to exchange materials and things of that nature. But we can't enable that any better from the Federal level because we can't see, you know, a current picture of what States' inventories are even.

So there are many points in the process where this stuff exists, and we need to know I think more about where it exists and what its availability is, and so on and so forth. And we're also focusing this discussion I think primarily I think in most minds about, you know, particular countermeasures. The Stockpile also maintains all of the ancillaries necessary to administer those countermeasures. So this is another aspect of that whole emergency response to such,to an event, that we need to understand what's there.

>> John Lumpkin:

Well, I think that we've gone a little bit over the time, but I think part of this questioning is what we will discuss right after lunch. I'd like to thank the panel for a very enlightening session. I think it will help us think through a lot of these issues in ways that we haven't looked at them before. And right now we're going to adjourn until one o'clock. For those of you who haven't been in this building before, lunch is right upstairs. And for those of you on the phone and the Internet, you're on your own.

>> Dave Ross:

John, this is Dave Ross. At one o'clock are we able to dial back in, or is it just going to be a closed meeting in Washington?

>> John Lumpkin:

Yes, it will be for -- it will be open for members of the Workgroup to engage in the conversation, and as well as the members of the panel who will want to stay, and then there will be time at the end of the meeting for public comment.

>> Dave Ross:

Do I call back into the same number?

>> John Lumpkin:

Yes.

>> Dave Ross:

Okay.

[lunch break]

>> John Lumpkin:

Good afternoon. At this point on the agenda we're going to spend a little bit of time talking about some of the discussions related to response management. And then, just to review the agenda, we'll have some discussion, updates on the status of the Workgroups, a little bit of discussion about prioritization of our recommendations to AHIC, and next steps and wrap-up.

And I'd like to welcome Steve.

>> Steve Solomon:

Thank you.

>> John Lumpkin:

So I'm going to toss out a little bit of a framework to our Workgroup and see how this sort of resonates with you. Having listened to this, it seems to me that there are two kinds -- two ways that we can sort of put together what we've heard today. One is we are -- we have on our agenda, we've made recommendations in relationship to bidirectional communication. And that what we'd like to see in bidirectional communication is the ability that if you see an outbreak of -- I'll use the case from my prior experience, of Salmonella agona which the local epidemiologist, and agreed with CDC, have traced now and she suspect that it may be related to a toasted oat cereal made by a company up in Minnesota.

[Laughter]

>>

(inaudible)

>> John Lumpkin:

And now we want to let the provider community, those who are treating patients, know that the public health system has identified this. And one of the things in bidirectional communication that you want to do is let them know that, well, if you're seeing somebody who has diarrhea and some of the symptom complexes that we're seeing, that maybe they ought to ask people what they've eaten, additional questions that may relate to that. And if you've got some information related to treatment recommendations, that that would go from the public health system and would be incorporated through the electronic health record into the decision support and other activities of the, of the EHR. So that's one piece. So the public health system has the capability -- the capacity to send a package of stuff. And part of that stuff may be the availability of -- because now this is a major outbreak and it's not just from food-borne illness, it may be due to a communicable disease that's either intentionally or unintentionally spread, like influenza or other nasty bugs. That there's availability of either the patient going to a distribution center and getting prophylaxis, a distribution center to get treatment, or for you as a clinician to requisition counter measures. So that can be included perhaps in the same package or the same kind of package that would routinely be used to send a communication that would not necessarily include the fact that there's stuff available. So there's information and stuff. That seems to be one piece of what we've been trying to struggle with as a Workgroup in making recommendations to AHIC, particularly around developing use cases.

The second issue here seems to be that there's an issue of how do we break down the silos. The silos that exist within the same agency, and I'm reminded of when I was in Illinois we had eight different systems that just dealt with HIV. Of systems that have been legacy systems, historically developed, that serve very important functions but for which there's no communication between the systems within the arena of public health. And creating a common vocabulary as well as a method of communication between those systems would be an important step. So I'm sort of describing two really big buckets of recommendations, and I'm tossing that out for you to tear apart.

>> Dave Ross:

John, this is Dave Ross. Can you hear me?

>> John Lumpkin:

Yes, I can, Dave.

>> Dave Ross:

You asked a question. Can I respond?

>> John Lumpkin:

Please do.

>> Dave Ross:

I like your description of two big buckets. Let me start just to lob out a couple of ideas about the breaking down the silos bucket, all right? I think that is no doubt one of the mega-issues and has been one of the mega-issues. Several of the speakers -- are all the people who spoke this morning also still there?

>> John Lumpkin:

Pretty much.

>> Dave Ross:

Okay. I think to some degree or other, many of them spoke around this issue. I think when it comes to making recommendations to AHIC, I think of the recommendations being in two forms. One are the things that are practical today, and things that will -- that is one category. And then the other would be the category of things that we should be working towards. So clearly all the effort that has gone on for quite a number of years now, towards building standards and getting endorsement of the standards for both syntactic standards and semantic standards are critical. And those are long-term efforts.

On the short term, I think that we could make recommendations of a type that Gary Urquhart’s presentation led me to think about this. That you've got an information infrastructure in place in a number of States, in the case of a Immunization Information System, that has several characteristics that we should be trying to endorse. One is they're population-based. Two, they're standards-based. Three, they are in use today by front-line providers and they, fourth, they create a public health to private provider linkage that is not totally unique, but pretty much unique in our health system.

Why -- for those immunization systems that work, and I think it's gone on, the whole effort has gone on long enough now to where we nationally have a more narrow universe of systems in use, and we know what works. That using that infrastructure and extending it to integrate other data sets within public health to make in effect a day-to-day usable system that, as Gary pointed out, is also useful in an emergency context, is something smart to do. We're building on an existing prior investment. It's readily leveraged and we ought to endorse that, is my opinion. We ought to endorse that more emphasis be put on that integration with the registry systems. There are a few State examples which Gary could describe better than I could, but Michigan is one of those where that's happening, where the front-line providers actually use it and it's sort of like a stripped down EHR. But we ought to build out of that existing infrastructure where possible and emphasize and start some of the integration at the public health level. That to me, on the practical, immediate side, the kind of recommendation this committee could make.

>> John Lumpkin:

Other comments? John?

>> John Loonsk:

John, you suggested two broad buckets and one was on bidirectional communication. I must admit that for me the bidirectional communication area is still a little diffuse. I think there's a whole area of alerting and communication that we hadn't really talked about. There's the area of getting information to be shared amongst the clinical sector, and between public health and the clinical sector, that needs to be fleshed out more. I'm not sure we've delved into all that. There are those who want to talk about population-level data that are available at the provider level. And I don't think we've necessarily fully talked about it. I think there are important issues. I'm not sure we've delved into them. What I heard today was good discussion about, and presentations on, some functions that include stockpile, commercial sector, supply chain, distribution, and some degree apportionment which, in other words, what do you do when resources are not apportioned appropriately, and how do you use information systems to support that?

Administration registries, we touched on a little bit of adverse events. I think one of the things that was clear in the smallpox program was that in certain circumstances you need to pay even more attention to adverse events at times in an emergency or in a program like that where you can't just accept passive surveillance. You have to look at active surveillance and think about accumulating those data. And we have clinical EHRs and emergency room-based systems and clinical -- you know, one of the things we didn't touch on in a huge way was the fact that a lot of the administration of this happens in a clinical setting. And so we have public health clinics, we have fairgrounds, we learned, drag races. But we also have clinical administration in clinics that are in clinical settings that need to be part of this as well.

This is just a classic example of a standards problem that still is waiting to be advanced. Because experience says that while in some cases, for example, the registries have taken some of this up. In some cases registries are not doing as much of the administration as they are the recording of immunizations that have occurred. And that there are -- there's large variation in that.

I think it would be very helpful to talk about the data at this point. And some of the kinds of things that we could be talking about in terms of making recommendations. It seems like we're talking about some data that are at an inventory level, and some data that are at an individual level. And that these data relate to vaccines, they probably relate to blood, they relate to prophylaxis and treatment, anti-virals, antibiotics. We heard some discussion of isolation and quarantine, another type of data different still. And there may be some more. But that a focusing, one way of focusing this is think about the data that have to flow in different ways in different localities. And sometimes the clinic that will administer will be at a hospital, sometimes at a fairground. Sometimes there will be a robust registry that is supporting both childhood immunization as well as emergency administration of countermeasures. But by focusing on sort of the functions instead of the systems, what needs to be done and to focus on what the data are, we could try to bring some of this into focus.

>>

I apologize for missing the superb testimony that I know you had this morning, so obviously I can't comment on that. But I did want to -- when I hear the term bidirectional communication, one of the things that has come up fairly recently is the idea that we may be leading ourselves awry when we talk about bidirectional communication because it implies sending information from point A to point B and back again. And one of the things that people are talking about in some places, and I know that the more sophisticated folks here know this already, but some of us who are less sophisticated, I think get misled by the concept of bidirectional communication. Because what we're really talking about, potentially -- potentially -- is really having information very broadly available. Putting the information out there into a Web or almost an Internet system. The alternative concept that recently some people have been talking about is that it's more like pulling TV signals or broadcast signals out of the air. I mean, the broadcast waves are out there, the data may be out there, to pull certain types of data, like the difference between broadcast radio or satellite radio, or you know, TV or satellite dish or cable TV. You have to have certain equipment to get those signals. You have to unscramble them. And again, I mean, there's nothing new about this. A lot of people have been talking about this. But for the less technologically sophisticated among us, bidirectional communication, that term sometimes gets bound up in the back of our minds with two tin cans and a string. Whereas, what we may be talking about is a much broader grid system or some kind of distributed network with a lot more data floating in there. And that the issue is who gets to pull it out, under what circumstances. So you know, that's just, that's actually just some fairly recent discussions that have come up.

>> John Lumpkin:

Let me push back a little bit. Because, you know, using hierarchy that I heard, I forget his first name, Wilson from Stats Canada -- Mike, I think is his first name -- described, which is most clearly that the hierarchy between data information and knowledge. And that data was analysis was information, information was rules, is knowledge that we're not necessarily in a bidirectional function. It's not the same things that are going each way. So that the public health system adds value to the data by creating the analysis and the result of that analysis, then, is sent back to the system. And analysis may be coupled with rules, and so you’re actually thinking about a bidirectional system through which different things are flowing and the characteristics of those things that are flowing require different kinds of systems and capabilities, so that it may be that data about individual patients are coming in from the clinical care system, and APIs or other kinds of knowledge management tools are then sent back to help or to enhance or to modify the decisional support components of the electronic health record. So I think when we try to look at it from a little bit different cut, we begin to see that what's the value added? Why is it that -- what is the case, the business case, then, for someone who is seeing patients in the emergency department to want to play? And the answer is they can treat their patients better.

>>

I can give you a very concrete example of that, which is in a lot of work that I do, we do a lot of reporting to clinicians of EHR data, and immunizations and pediatric immunizations are a hot topic. The pediatricians in particular want to know, give me a list of my kids who are due for X or overdue for Y. And for us, we know that things that were administered but the logic to figure out that this combo vaccine given at this time counts, doesn't count, how it fits in, it’s a lot of maintenance for us, for my team to do the knowledge management to understand, to create the report that's actually useful to the clinician. And I wish there were some public service we could just consume that would -- we could apply to our data and I know it would generate the -- sort of roll things up in the right way and we would know how it works. I recognize that is a little bit of ways from response management but it's very much maybe that’s data information knowledge.

I did have one other comment, though, which is if you're going to do -- actually, I'll just try one other analogy. But when a hospital or health system does information systems, and you know, you may start out and say well, we want to do a bunch of cool things. We want to have alerts and reminders and adverse event detection, decision support, you think about all the really cool stuff. But then somebody starts being a party pooper and saying, well, do you have a place to store the patient's data, and do you know how to identify patients, and do you know how to identify the providers, and do you know -- really basic stuff, like, I don't -- you have to do that before you can do the cool stuff. And I kind of wonder, on the public health side, if there's an analog and the one that I would maybe throw out there on the patient- or person-level information is if you have an immunization registry, for example or if you're collecting any kind of information on individuals, how do you identify an individual and link their data across multiple sources? So if you're getting immunizations from North Dakota and immunizations from Minnesota and you’re scanning a driver's license in one State and getting an insurance card in another State, whatever, from the electronic medical record and you want to combine that information, I sort of wonder if that's not one of the standards that really is one of those foundational building blocks that could be the subject of a recommendation.

I think there are others, but person identity is one, provider identity is another. Locations of care is probably a third. I mean, there's other ones. But fundamentally, who is a person is something I'm not sure that we've solved.

>> John Loonsk:

There are few pieces that were discussed this morning, and just now, that actually have already found a place in the process that’s being advanced in the national agenda. One of them is relative to identifying the patient, we don't have a national patient identifier. And the architecture that's being advanced is to have -- to hone down on a standard set of demographic data that would be associated with a patient that would be used for probabilistic matching and logical association of data. And it’s one of the things that the Nationwide Health Information Network has been working on. The HITSP has identified some of the data for that, to do that, still obviously more to come but it's an important point.

From a provider identifier standpoint and from a credentialing standpoint, one of the things that went forward in the emergency responder electronic health record use case, was the need to be able to facilitate provider access in emergency settings, care settings, in other contexts. So obviously if you have an emergency and you need to bring providers in or move patients out to a different setting, you need to be able to identify the provider and so some of those types of data and the needs to be able to share credentialing and provider identification information in that regard have been touched on, they're in flight, in the process, not by any means concluded.

Hospital bed utilization is one of the things that went through in the biosurveillance use case and that was touched on a little bit as one of the utilization elements of response, is knowing bed count and knowing where there's dynamic bed availability and how to apportion response in that regard as well. So I wanted to just touch on those because those are three areas that at least that are, to some extent, in flight.

>>

Should one recommendation be that at some point in the future we try to have an inventory of the various types of systems or tools that are throughout that we know of to sort of have one place to start to figure out where the pieces of the big puzzle, just as -- throwing that out.

>> John Lumpkin:

Well, what if there were a National Center for Public Health Informatics? They could do something like that.

[Laughter]

I'm sorry, that would be too much to hope for, right?

You know, I think that -- that there are some obvious low-hanging fruit in regard to this. You know, we need to look at what Tim shared with the system they're doing in North Dakota, what's happening with the Strategic National Stockpile -- I still want to call it the national pharmaceutical stockpile but that just shows my age. Actually, you don't have to be that old to remember that, do you? Just a couple years ago.

But I think that there's some obvious areas, particularly when you focus at response management, where looking at doing an inventory of what's being managed and what are the systems in place. I kidded Brian earlier, but the overlap with the system particularly the emergency medical services system, you know, I think we still need to find out a little bit more about what's going on and the folks who tend to gravitate around Homeland Security, the emergency management agencies at the State level and local level. There are a number of systems and once you begin to inventory those, at least you have an idea of the universe that you need to encourage to begin to think about having their systems talk across the silos.

>>

John, are you identifying some gaps that you think perhaps we have in the testimony that maybe we need to consider for later testimony? I know we'd initially talked about both EMA and EMS, as well as DHS.

>> John Lumpkin:

Well, Tim's a recovering EMS guy. I think, you know, I don't know if we necessarily need to do this in a hearing but certainly would want to perhaps get written testimony from experts in those areas. Other thoughts? Now, we do have a Workgroup so we don't have to solve this problem today. We can pose issues that we would want the sub-Workgroup, the ad hoc group to consider as they bring forward recommendations for us later this summer.

>> John Loonsk:

Well, I heard and we can speak about Greg since he's not here, but I heard Greg talk about an openness to considering the ways in which data from the Strategic National Stockpile could be shared, given the security issues obviously, but so they could be shared between information systems in ways that could be facilitative of the standardization in that regard.

I do think that this whole area of the commercial sector supply chain and what can be done to facilitate communication and awareness of countermeasure availability is one that could -- that the working group may want to explore further what the issues are, they're clearly proprietary business data issues, but on the other hand since such a substantial portion of countermeasures are in the supply chain at any given time, it would seem pretty important that, from a national standpoint, that we have an ability to understand where those countermeasures are.

I think that one of the things that we didn't delve into very significantly is this issue of the relationship of adverse events when you're doing an emergency distribution, what are the, what are the data and when do you -- can you realistically get them versus when you can't. We heard a little bit about pandemic that there's an estimation that initially there will be case management and contact tracing. And then at some point there won't. And it moves to broader messages. Well, what's that point?

And on the other hand frequently in the past we've heard about the sort of the analog on the countermeasure side which is that in an emergency there's going to be a need to push pills out as quickly as possible and you won't accumulate data because you won't have the time. And you know, I think some of us who have been involved in particular emergencies have actually not seen that scenario, but seen a lot of intermediate scenarios where understanding who got the pill, understanding and tracking where the pills were, were critically important and information systems could help, so where's the line there relative to an emergency? I think those are both important areas to talk about and delve into so that we can upgrade our clarity on those as approximately.

>> John Lumpkin:

Although as I listened to your comments, I was struck by a memory from the late '80s when I was doing some work with HRSA in Egypt in the emergency response system, and I visited this hospital in Luxor, and it was smaller than the area in and around this area and they told me that they saw 26,000 patients a year, which -- I was pretty impressed for an emergency room that size. And so I said, well, can I see some of the charts. And they said, charts? Well, if we filled out charts we wouldn't be able to see that many patients. And I think that’s true, because they didn't have a system in place. And it seemed to me the system that Tim described of doing bar-coding both of the pills and the driver's licenses, is a way to maybe not get the full bore of information that we get. And I think that's the other piece. Is what is acceptable in an emergency? Well, that's all dependent upon planning. Prior to Louisiana LINKS, it would be acceptable in a mass evacuation for kids to get over-immunized. But because of the LINKS system, that no longer really ought to be acceptable in this country, and I think we need to think about that in regards to the standards we set for the system.

>> John Loonsk:

Couldn't agree more. I've just seen this argument being an obstacle to the advancement of information systems in this regard, and I think getting some clarity, going through the exercise of discussing some of those lines would be very helpful in bringing to light some of the very issues you were talking about.

>>

Could you restate what the argument is?

>> John Loonsk:

Well, in the countermeasure administration side, the argument was -- and a lot of this was under the pressure of having a system in place to get things out as quickly as possible and the very superficial rationale was you're going to push it out and you can't keep track of who gets it because there's not enough time to track that, that it's going to be an emergency distribution, you're going to be spending your time exclusively on distribution issues and not on information systems or management, information management issues. And we've heard this in a number of different settings over the years and I just think in terms of the scenarios we've seen, in terms of systems that actually could be very facilitative of rapid distribution and help with apportionment because you don't want people to be taking more than they necessarily should be taking. The realities of it are information systems could be very helpful in that regard. That's on one side of the equation.

On the other side of the equation is when there is a major event, it's how long do you track, how long do you monitor the cases, how do contact tracing, and when do you recognize the fact that it's really beyond that which you can do that for. And then you have to do broader public messaging about social isolation and about hand-washing and all those preventive measures that one could take. And I just -- I think it's been an area that hasn't been well discussed, well defined. And it is particularly relevant in the pandemic flu arena because I think we all feel, you know, some of us may have felt that going into SARS, this might have been a highly communicable disease and we would cross that threshold. We never did, though. It was actually a management of the outbreaks and clusters of outbreaks that actually was very effective. When does a SARS-like scenario turn into a pandemic flu scenario where you're just doing the messaging? That line is not a clear one and it's not clear to me, at least, at what point in a pan flu exercise you make that cutoff.

>> John Lumpkin:

One of your comments, just to branch off, raised another area that we haven't really addressed. And that has to do with quarantine, and quarantine management. We don't have a lot of experience with quarantine, except for some lawyer that recently got -- anyway, but if you really are going to have an effective quarantine and somebody needs to stay in their house, well, if they're in their house, how do they get food? How do you make sure that people who are now forcibly restricted, that the kind of management system that would need to be in place, that would think about those other components of a health response, is -- and again, this is not -- you know, when I think about this, I think about the term registry, and not think about it in the public health sense of registry, although we used the term first. But more in the term of what's being done with disease management. How different is a system that manages people with diabetes to make sure they get the appropriate treatment and at intervals is different from actually managing somebody who is under quarantine who needs other kinds of supplies.

>> John Loonsk:

I think that's an excellent example, and one where my fear is that the concerns about sensitivity of trying -- of considering managing data about someone who is confined to their home, may overwhelm the needs of being able to identify those who are in their home and need support resources, which is much -- sort of a much more positive aspect of it, and but critical in terms of that kind of basic public health tool that is tried and true in -- and the evidence of its utility in terms of isolating those who are -- have a communicable disease.

>>

We do isolation for TB, and the nurses are there figuring out how to keep them home. So that is going on. There are probably models we can look at for that. You know, making sure they have food, that whole thing.

>>

Isolation and quarantine law, isolation for people who are sick or quarantine for the exposed is tjat the local health departments would help with contacting those individuals and making sure that they have access to what's in statute, have determined to be important basic services, food, shelter, communication, facilities, access to medical care, and things like that. We haven't done it. But we do manage tuberculosis cases all the time, but this is a very different kind of scenario, and we haven't practiced that part.

>> Brian Keaton:

This is Brian Keaton. One of the other things as we put this on the table, that concerns me, we talked about bar coding and we’ve talked about a lot of technology. From a practical standpoint, what do we do if the power goes out? And we're building ourselves into these systems. I mean, we know when polio was around, it was what, eight patients a minute that got vaccinated. We could never duplicate that with any of the systems that we have in place now, relying on technology. What do we do with a Katrina or something more focused or a terrorist attack that takes out the power grid or does whatever? We're building our systems around the, maybe the redundancy of the net or the redundancy of a network or those other protections, but there are things that are much bigger than us that we can't protect. I think we need to have that kind of contingency in the background as well. Sometimes going back to the simple in the truly chaotic situation. There's going to be a place for that, too.

>> Paula Soper:

You know, that comment, as well as some of John's comments about the supply chain really makes me think that we need to hear from some of the work that's going on in the Sector and Government Coordinating Councils that are co-chaired by DHS and HHS. You know, they have been having discussions and a lot of conversation post-Katrina about supply chain issues, a lot of lessons learned, especially from the private sector, about the kinds of information flow that needs to happen, the kinds of information flow that did not happen, information that should be flowing all the time prior to an emergency, so that resources can flow quickly at the time of an emergency. They're also working on protecting critical infrastructure and certainly health information technology is critical infrastructure. I know that they've looked at it in kind of a cursory way but it may be a area where we can either inform their discussions or they ours. And figure out how we can work collaboratively on that.

>> John Lumpkin:

Go ahead, Tim.

>> Tim Wiedrich:

This is Tim Wiedrich. If I could just follow on Paula's comments. In 15 minutes I need to participate in a teleconference with the Department of Homeland Security and a specific initiative that they're working on to take the emergency management information systems and roll them up so that the information systems that emergency management utilizes can in fact speak to each other. And this conversation we're having is about pandemic influenza and building scenarios in terms of the types of communication messages that are flowing during emergencies and we’re there having conversation about the public health components. It seems to me that this committee and that effort really could have a linkage because I think that you could really drive a lot of that conversation that's happening in a broader context.

>> John Lumpkin:

But I'm going to --

>> Paula Soper:

Go ahead.

>> John Lumpkin:

-- suggest that one of the major challenges of any organization that's trying to deal with information technology is scope creep. And since our focus is on information, the uses of health information technology, I think those are all important questions. But one of the neat things that has happened since I'm no longer a State health official, I don't have to worry about those. But we are charged to think about how health information technology can facilitate that, and then I think we have to turn it over to other committees to think about, okay, what happens when what we come up with isn't available because of the characteristics of the disaster.

>>

John, you talked about breaking down the silos. I think one of the things that lends to the silos is that there's a great urgency to build solutions and you can't have a lot of the communication, you can't get the input that you need when there's such an urgency for a solution. If a grant comes out, if funding comes out, and there's two years to create these solutions to some problem, we're not going to have the input we need to be breaking down the silos. So perhaps one way the committee could highlight that would be to recommend around that either funding is much more long-term and requires some sort of input, or else that the planning is funded, that you're planning to do the collection of the input from the various members. And there's -- from the various parties, stakeholders. And there's, you know, the grant is requiring that input be gathered from all these things, that the requirements be developed from the various users, or the uses be defined as opposed to providing a grant to create the solution to this problem. You know, we get a mandate to do this or to do that. We run around like a nut coming up with a plan that's not going to be very effective because we don't have anything because we didn't have time.

>>

John, I want to support your comment about scope creep. It's very, very difficult, all these systems problems and in an emergency, a national or regional emergency, how information systems contribute to a command and control model, as opposed to a broader information or knowledge access model, operating within parameters, can't be solved by the development of the information systems. The information systems need to be there. I mean the, the lesson of Katrina, one lesson, perhaps, is having no one in command and no one in control is a bad thing. But where the command and control authority sits, how that's exercised, and the extent to which there have to be multiple nodes of command and control for different aspects of emergency response, is something that I think we're all still working out. And that's what those kind of phone calls are about.

But I just want to support your point that our obligation is to figure out how to make the information available in the best possible way, so that whatever system solutions are worked out, to hopefully put the right people in command and give them the right level of control over assets and resources, they've got the information that we've provided to them to make the right decisions.

>> John Lumpkin:

So we have about 10 minutes left in this portion of the meeting. And so I'm going to give people an opportunity for last words. And then we're going to turn this over to the ad hoc group on response management. Last words?

>> John Loonsk:

One of the things that was done in the biosurveillance activity was to develop -- it was a similarly complicated area, was to develop a few very practical scenarios, and then to look at in this case it was the data about, it was what data would be applicable in those scenarios. I think this would be amenable to a similar process whereby if the working group could come up with some easy to understand scenarios that had a little bit of variability in them so they could span some of the activities, that would help put in clearer focus some of the data needs and some of the data exchange needs that might be talked about relative to the testimony we heard today, and some of the ways in which the silos need to be broken down, and I think from a number of standpoints that would be very helpful.

>> John Lumpkin:

And let me follow up that suggestion with a request to members of the panel, but actually looking at the end of the table, where ASTHO and NACCHO are. I think that would be a very useful thing. I know that most States have gone through various scenario planning as part of the preparedness process, doing table tops and other kinds of preparedness stuff. And I think John's suggestion is an excellent one, and having the kind of scenarios that actually address the issues at the State and local level and then working with the Federal partners to have a -- to then come up with scenarios that address those different components, look at the silos, both the horizontal silos, the ones that sort of in parallel as well as the vertical silos, which are State, local, and Federal.

Any other last words?

>> Michelle Meigs:

I'm Michelle Meigs, I’m from the APHL, actually, sitting in for Scott this afternoon.

>> John Lumpkin:

Welcome.

>> Michelle Meigs:

Back to what Dr. Solomon was saying about bidirectional communication and the kind of ambiguity -- and that word gets thrown around a lot, bidirectional communication. I was thinking that maybe a better way of stating it might be multi-directional communication, taking into account that in an emergency situation or in any domain, you have to know what partners need the information at the same time, and there should be some way in each of our domains, laboratory, you know, response management, to be able to distribute that data simultaneously to our various partners, instead of point-to-point contacts. So that may be a better way of stating it, I don't know. Throwing that out there.

>> John Loonsk:

I think it would be a good subject for a subsequent meeting of this group to talk about particularly coming from the focus of the clinical care sector, but how access and sharing of data with public health and from public health and betwixt and between the clinical sector could be facilitated. And I think that's a -- we've talked about talking about it, I think we could finally do that.

>> John Lumpkin:

Which -- uh-huh. Okay. Any other last points?

I'd like to thank the panelists. As you can see, your comments and input gave us a lot to work on and has actually moved us far along our path of at least trying to identify what it is we need to do. And we appreciate you traveling here on a Friday afternoon, and we wish you safe travels. You're more than welcome to stay for the rest of the meeting, but you’re not required. So thank you.

The next item on our agenda is to get some updates on our various workgroups, and the first one is response management ad hoc workgroup.

>> Laura Conn:

Hi, this is Laura Conn. Can you hear me? Hello?

>>

Hello.

>> Laura Conn:

Hi, can you hear me?

>>

Yes.

>> Laura Conn:

Okay, great. This is Laura. I'm going to step in since Scott had to leave early today. And I hope that you have, that you can see the proposed timeline up on your slides. You can see those first three grayed out meetings have occurred and I'll give you a little bit of a update of where we are from those and then you can see the schedule going forward, which may be adjusted a little bit from our discussions today.

In thinking through recommendation of -- in the first, in the first two areas that we heard testimony on about outbreak of an event management and laboratory response, we heard three things that we sort of felt were overarching from that first day's testimony, and I think we validated them in some of our conversations today. And we're working towards recommendations around workforce development and recommending something similar to the AMIA 10 by 10, building off of what CDC and the University of Washington have done in developing informatics competency and the CDC informatics fellowship, so we're going to be exploring that a little bit.

A second recommendation around evaluating and strengthening the IT infrastructure for interoperability. We've heard that there's disparities and infrastructure costs across all levels of public health but specifically in the interoperability categories, the thinking of how we can do that.

And then the third overarching recommendation is establishing preparedness metrics so we can really demonstrate the ability of these functions to be carried out by public health.

And then moving on into outbreak and event management, we talked about convening a group to define the functionality, security and interoperability needs of systems to support outbreak management, the need to support development and testing of software systems that can support those functions that are defined by a broad group, and the need for freely distributable software to support those agencies that need it, but also the need to develop implementation guidance for those requirements for localities that want to provide those systems or have systems that they can augment to provide the support.

And then in the lab area, we have four areas, the first is standards for lab reporting and requests, and to support the public health case identification. Excuse me. The second is to define uniform architecture for messaging structure for interoperability. And then the third is to promote examples of how health information exchanges can serve to advance lab result reporting and we talked both about the CDC RFPs and the NHIN contracts that will be coming out as a potential place to be able to do that. The fourth was to explore the concept of a clearinghouse for messaging system collection, and transmission of lab results for public health purposes.

So that's a summary of where we are today. We'll take up these next topics that we heard about today in the coming meetings and anyone is welcome to join us and we'll be sharing draft letters on the schedule that you can see.

>> John Lumpkin:

Great. Any questions? Shu?

>> Sunanda McGarvey:

If you're not currently on the response management ad hoc group and you'd like to be, please let me know, because the information is going out to the subset of people who had responded to say they were interested in working on that. So if you're not on there and you want that information, let me know, I'll send it to you and include you.

>> John Lumpkin:

Great. Let's move on to the adverse events update.

>>

We had a very exciting time with adverse events. One of the things that has come up is the new approach -- well, I wouldn't call it new approach -- but an evolved approach to making recommendations. At Tuesday’s AHIC meeting Rob presented the report cards on the recommendations that have been made to date, and those are going to continue to comb down into green, yellow, and red. And no one likes to be red. So I think that and the AHIC successor discussion has really caused to us think, to really focus on developing really achievable and doable recommendations, and we've talked a lot about what's doable, what the scoping is, and I think we with some just absolutely great input from people like John and Amy and especially Lisa Rovin, because so much of this is bound up with the FDA-related issues, I think we're really focusing down on what may be a relatively small number of achievable, well-defined recommendations which at the moment really focus on things like the ICSR, and the BAERs, and figuring out how to get those implemented, effectively, and how to really standardize and harmonize some of the data elements, some of that standardization in ICSR and BAERs has taken place. Now we're looking more broadly at what are the steps and tying that in with the input we've gotten from Shawn Fultz of the VA, from Amy about AHRQ, and how does this move the ball down the field? So I think we're getting much closer. We've had some very energetic and exciting conversations, but I feel real good about where we're at now.

Amy, John, any thoughts about that?

>>

You know, I think it has been helpful for us to as a Workgroup take the larger set of recommendations that we would initially drafted several months ago and really start to winnow through those and figure out what's going to work, especially looking at the year and a half timeline left of the AHIC.

>>

I don't have much to add. I'm looking forward to trying to squeeze something in on adverse event detection, as well as reporting, but I think we've settled in a really good place.

>> John Lumpkin:

Great. Which brings us to our -- if there are no other questions on that -- to our next portion of our discussion, prioritization of the Workgroup activities and looking at two issues. One, what we're going to be doing next as we're sort of -- Tomorrow. Yeah, for those on the Internet and thinking about coming to the Humphrey building between 8 and 4 on Saturday, the power could be out because of maintenance. But for the rest of us who are planning to be as far away as possible, the notice that we saw on our computer, and you hopefully didn't see over the Internet, is not applicable.

So the two issues that we have before us is what we will discuss next after -- now that we've completed the hearings portion of adverse events and obviously we have work to do to get that fixed up to be a recommendation, is -- and then we'll have some discussion about our focus in the next round of use cases.

So one of the areas that we have discussed about is -- and I see what's up there but now I'm confused.

>>

Clinical decision support triggers. Lauren, are you -- do you want to shed some light on what exactly the subgroup on clinical decision support is looking for this Workgroup to consider and prioritize? We're fortunate to have -- do I have your name right, Lauren, here today who is actually in charge of that subgroup.

>> Lauren Kim:

I'm certainly happy to, but then we have luckily Dr. John Loonsk here. John, if you wouldn't mind, I would defer to you, if you could sort of summarize where we are with that.

>> John Loonsk:

Sure. I think people know that there is a cross-Workgroup working group on clinical decision support, which has been -- had a couple of meetings and calls to begin to put into place some of the considerations for clinical decision support that can support a variety of different activities in the different working groups.

The discussion heretofore included a few different things. One was the fact that there have already been a number of clinical decision support-related activities that have been identified in the medication management domain in the context of some of the other use cases and there's a desire to try to bring in this next round of use cases some very focused support for a generalized approach to clinical decision support. So we have, we will next week put out the current set of use cases which include medication management, quality, and clinical -- consumer access to clinical information, and then there are six additional use cases that the AHIC did not prioritize last time that are -- but asked us to work up over the course of the next several months and have available for possible use in the next -- by December.

John Lumpkin presented this committee's work to that process, and so the intent is that for this working group and for the clinical decision support working group to feed in more information on how clinical decision support can be supported in the context of those next round of use cases.

There's also been discussion about, in the working group, about how to very practically pick off one or two examples of clinical decision support opportunities which this group may want to comment on, that could -- for which prototypes could be developed and advanced and tried to work through to completion. So one is sort of a broad activity and the other is a very focused activity to try to identify a couple of examples that can be advanced and moved through the process to try to get them actually into electronic health records and support them in that context.

So I think what the desire here, from this working group, is to A, identify very specific possibilities for clinical decision support that it views as viable moving forward, and B, to try to relate the broader area of clinical decision support to the activities we're involved in here, and try to bring forward suggestions for how that can be advanced. Did I do a reasonable job, Lauren?

So two sort of requests. One, possible examples that are very concrete, to pick up on a couple that have a reasonable timeframe for achievement, and that specify -- that could be advanced. And the second, to, a little broader, a little more diffuse, to think about general clinical decision support needs as they associate with the focused areas, the functional areas that this working group has talked about.

>> John Lumpkin:

So let me put that a little bit differently. As John mentioned, we have a recommendation for a use case on case reporting. There seems to be an opportunity when we look at what we've been discussing with adverse events reporting that talks about, that ties in with John's discussion of clinical decision-making and clinical decision support. And so the question is, since we've already got our foot in the door with the case reporting, can we think about harmonizing our conceptual model for the use case in such a way that we can address the mechanism for doing case reporting, in the broader sense and tie it in with our adverse event reporting.

>> Sunanda McGarvey:

The fourth bullet on our screen up there. These other ones, these other ones came from areas that had been touched on by this workgroup over the past number of months, from, over the last six to nine months. And John Einbinder, you, earlier today you expressed another area where clinical decision support could come into play with having the vaccine information and the vaccination schedule information and knowing what vaccinations had been delivered and what combinations worked at what time. So that ties into the first bullet, the integration with registries. But from the other standpoint, what information are you getting from registries?

>> John Lumpkin:

So not quite knowing how to interpret the silence, let me push it a little bit differently and say, would that be a task that the adverse event reporting group would be willing to take on, since that would be the mechanism to do that?

>>

I think it could fit in well with what we are exploring, Steve, and our recommendations. The two that we're putting through with Lisa and FDA or ISCRs and EHRs. Lisa, I don't know if you're on still, but looking at that last bullet point.

>>

I think so. But obviously it will impact on our timeline. So we would need to rethink our timeline if we're going to -- but, you know, it makes a lot of sense. This is where the action is.

>> Sunanda McGarvey:

I know Lisa had mentioned that she was called away at the last minute, and she did want to be involved in this discussion of prioritization of the clinical decision support components, as well as prioritization of next level use cases.

>>

I think we have a call next Friday so we can just put this near the top of the agenda to just address this issue. I mean, I agree with Amy. I mean, this is what it's all about. But we need to -- I mean, no buts. Why don't we just do it?

>> John Lumpkin:

I think my concern is that knowing what's on the agenda for use cases, when you've got your foot in the door with one use case that's already been presented to AHIC and I think we had some sympathy, although it didn't rank up to the cut, but there was certainly a lot of interest in the issue of case reporting. We were battling against quality reporting, which I really felt kind of schizophrenic on. But I think it would be difficult to imagine that in at least a relatively short period of time that if we were to recommend a adverse event reporting use case separate from case reporting that that would make it through the priority process very quickly. I think we may be able to have our cake and eat it, too.

>> Richard Haberberger:

This is Captain Haberberger from DOD. I was just wondering, are we focusing on just hospital-based situations, or is this also to include private practices and outpatient clinics?

>>

In the long-term, it's as broad as possible. I mean, how we get there, you know, clearly a lot of what's being done in terms of providing physicians office systems, there’s a lot of discussion about this. And in fact some of the beneficiary, the pharmaceutical beneficiary systems offer some of these although they're somewhat primordial. They offer these as selling points. So I think, I think it's just a question of phasing. The answer to your question is obviously this has to extend down the road to anybody writing a prescription for anything. But obviously there's a question of phasing and what do you tackle first and what's achievable within a reasonable timeframe?

>> John Lumpkin:

And I think that the vast majority of reportable cases are going to occur in the outpatient setting. That's where the challenge is, I think. At least in my experience hospital-based reporting is much more robust than in the outpatient setting, particularly for the things health departments want reported.

>>

I think it seems like a fascinating area, but I think there's sort of two, as I look at it, there are kind of two bucket, we'll do the bucket thing here again, two buckets of stuff up there. And decision support applied to populations, as opposed to applied to individuals. If you open an electronic medical record and you get a reminder that this patient is due for this vaccine, well, that's sort of the state of the art decision support today, you know, you open a patient's chart, you get the reminder.

To do population-based decision support, I think there's sort of stuff that happens at the patient level that then accrues to the population. So an event happens and now it gets entered into a registry, and there's decision support you apply to a population and then percolate back down to the individual. Trying to think of a example -- again to the immunization registry, deciding that patient is due for a vaccine, notifying the clinician as opposed to the vaccine was administered and the event gets reported to the immunization registry. And it might be a useful way to think about decision support, is what takes place in the -- where the decision support takes place, and what the communication is between the individual care and the population registries. I think the registry piece of this is to me the really interesting part.

>>

And just to build one step on top of that, which may be where you're going, is once you have the demographic information, are you learning on a population basis whether there's one ZIP code or one group that isn't getting -- I mean, are you seeing a -- rather than your missed opportunity for immunization, you know if that 5, that 8 percent is spread, is it focused, which means that as a public health professional you have to respond as you would as a clinician to an individual patient, you then have to respond in a different way. And otherwise you only find out about that, those missed opportunities when the outbreak occurs in that population. So wouldn't you much rather know about it in your database rather than waiting until they're all with the disease in the ER, you know, mumps.

>>

So --

>>

I'd like to -- I mean, I think it's a good plan to have the adverse events group look at this. But to me this idea of decision support earlier John mentioned about consuming a knowledge base of information of value to either the individual or the population. This is just one instance of decision support with adverse events. There will be a decision support system as well, I think, for case reporting. So it's adverse events or reportable diseases that just -- other examples. And I think that when we get back to the discussion and go in depth into what bidirectional communication means, what drives the bidirectional communication should be decision support, that consumable information that's available to public health to run on that individual's record or a population's record, and decide this kid needs an immunization, or there's been a group of people who have a salmonella outbreak and now every person who comes in with diarrhea, we should be thinking about that.

>> John Lumpkin:

So I'm going to suggest that this is the second time we've gotten to the point where we need to, where we've talked about we need to have more discussion on this. And so it almost seems like a consensus that this is the next issue that we need to take up as a Workgroup. The broader issue of bidirectional communication, decisional support, how that all fits in, both decisional support in the population sense which is not a function of electronic health record, although it may drive and provide enhancements to the electronic health record, and other components that came out of some of our discussion today. So if we're agreeable, we will put that as our next item on the agenda, as we're working through adverse event reporting, completing that, completing response management, the next step for us would then be the bidirectional decisional support piece.

>> John Loonsk:

I do want to add relative to the clinical decision support piece, that it's several times now that we've heard about immunizations and -- as a possible clinical decision support feed-in that's relevant to our activities. And Gary is not here anymore, but just waving my hand at his placard there, I know that he would say how important that is, and how mature some of that infrastructure is. So both from the standpoint of guidelines for when immunizations need to occur, as well as the registry infrastructure he did talk about. So I mean -- I'm sorry?

>> John Lumpkin:

And the HL7 standard.

>> John Loonsk:

And the HL7 standard. So I would like to put on the table that if we're going to be prioritizing clinical decision support coming from this group, I think that's an excellent one to think about, because it's something that might get some immediate traction with others as well.

>> John Lumpkin:

And tie that in with the ability of the registry to be used to identify when there's an adverse -- there's a bad lot and so forth.

>> John Loonsk:

You've got a cycle there.

>> John Lumpkin:

You've got a nice cycle there.

>>

(inaudible)

>>

That goes back to Dave's comment earlier about doing something that's relatively practical, something that we can get our hands around, rather than more of the futuristic stuff.

>>

Yeah.

>>

(inaudible)

>> John Lumpkin:

Well, great. So we've talked about clinical decision support, prioritizing our work, harmonization of our use case recommendation, and next tasks. Do we have other items that we need to talk about before we go into public comment? Then let's move to public comments.

>> Jennifer Macellaro:

This is Jennifer. Matt had to step away. You should see a slide in just a second that has a number for people to call in who are listening over the Web. Anyone who is already dialed in just needs to press star-1 to alert the operator. And there's an e-mail address if you’d like to write in comments after the meeting. I'll let you know if anyone calls in in a minute or two.

It doesn't look like we have anyone calling in on the phone today.

>> John Lumpkin:

Then we stand adjourned.