[This Transcript is Unedited]
Hotel Monaco
225 North Wabash
Chicago, Illinois
DR. LUMPKIN: Good morning. My name is John Lumpkin. I'd like to welcome everyone to Chicago and to the state of Illinois, and encourage all of you while you are here to enjoy Michigan Avenue and other locations, and spend a lot of money, because our revenues are down significantly in this state, and it will help impact our budget if you will spend money here in Chicago.
We crafted a very beautiful day for you today, so even though we are going to be inside for most of it, it should be wonderful this evening, and there are a lot of attractions. So once again, welcome.
We have a very important panel. As all of you know, the work group forwarded to the full committee, and it was adopted, the report on the national health information infrastructure. Our goal as a work group is to continue to monitor the implementation of those recommendations, and to see to what extent do we need to go further and continue to push for the concepts that were developed by this very important report.
This represents the first hearing that we have had since the report has been issued, to begin to address those issues. We have a number of panels today.
I would like to start out with some of the ground rules. We are going out live over the Internet. I actually talked to at least one person who listened in, and actually got good reception to a number of our committee meetings, so there are people out there listening.
We are going to start off by going around and doing introductions. We will start off with the committee first, and staff. As we are going around to the committee members, I'd like to ask them to identify if they have any conflicts with the subject matter of the committee. As the work group chair, I do not.
So why don't we start off with Marjorie?
DR. GREENBERG: I'm Marjorie Greenberg from the National Center for Health Statistics, Centers for Disease Control and Prevention, and Executive Secretary to the committee.
DR. SHORTLIFFE: I'm Ted Shortliffe from the Department of Medical Informatics at Columbia University College of Physicians and Surgeons in New York. Member of the committee.
DR. ZUBELDIA: Kepa Zubeldia with Claredi Corporation and member of the committee. I am also chair of the Association for Electronic Health Care Transactions and a member of X-12 and other committees.
MR. BLAIR: Jeff Blair with the Medical Records Institute, member of the committee, member of NC-HISP, HIMSIS and HL-7.
MS. WILLIAMSON: Michelle Williamson, National Center for Health Statistics, CDC and staff to the committee.
DR. LUMPKIN: Great. Why don't we go around this way, and then we'll get the first panel introduced and we'll get the audience to introduce themselves.
DR. DEERING: Mary Jo Deering, HHS Office of Public Health and Science and lead staff to the national health information infrastructure work group of the committee.
DR. COHN: Good morning, John. I am Simon Cohn. I am a practicing physician and the National Director for Health Information Policy for Kaiser Permanente, and a member of the committee. I am also a member of the CPT Editorial Panel, the National Uniform Claims Committee, and like Jeff, NCHISB. I don't think there are any issues related to any of those today.
DR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention, staff to the work group.
DR. ORTIZ: Eduardo Ortiz, from the Agency for Health Care Research and Quality, also a practicing physician in the VA medical system and also staff to the work group.
DR. FITZMAURICE: Michael Fitzmaurice, Agency for Health Care Research and Quality, liaison to the National Committee, staff to the Subcommittee on Standards and Security, also member of the ANSE Health Informatics Standards Board.
DR. LUMPKIN: Why don't we go to the audience, and then we will come back to the first panel, and we'll use that to kick off.
DR. MILLENSON: Michael Millenson. I am a senior advisor to the information technologies for better health program of the Markel Foundation.
DR. RICHARDS: Meg Richards. I am Deputy Director of the Office of Epidemiology at the Illinois Department of Public Health. I work with John. I am a member of the second panel.
DR. ETTINGER: Stan Ettinger, AHRQ and also staff to the work group on quality.
DR. OVERHAGE: Marc Overhage, Regenstrief Institute in Indiana University, and I am part of the second panel.
DR. JACKSON: Debbie Jackson, National Center for Health Statistics, CDC, committee staff.
DR. JONES: Catherine Jones, NCHS and staff to the Executive Committee.
MS. KANAAN: Susan Kanaan, writer for the committee.
DR. NATH: Ron Nath. I am a consultant at Apelon, and I am on one of the afternoon panels.
DR. ADLER: I'm Jackie Adler and I'm staff with the committee.
DR. EYTAN: Ted Eytan, Medical Informatic Division, Group Health Cooperative of Puget Sound.
DR. LUMPKIN: Thank you. Why don't we have the first panel, if you would introduce yourselves, and then we will kick off the first discussion on registries.
MR. LAMOUREUX: Good morning. My name is John Lamoureux and I am with the Baltimore City Health Department.
MR. WILLIAMS: I am Warren Williams. I'm from CDC.
DR. GORDON: Larry Gordon, California Cancer Registry. I am also a software vendor, C-Net Solutions, member of HL-7.
DR. LUMPKIN: Great. John?
MR. LAMOUREUX: Good morning, everybody. On behalf of the Baltimore City Health Department, I would like to -- I am honored to be able to present to you this morning some testimony on immunization registries, how registries collect data, how they exchange information.
I would like to just present a quick outline on how this talk is going to go. First of all, to talk about vaccination coverage, how immuunization as an information tool can hehlp sustain high national vaccination coverage, to talk briefly about the experiences of Baltimore City, and then move on to what is the immunization registry status in the country, and then to talk about six challenges that prevent full implementation of immunization registries.
I apologize for the brevity of my comments. Most of the detail is in the written testimony in front of you.
The CDC NIP on an semi-annual basis measures national immunization coverage rate among children. The last study released shows that among two-year-olds nationwide, there is a 78 percent coverage status. Vaccinations are a proven public health tool that reduces disease, reduces health care costs.
There are a number of threats to maintaining a high level of national vaccination coverage. Seventy-eight percent is good; CDC would like it higher, 90 percent plus. The threats include things like the mobility of today's society, the fact that people move from residence to residence. That changes their health care provider. Health insurance status drops in, drops out. As far as immunizations are concerned, parents think their children are up to date. More to the point, they think their doctors are keeping their kids up to date for shots. Parents think their patients are up to date for shots. When we actually go in and look at vaccination history, they are not up to date. There is a perception of over-immunization.
Vaccination schedules are complicated, they change. There is no real way of tracking those changes or from a public health point of view making sure that the private health community is informed about the changes, and so forth.
Immunization registries are one tool that can potentially sustain and increase today's high immunization coverage rates. Among other things, immunization registries -- well, let me back up a second.
What is a registry? In simple terms, it is a computerized tracking system. It collects information on a jurisdiction for children, in our case, who they are, where they live, where do they go to for their medical care, and what is their shot history.
Also, along with comprehensively collecting information, registries securely -- and I want to underline the word securely -- disclose the information on the children the registries collect. It sounds simple enough, collect data, re-disclose data. It is not that simple.
The other thing that registries do contain pretty much across the board is a decision support module that given the child's shot history that is on record, and given current recommendations published by ACIP, AAP, AAFP, two questions. Number one, is the child up to date for their shots and number two, when is their next dose due?
Registries also include a supporting infrastructure. I didn't want to just make it electronic, because in Baltimore it is a lot of paper. It is paper, it is faxes, it is telephone. It is not the Internet, it is not distributed networking, it is not the high tech, it is paper. So again, in our mind that is part of the communications infrastructure.
Registries can potentially offer benefits to parents, the community and the public health and private health care delivery system, including consolidating multiple vaccination records into a single record. For Baltimore, the second point of providing an electronic copy of the child's record when the record gets lost or destroyed. That is our main benefit that we provide to the community.
We can assist with automated reminder recall notices. Your veterinarian will remind you when your dog's next distemper shot is due, your hairstylist will remind you of when your next hair appointment is due, but will your pediatrician send you a card about when your child's next shots are due? I can only speak for Baltimore, but it doesn't happen. There is just no reminder recall in Baltimore, anyway.
Registries can help automate that process. The interesting marketing point of view is that a lot of our solo practices don't have the time, staff, money, other resources to support a reminder recall system. That is a service that we in the public health department can offer to the private sector.
Registries also can from a public health point of view identify neighborhoods, populations that are at high risk for delayed immunizations. We can also profile and monitor the practice of individual health care providers; do they follow the current ACSP recommendations, do they give the correct formulation of a vaccination appropriately and so forth.
Really quickly, about Baltimore's immunization registry program. It goes by the acronym of BIRP. Ask your doctor to BIRP your baby for good health.
We started the program in February of '95. We are authorized to operate under city ordinance and state law. Sources of funding has been mixed over the years. Initially we were funded through the Robert Wood Johnson and Annie E. Casey Foundations. We are now using monies from Title 5 of CNY program funds.
From '95 until about the summer of '98, pediatric participation, i.e., their reporting to the registry system, was voluntary. We thought, we will let the community leaders give this a shot. Word of mouth has spread, it is a good deal, and everybody will sign up on board.
Well, it didn't happen. About one in five, 18 percent, at the start of the summer of '98 were actually reporting. We then decided to in the summer of '98 launch a marketing campaign, and through that marketing campaign we were able to grow and sustain a health care provider reporting rate of about 85 percent.
As far as what we did in our marketing campaign, I would like to put that off for the challenges that face immunization registries as a whole.
This one graphic here does show the fact that we do track our providers, who is reporting on time and who is not. In Baltimore we have about 90 clinic sites; we track by individual clinic site, not by physician. The red dollar signs are those who are 60 days past due. We do have a tracking system that includes 30-day, 60-day past-due reminder cards, letter from the health commissioner, a letter from the city solicitor taking them to civil court, that type of process.
What do we collect our data from? Shot records and again, it is not just the shot records. It is the name of the child, home address of the child, child's medical care provider.
The lower part of this slide shows the BIRP system. Feeding into BIRP are the health care providers themselves. Electronic reporting and paper logs and reports. We also collect information from health department-run WIC clinics, from the city's daycare centers, Head Start programs. We also collected a little bit of information from the Maryland Department of Social Services families in progress program. A big bulk of the records come from the city's public schools.
Let me stop and backtrack a bit. The immuunization registry in Baltimore focuses on children under six years of age. We concentrated on that population because they were the most vulnerable for delayed immunizations. You all probably know that if you are enrolled in school either private or public, you must present proof that you are up to date for shots before you are allowed to enroll in school. Likewise for licensed daycare centers.
So the kids who are five to 18, we figure that for the most part they are pretty much up to date. Again, it is the pre-K kids that were the focus of our efforts.
In the planning stages, we do work under the supervision of the Maryland State Health Department, DHMH. They today are in the planning and development stages of creating their new registry. Once they come online with their registry, we will be able to tap into other data sources, mostly electronic, from the managed care organizations, billing clearinghouses and potentially from neighboring states.
The bulk of the reports come into the BIRP system through paper forms and logs. Four of the five clinics who report give it to us on paper. The 20 percent who give it to us electronically from collection from billing systems, from their in-house QA systems and in one case, from an electronic patient records system. There are only 20 percent of the total clinics, but it amounts to 42 percent of the total reporting given to us. That is the count based on number of children and number of immuunization doses.
In Baltimore, while the electronic reporting is a small number, you can see that they tend to be the higher volume health delivery systems.
There are a number of areas in which the immunization registry in Baltimore needs improvement. Again, I would like to direct your attention to more detail in the testimony. Number one, we have got to improve the quality of our data. There are a lot of holes. There are some duplicate records.
We are now in the process of designing and deploying an upgrade to our software. We want to make it Internet accessible, and we also want to put it on an Oracle platform, grow the scale and scope of BIRP reporting. There are a couple of issues. As far as scope goes, right now it is just immunization registry. Our health commissioner has dictated that it must also include results from blood lead testing. In Baltimore City, every child is required by city law to have the blood lead test at age one and again at age two. Those results must go into the immunization registry as well.
Our pediatricians have asked us to include electronic newborn discharge summaries. They have asked us to include dates of PPD-tuberculosis testing. Likewise, there is talk about including our division of maternal-child health outreach activities and outcomes.
So as time goes on, the scope of our immunization registry is growing. As far as the scale of reporting, I already alluded to the fact that we want to begin to include adolescents and adults as well.
One of the big holes in our system is the dropping of the linkage that we had with the Maryland Department of Vital Records for their electronic transmission of both birth and child death certificates. We used to have it, we don't have it anymore, we want to get it back.
From a national perspective, one of the Healthy People 2010 goals is to enroll at least 95 percent of the nation's under-six-year-olds into a fully functional immunization registry. CDC reports that as of December 31, 2001, about two-thirds of the states self reported operating an immunization registry. They can potentially capture about 50 percent of that under-six-year-old cohort.
The interesting thing is that states and local jurisdictions have developed disparate systems. The development of system has not occurred on a uniform basis. All of our registry programs have done it as funds permit and so forth.
The deployment of one single national immunization registry is not feasible at this time. It is not technical, it is political, and it is also financial. The best that we can hope for in the next five to ten years is to quilt together individual state registries into a regional registry, and allow sharing between different states.
This is a map of the state immunization registry status. It is self reported, and it is as of December 2001.
There are a number of challenges that face individual registry programs as far as fully implementing their programs and as far as sharing information or exchanging information across jurisdictional lines.
Number one, the big challenge for all of us is to recruit and retain health care providers, make sure that they are not only reporting to the registry, but also getting something back from the registry. It is not a one-way street, this is not a dictate from the government to the private providers, or it shouldn't be a dictate.
Number two, to insure functional standards are uniform across the platforms. Number three is integration. Integration means pulling together other public and private public health databases such as the blood lead testing, newborn discharge summaries, cross-jurisdictional connectivity, allowing one registry to talk to another registry program.
Just as a background, we talk to Washington, D.C.'s registry, we pick up the phone and call them. Philadelphia talks to us and gets a record; they call up and phone us. I know that there are HL-7 standards, possibly X-12 standards being developed, but for us, a low volume player, pick up the phone or fax us a request, we will get it from there.
Issues of privacy, confidentiality, and security and lastly, to insure a steady stream of funding. Let me start off by talking about health care provider participation. It is the underlying factor. It is critical to insure immunization registry activities. No providers, no registry.
In Baltimore, we developed a marketing plan, and here are just a few of the relevant stances that we took, actions that we took. Number one, we had to define who our target was going to be. Was it going to be the individual doctor versus the clinical practice versus the managed care organization and billing houses? Who were we going to require reporting from?
Lists of health care providers. We are not comprehensive. We had to go back to the Yellow Pages and find our doctors' list from that. No, the Maryland Board of Licensure for physicians didn't have a list. No, the Vaccines for Children program didn't have a list. So back to the Yellow Pages for everybody.
One of the major points was that we developed marketing materials and we distributed those materials to both health care providers as well as parents, get the word out on the street.
The next point, when we marketed the system in Baltimore, we did not want to have a single system that was mandated for all health care providers to follow. Again, we wanted to do two things. We wanted to minimize provider burden and we wanted to return value to the providers in exchange for reporting to the registry.
So in essence, we said however you want to report to us, go ahead and do so, whether it be by a xerox copy of the vaccine administration sheet, whether it be via a spiral notebook, you tell us, we'll take it.
Likewise, wraparound support services were offered. Those included, let's start you out. Let's send a team over to your practice and we'll go ahead and capture the vaccine histories for the under three-year-olds in your practice. Or let us come out and run a reminder recall system for you to try to capture kids, or let us make the telephone calls to insure that a VFC vaccine can be supplied to your practice if you have got problems with that. So again, support services.
One of the big issues, you make promises as a public health program, you have got to deliver on those promises. Health care providers in the private sector are unforgiving, at least in Baltimore. You get one strike, you get one mess-up, but after that, they are just going to shake their heads and say, once again, public health, incompetent, don't know what they are doing. You have got to get it right if not the first time, you have got to get it right the second time. Again, deliver on promises.
Talk to the providers. One of the key ingredients is a person to person followup. We modeled it after the pharmaceutical companies. We don't offer free lunches, but we offer things like pens, lanyards, sticky notes, that type of thing, and we offer somebody to complain to, or somebody who will listen to the doctor's complaints about the registry system.
Lastly, as I mentioned before, our city ordinance allows us to take punitive measures against providers who fail to report in a timely manner.
Functional standards, just a quick definition. Common core data elements and common functionalities, in order to facilitate information exchange between registry platforms. The National Vaccine Advisory Committee or NVAC has already defined these standards. Likewise, the CDC national immunization program is now working with AIRA, the American Immunization Registry Association, who is a peer committee of registry programs throughout the country.
Anyway, CDC and AIRA are developing a registry certification that will allow self testing of registry platforms to make sure they are in line with CDC guidelines.
Integration between registries and other public health systems. We have talked about this before. The fact is that in Baltimore's care, registries are growing in scope. They are collecting information from other public health databases. Our hope is to also capture more information from private databases, building clearinghouses. Those practices are instituting electronic patient medical records.
Let me just cite two organizations that have been in the forefront. Number one, CIRSET is now working toward HL-7 standards. They pretty much have a first draft of those standards out, they are working on a second. Let me just say that CIRSET in partnership with CDC has also created an HL-7 parser, a black box that attaches onto registry platforms to enable automatic translation into HL-7.
Likewise, another organization, the All Kids Count centers for innovation in health information systems is now working towards connecting different public health systems.
Let me also take a moment to say that there are opportunities for growth in the future. I have cited two here. Integration with disease surveillance systems such as CDC NEDS, and also the emerging software that will respond to emergency disasters in bioterrorism. From a funding point of view, this emergency and disaster response software, it is extra dollars. I hate to be so vulgar, but we will chase the dollars. That is where the money is right now.
Cross-jurisdictional connectivity. Again, it is what it sounds like. It allows Baltimore City to talk to the state of Maryland. It lets Maryland talk to the District of Columbia or to Pennsylvania.
Talking about the HL-7 standards developed by CIRSET in partnership with CDC, privacy, confidentiality, security, must haves in any operating registry program.
I am going to skip over this part. Let me just say that the registries must be in compliance, but not only federal legislation such as HIPAA, but also state and local registration. My understanding from CDC's interpretation of HIPAA, it does allow some exemptions for immunization registries, as registries are lawfully authorized public health surveillance instruments.
Insure funding. Number one is, programs have to measure how much it costs to run their system, develop their system and to run it on a day by day basis. That measurement should include cost-benefit analysis. Okay, so it costs us one dollar to key in a child's shot record, and it costs us 25 cents, but how much time does it save the doctor's office. Their clerk has to take 15 minutes to retrieve the chart, copy the chart into a state form that will allow the child to be enrolled in school. How much does that cost? Anyway, cost-benefit analysis.
The second point is that surveys suggest that registries capture information from multiple sources, both private and public. One of the new interesting ideas out is that the All Kids Count program has suggested creating a pool of shareware. Shareware in this case is publicly funded immunization registry software.
In our case, I know that we are spending a good chunk of change to develop our new registry platform. It is so much nicer just to log into a site and download the source code for nothing.
Conclusions and recommendations, if I may just quickly. Number one, registries are a vital component of any public health information infrastructure. Number two, I do come from a bias. I am a city public health department employee, and I do believe the locals know best. We know our docs, we know our people, we are best situated to address local needs. We are asking the state of Maryland to allow us to operate within their guidelines, but to do so in a semi-autonomous basis.
I just wanted to make the point that one size does not fit all. We in Baltimore are not advocating a single registry standard for the country. However, we do recognize the fact that standards will be built and will be implemented in order to realize economies of scale and cost savings.
I mentioned six challenges real quickly. Our recommendation to this committee is to go ahead and work toward encouraging CDC to work with local registry programs to solve these six challenges.
Lastly, I don't mean to be vulgar, but if you all could advocate on behalf of additional federal funding for registry programs, that would be most kind of you.
Thank you.
DR. LUMPKIN: I just want to make one comment before the next speaker. Since we are going over the Internet, if you could pull that microphone all the way up, very close to you, so that we could get a good signal.
Warren?
DR. WILLIAMS: Good morning, Chairman Lumpkin and distinguished members of the National Committee on Vital and Health Statistics. My name is Warren Williams. I am a health scientist in the Division of Cancer Prevention and Control at the CDC. Thank you for this opportunity to talk about population-based cancer registries, their role in collecting data, and the standards that pertain to these data collection and reporting efforts.
Data standards, collection, reporting procedures and using data are fundamental to those organizations whose mission it is to reduce the burden of cancer in our nation. These organizations include the CDC's national program of cancer registries, the surveillance, epidemiology and end results program of the National Cancer Institute, the North American Association of Central Cancer Registries, the American College of Surgeons, and others.
For those organizations involved in cancer reporting, high quality, complete and timely data form the backbone of population-based statistics used for informed decision making. These groups all contribute a significant amount of time and effort to provide timely information about cancer occurrences and outcomes.
This information is used for implementing cancer prevention and control programs for identifying when and where to enhance cancer screening efforts for reducing the impact of disease, for improving patient outcome and quality of life, and for developing effective research.
Population-based cancer registries exist in every state in the United States, the District of Columbia and free territories. The surveillance, epidemiology and end results program of the National Cancer Institute and the national program of cancer registries work together to support these efforts. These cancer registries serve extremely important roles in collecting data, performing quality control evaluations and using data from clinical facilities.
Typically, cancer registry data are collected from various aspects of the medical record, including reports from pathology laboratories, admissions and discharge, surgery and radiology into a hospital registry. Data are then reported to a central or regional registry and finally, as reported, to previously mentioned national sources. Depending on reporting laws and operational issues, some direct reporting occurs from reference laboratories, physician offices and nursing homes. Uniform data reporting standards exist for the cancer registry profession. Most of the organizations involved in the registration and counting of cancer cases collaborate under the auspices of NAACCR. This umbrella organization works with cancer registries, government agencies, professional associations and private groups interested in the quality and use of cancer registry data.
Within NAACCR, various committees debate, refine and publish data standards and procedures used to report cancer into population-based repositories. These standards are reported electronically for reporting and analysis in an ASCII flat file format. This format changes on a yearly basis and is reflected in updates published in revised versions of the NAACCR record layout. The reason for these changes are based on organizational requirements for new data, clarification of existing refined data or changes due to procedural clarifications. Typically, these data standards are not specifically constructed to work within a messaging style environment.
CDC has recognized the need to enhance data collection practices so the cancer data can be reported efficiently in a constantly evolving electronic environment. This environment continually changes as technology advances, electronic medical records mature, and demands for more, faster and higher quality data are placed on the cancer registry community.
In October of 1998, professionals interested in the application of industry standards to improve the reporting of cancer data convened to examine the issues. The industry standards group examined at this meeting included the ANSE accredited organizations, Health Level 7 and coding schemes such as LOINC and SNOMED. Through support from CDC, a work group was formed to explore the development of an alternate reporting protocol to the NAACCR flat file format. This proposed alternative reporting method would apply to the Health Level 7 messaging approach, LOINC identifier codes, standard demographics and local value responses.
The group drafted an written document to serve as an implementation guide for the use of the HL-7 reporting approach. This implementation guide is intended to be a springboard for further development. The guide is designed to promote implementation and pilot efforts and to port registry data into a message-based environment. This guide should serve as a starting point for involving the registry community in the use of a structured reporting approach for gathering data with an industry developed reporting protocol.
Additionally, work is focused on the practical development and use of a comprehensive medical record vocabulary for as much as 30 years. The SNOMED vocabulary has had an association with the reportable codes used in cancer registration. By agreement, the report of morphologies in ICD-O and SNOMED are consistent between the coding schemes. Codes for topography or site of cancer are more detailed in SNOMED. Mapping tables are used to relate them to the appropriate ICD-O codes.
These maps and the use of SNOMED vocabulary promote a more detailed report of the site of cancer, yet maintain the classification schemes used for years in cancer registration. It is important that appropriate levels of quality and accuracy are applied to the assignment of the SNOMED coding.
Continuing to address the educational, practical and technical concerns of implementing such a vocabulary is still needed. The development and use of messaging approaches and clinical code sets such as LOINC and SNOMED codes require a transitional approach to data gathering which the division of cancer prevention and control has supported.
Over the past four years, DCPC has formalized new partnerships through cooperative agreement mechanisms for certain key industry standards groups to help promote the development and use of these key industry data standards. The division has cooperative agreements with the College of American Pathologists, SNOMED Division to promote general education activities on SNOMED and encoding of clinical cancer protocols. Additionally, a recent cooperative agreement has been established with the Regenstrief Institute to help promote and to re-mine the LOINC code set, promote education and develop tools for mapping and management of LOINC codes.
While it is important for the cancer registry community to promoting using industry coding schemes and reporting structures. It is equally important for these industry groups to appreciate and work with the practical reporting needs of cancer registries. These cooperative agreements exist to encourage all parties to work together to address and support their individual and collective data and secondly, assist in supporting these organizations' capacity to meet specific surveillance needs.
Achieving the NHII vision requires synergy and interplay among these and other organizations. Active coordination efforts are needed to strengthen the reporting of clinical data into cancer registries and build upon various components of the NHII.
For example, the College of American Pathologists has developed and published standardized reporting protocols. These are designed to help surgical pathologists achieve completeness and accuracy and uniformity in collecting and reporting pathology related tumor data.
In 2001, the CDC cancer division funded two state registries to work in conjunction with two pathology labs to evaluate the use of code sets, structure data entry for pathology reports that are submitted to cancer registries. The funding partners will be investigating the use of new electronic technique along the HL-7 paradigm and the reporting of a checklist style report.
Several specific objectives of this project are to encourage standardization of the content and electronic reporting for pathology data for colon rectal cancers to cancer registries and secondly, to provide feedback to CAP's cancer committee and other groups regarding improvements to and implementation of the protocols and three, evaluate the strength and limitations of implementing SNOMED encoded CAP protocols for colon rectal cancers for both clinical and cancer surveillance purposes.
As a collaborative effort in public health practice, this three-year project is expected to result in improvements to the completeness, timeliness and quality of cancer data from pathology labs.
The registry community and industry standards groups need to be broadly educated about the use and benefits of controlled vocabulary, as well as coding schemes for specific program needs. In addition, further evaluation and educational efforts are needed to demonstrate the practical benefits of standards supporting the NHII.
However, several projects such as those referenced on this slide emphasize the transitional approach to accomplish programmatic needs within the components of the NHII. These projects are some of the beginning steps that enhance, contribute to and support NHII initiatives.
A number of engineering related principles and practices are also needed to support the NHII. These include one, the use of engineering methodologies for analyzing requirements and designing solutions, two, engineering tools and three, application of engineering standards such as notations and processes.
Modeling the business, i.e., surveillance process and practices as well as specific activities, protocols and data structures is important to describe cancer surveillance in unambiguous terms. We need to transition and improve the capacity of registries to learn and apply new technologies and approaches for cancer registration. Modern engineering practices including analysis and design, business modeling and the unified modeling language should be explored in order to better describe the practices in cancer surveillance, information technology systems and cancer data. In fact, concurrent with this testimony is a best practices workshop in which modeling techniques are being partially applied to describe the process of data clearance.
In conclusion, the metamorphosis of a large-scale population-based surveillance effort such as cancer registration to enable real-time electronic reporting and take advantage of developing technologies and standards will not occur overnight. We hope that these initial efforts to promote better engineering, education and the use of standardized reporting structures and controlled vocabularies and code sets will position the registry professional, the systems and the data we collect to better serve the needs of cancer prevention and control. It is important that the education and exploration on the need and use of key industry standards and engineering principles be continued and prioritized at all organizational levels to improve completeness, timeliness and quality of surveillance data.
I hope this background on cancer registration standardization efforts and new initiatives sponsored by CDC's Division of Cancer Prevention and Control has been useful. Thanks again for the opportunity to testify before you today, and I'll be happy to answer questions. Or are we doing that later?
DR. LUMPKIN: We'll take questions as a panel, thank you. Barry?
DR. GORDON: Thank you. I was trying to remember the last time I actually presented from text. I think it was probably in a community chorus, where I was singing a German requiem. There will be no singing today, but I think I may be preaching to the choir.
DR. LUMPKIN: But will you be noteworthy?
DR. GORDON: I have been concerned with standards issues throughout most of my 35 years' work with cancer registries. I'd like to start by describing some of our standards work, give a kind of status report, and provide some examples of what we are learning from the current projects. I will end with some ideas on how to foster the extension of structured standards both within cancer registries and between them and other key players. Warren has provided a nice overview of cancer standards; I'll give some specifics.
Several of us joined the standards venture fairly early, when the possibility of electronic reporting first become recognized. When PC's became available widely, physicians were starting to invent their own coding software for home-brew registry systems, so we decided in California to produce freely available PC software as a pre-emptive act to encourage the use of newly forged standards agreed on by NCI and the American College of Surgeons.
Then when we were proposing the cancer regulations, the California regulations to mandate electronic reporting as part of our new state registry system, we had even more reason to hammer out common standards and formats. I believe the speed with which we implemented statewide reporting and data collection was at least in part due to our ability to provide clear electronic standards and the software that carried them out.
The fledgling NAACCR when it was being formed to support state registries in that, I helped found a standards committee
to find the national exchange standards for reporting. The easy part was to include the simple inclusive structure; the hard part was getting SEER and the College to agree on how treatment and staging should be coded.
There is the inevitable conflict between the desire for a consistent coding system over time, for those who study trends like epidemiologists, and the clinical view exemplified by the College. Clinicians need to keep up with how changing clinical knowledge and practices affect the staging of cancers in terms of predicted outcomes.
The standards work was helped by the recognition the clear gains in efficiency the agreement would bring, along with plenty of motivation from vendors and states having to interface with boundaries.
I believe this cancer registry standards effort has been a success so far. First, let's look at California. We now have all 450 hospitals using standard electronic case reporting to our eight regional registries and central registry, using a common set of required edits and online coding manuals. Specifically, an ASCII layout, a national agreed on code set, online coding manuals and common edit set.
The second standard efforts being undertaken in California involve standards for reporting potential cases by pathology labs. We are devoting a lot of attention to this. The sheer volume suggests we need to go electronic in this.
I can summarize briefly -- this is looking at, for each of our cancer cases in 1999, what we believe was a source of the case finding, that the case was actually discovered. You will see that the most common sources are various departments within a hospital, especially in medical records and path reports. I will be discussing these sources in relations to structured messaging in a moment.
Turning to national standards with cancer surveillance, I believe we have another success story. As Warren has already mentioned, we have a neutral organization to host the standards, that is NAACCR. The geographic scope is the entire U.S. and Canada. Key players are all participating. We have achieved some data harmonization between partners, although this is a continuing effort.
We have common tools, including distributable dictionaries, code sets, electronic coding manuals and standard edits. And most importantly, states get measured on their ability to meet data standards and quality, both by the CDC and NAACCR. Each year for example, NAACCR awards, gold and silver awards, go to states meeting their standards, and they include them in the combined data publication.
What did it take to get this level of harmonization released? First, the recognition that hospitals were reporting the same cases to agencies with conflicting standards, lots of duplication of effort. Secondly, commitment by a national organization to achieving common definitions and third, federal funding of state registries, which was contingent on their using common standards.
Another way to put it is, ingredients to success were first, a commitment to standards, secondly, the tools to encourage them and thirdly, the courage to measure and report compliance.
I am particularly proud of our distributable edits technology as a tool that strongly encourages standards. Using a common workbench and cross-organizational metafile of standard edits that are cullable from any Windows application, supports each national organization in maintaining edits for their part of the common data set, and supports easy distribution of the edits nationally. Portable edit software was developed by CDC in consultation with several vendors, including us, and are used by the College, SEER and NAACCR to maintain edits. In California, these edits are built into our C-Net's front-end software and our statewide software.
Not everything has been a success. As soon as we look for connectivity between cancer registries and other agencies, we see harmonization problems, lack of well-structured reporting. This is the highest concern in relation to our meeting HL-7 standards. Although much work is done, we find few implementations.
In the past three years, there have been two project areas that Warren mentioned. How much of these mappings to HL-7 been used? Not very much, and I'll discuss why.
Four projects I want to mention that we have been working on in terms of HL-7 are these. First I want to talk about the project to create HL-7 based cancer case report messages. Warren discussed this already.
In California we tested this HL-7 message structure by developing software that creates and sends and receives these messages as defined by the implementation guide. This project was successful at least technically. However, there is no clear business case motivating organizations to use this format for cancer reporting. Also, I am not aware of anyone else who has done even a pilot implementation of it.
The biggest impediment is the state standard's lack of economic or regulatory motivation to switch to HL-7 for cancer reporting. No national funders are requiring the switch, and the harmonization work to better align NAACCR with HL-7 is not seen as worth the effort for this particular effort. There are other, more positive motivations.
A second project I want to mention is integrating in-hospital messaging into cancer reporting. Most cancers are diagnosed in hospitals. Yet, cancer registries are still cut off from most of the interesting HL-7 traffic that passes routinely between departments.
In this project, we are implementing software to capture discharge messages, select those coded with cancer codes and bring them into our C-Net registry software for evaluation and pre-population of electronic reports. We are also studying how best to merge pathology messages with discharge messages to further expedite cancer data collection.
A case finding can involve a great many different hospital systems. In one analysis at UCSF, 21 different departments or systems had reports that could identify cancer cases. We are finding that the majority of discharge systems already use standard HL-7 messages, however there is less penetration for pathology systems right now.
The third pilot project I want to talk about is the electronic pathology reporting. Warren has mentioned this also. In California we are working hard to set up electronic reporting between path labs and the state registry. This is particularly important for stand-alone labs, but any regional or state registry that needs rapid case finding for special studies needs to have high speed access to large hospital path labs.
Nationally and locally there have been some successes. The standard lab electronic message agreed on by NAACCR with leadership from CDC, as a compromise with existing methods, both a column de-limited and HL-7 version are available.
There is also a nationally maintained list of key search phrases for recognizing potential cancers by scanning report text. There are some issues. Even though -- this work is being used in several states, including California, but there are some issues. It takes a long time to get lab buy-in to this electronic reporting.
Secondly, there is confusion over HIPAA issues that makes some labs and facilities nervous about electronic transfer, even though their current methods like postal delivery of diskettes are far from secure.
Third, there is no agreement in the registry or vendor community as to which secure transfer protocols and authentication schemes to use to carry out these communications. So cross-system interchange is not facilitated. There are a number of efforts, including CDC's NEDS model and some BDB solutions, but I don't see any consensus. Without this, it is hard to build clinical public health connectivity.
Last, message schemes that depend on the latest HL-7 formats, version three, where are you, don't work when facilities are out of date, that use out of date software systems, is mostly what they are doing.
The fourth project I want to mention is the reporting pathology protocols project. It builds on recent excellent work by the College of American Pathologists. They created standard synoptic checklists for cancer cases which hopefully can replace the largely idiosyncratic text-based reports currently used.
We are implementing data capture and HL-7 messaging of the colorectal synoptic report, then putting it through a live test to see what kinds of efficiencies it might produce. In California we are working with the UC-Irvine Cancer Center. If this approach works, among other benefits it will lead to a more rapid and consistent identification of potential cancers for cancer registries and less manual coding.
As we proceed with this work, we are discovering again the substantial effort needed to convert something that looks read good on paper to algorithms that unambiguously capture standard data from the form.
I believe this project has the ingredients for success, because of the participation by some national standard setters, CAP and CDC, standards agencies like SNOMED, LOINC and HL-7, state registries, in this case California and Ohio, software developers like C-Net, Rocky Mountain and COPATH, and practitioners, in this case pathologists. And it helps that all these efforts are focused on not only implementing, but evaluating the new standards and techniques.
Now, beyond the four projects I have just mentioned, there are many other systems that registries could benefit from interfacing. I will just list them here. Clinical lab electronic reports are important to tap into. Other aspects of the hospital information system that are not being tapped. Radiation treatment center systems, state vital status records, clinical trials systems. It is really a shame that we are not hooked in well to ongoing studies, and rapid case findings systems for interview studies.
So to summarize, I believe the following steps will help us all make progress toward more consistent and widespread structured standards and reporting.
First, public health and clinical groups need to value connectivity with others, and include it in their high-level agendas. They also need to encourage to measure compliance.
Secondly, more glue projects are needed to create structured standard interfaces and prove their worth. These pilot projects need to be funded well enough to include representatives from standards organizations and all the key players in the interface, along with software developers.
New proposed coding and message structures, no matter how well designed, must be implemented in real messages and environments before their design is complete, and standards work best when accompanied by portable edits and other tools to implement them.
So the goal here is better interconnection. This goal has a certain inevitability, a slow inevitability, but I am glad to be working with so many talented people to help move it along.
Thank you.
DR. LUMPKIN: Thank you. I think we all have a lot of questions to ask. I will try to keep us on schedule. We are scheduled to break at 10:30 so we can ask questions until then.
Ted, I know you had a number of questions, so if you want to kick it off.
DR. SHORTLIFFE: Some of the questions were clarifications, which probably aren't crucial now. They were questions that occurred to me especially during Mr. Monroe's presentation on the Baltimore situation.
Let me take a step back, having heard all three, and ask a question. There is a fascinating contrast between the immunization situation that we heard about and the cancer registry situation, both of which are presumably of high interest to CDC, of course.
Mr. Lamoureux, you pointed out the need for increased funding. Many of the points you made, it seemed to me, and I would like your reaction to this observation, reflected the realities of scant resources and decisions that you had to make for local optimization, given the fact that you couldn't really do what you wanted to do, given the resources that were available to you in Baltimore.
So for example, the one size does not fit all philosophy, about the need to merge so many different approaches. One observation on that is that the reason that you can't is because you don't really have the resources to try to make sure that an infrastructure exists that would allow you to have something much more consistent across all the practice settings in the pediatric environments and clinics in Baltimore.
The consistent view of this over time is, you want to make sure that you are sensitive to differences in practices, practice styles, practice automation, et cetera, but you would really over time like to have one size that did fit all underneath, that allowed the full integration to occur and get rid of some of the faxing and some of the manual processes that you are wrestling with now, and that are creating some potential for tremendous administrative inefficiencies that you have to deal with because you have such a manual process.
We hear there is something much more automated going on with the cancer program in California, although you still have lots of challenges with standardization.
So I am trying to understand first, is my read correct on this from your perception? Second, what is it that has happened in terms of national programs embracing the importance of these two areas of public health, cancer registries and immunization, and how can the one learn from the other or perhaps even be merged from a perspective perspective? It seems to me that many of the issues are remarkably similar, and yet the state of development of the two, at least from your description, is quite different.
I may be misreading this in terms of what some other states have been doing in the areas of immunization registry. I think what you have described however is very similar to what we experienced in New York City, where we are struggling with a wide variety of ways of submitting, and some experiments with online submission and efforts to try to engage the clinicians.
So a final clarification, because I could go on. You led us to believe that this was initially voluntary, but you got up to an 85 or 90 percent effort after monitoring. Then you started talking about requirements for lead testing submission and punitive measures without telling us what they were that ultimately occurred. So have you transitioned into a less voluntary, less optional set of rules? Because that would seem to be implied by some of what you said, if people can actually be punished for not complying now.
So a lot of questions buried in that little spiel.
MR. LAMOUREUX: I hope I can fudge on at least half of them. When we established the BIRP system, we didn't know what we were doing, and neither did other registry programs. Baltimore was among the forefront of registry development, again funded by the Robert Wood Johnson Foundation back in '96, '98, somewhere along there. We had no recipe for establishing a registry.
Let me go back. When we looked at the 18, 20 percent of voluntary participation, that wasn't good enough. We wanted to market the system so that providers -- we couldn't go to health care providers and say, this is nothing, you won't even know it is there.
It requires effort on the behalf of health care providers. They do have to expend additional costs in their practice to make this registry happen. We on the other hand said, we can't eliminate costs, but we can minimize costs. That was the basis -- one of the two bases for our decision to let providers establish their own way of reporting.
The second thing is, we did take a look at some of the electronic systems in Maryland. Again, I can't talk about the rest of the country, but we looked at the databases compiled by managed care organizations in two parts -- one, their QA checks and number two, their billing data. We found both to be extremely lacking. We made the decision that in order to build a registry that had credibility to it, we had to throw out the electronic databases that had already been established by managed care.
Do I wish we could have standardized? Gee, I don't know. We are doing all right. Let me just say this, though. We have been in discussion with the state of Maryland health department, and they have emphatically said there is no way that they can do it for a statewide registry. In Maryland's case, they must establish reporting standards and --
DR. SHORTLIFFE: Because it is resource constrained?
MR. LAMOUREUX: Yes, exactly.
DR. SHORTLIFFE: That is the reason, let's be honest about it, because you could do it.
MR. LAMOUREUX: That is the reason. We could do it.
DR. SHORTLIFFE: It is not like there is a fundamental barrier out of that money.
MR. LAMOUREUX: We could do that. As far as punitive measures, we have threatened and we have never -- part of the process in the last scheme is to take it to civil court. We have never done that.
DR. SHORTLIFFE: Do you now require participation? Is that the implication?
MR. LAMOUREUX: We required participation back in '95.
DR. SHORTLIFFE: Okay, that wasn't clear.
DR. GORDON: If I can comment, the cancer field has helped, because several national organizations are funding, rather than one. The College of Surgeons has its interests, and NCI has its interests; that helps.
But I think if you set an electronic standard and write it into the state code, then vendors are free to do any solutions they want to, people are free to go anywhere. Then you just rigorously test and approve them. So it is a shared cost. It is not all the state has to pay here. And we charge $35 a case if somebody is not submitting a cancer case electronically. That hurts them. So we have regulations, and CDC has helped foster every state, getting some kind of regulation in place. I think that is a model that should be used in other diseases as well.
DR. LUMPKIN: I should just kick in on behalf of CDC. They have been heavily funding immunization registries, state level immunization registries, for a good bit of time. I think that what we are seeing is some of the complexities, not just also totally the issue of funding.
Obviously, there can be more money in the system, but I think we do have to recognize the funding that does exist.
DR. SHORTLIFFE: It does occur to me that a key difference that we are seeing here is that you are dealing with every practitioner who practices pediatrics, and gives shots in the greater Baltimore area. Whereas, the cancer registry as you pointed out is dealing primarily with hospital path labs and private path labs, and not individual practitioners, every primary care physician who has a patient who happens to present with a new tumor. That does make a big difference in the nature of the complications associated with trying to do this kind of registry.
DR. LUMPKIN: Kepa?
DR. WILLIAMS: Just one other point that also helps with the cancer registry world. There is an existing network of cancer registries in the hospitals that have been around for years. That was in place before some of the national momentum got moving, and that helped give a good baseline for capturing all these cases from the other individual facilities.
DR. SHORTLIFFE: Because the college required them.
DR. WILLIAMS: Yes.
DR. LUMPKIN: Kepa?
DR. ZUBELDIA: In moving towards a national information infrastructure, I also share your vision that a solution that fits all may not be feasible as far as implementation, unless you want to develop shareware and distribute it, and then everybody agrees to use the same shareware because it is so wonderful.
But we are going to have to live with multiple different solutions. The question is -- and I would like to get feedback from all three of you -- is it feasible to have a data interchange solution that would let people do their own implementations, and that will be completely agnostic as far as implementation, but will allow to exchange the same core data elements, where everybody can share from the same data transfers, and still maintaining their own infrastructure?
Then, what sort of communication standards would you need to establish that? Would it have to be the Internet? Would it have to not be the Internet for privacy reasons? What do you see in that area?
DR. GORDON: Well, your question answers itself fairly. I agree that that is exactly what is missing. The glue that is missing there is -- and it has got to be Internet based, and the contents standards are being dealt with fairly well, but the wrapper standards and how you hook up and how you authenticate, and those standards, there are four or five or ten different efforts here. I think we need some leadership to move on that particular issue, and then everybody can be players to use a neutral exchange medium.
MR. BLAIR: So the four or five wrapper standards, which are the four or five wrapper standards?
DR. GORDON: I wish you hadn't asked that question. Every HL-7 meeting I go to, I hear a new one. But NEDS is an example of a CDC-based private wrapper that could be promulgated. I think there are several XML solutions that are proposed for the next level up that you are more familiar with, I know, than I am.
So what I am saying is, as we try to design a network in California, I don't see one place to go for this. It is hard for me to make the technical decision without trying to read where everybody else is going, so we can have a joint venture.
So it may be my lack of knowledge, but I don't see the single way to go.
DR. ZUBELDIA: How about immunization? Do you see the same situation with immunization?
MR. LAMOUREUX: I am of a mixed mind. Again, I am just going to cite my bias toward city-based immunization registries.
The inevitable is that for the development of information exchange, you are number one going to have to base it on a statewide level. Number two, CDC in partnership with peer organizations have already developed standards, data elements, functionality, for information exchange.
In addition, CDC has developed the HL parser. All the pieces are there. It is just a matter of the states supporting it together to form their own registry, as well as to begin to exchange with neighboring states.
From a local level -- and maybe this is to continue Dr. Shortliffe's answer -- we would gladly surrender a lot of this customization if we felt that there was something valid and robust to replace it, bowing to the inevitable issue of standards on the Maryland level.
DR. WILLIAMS: I do think it is important to focus on the interface component of these systems in order to be able to bridge the connectivity between the organizations. I think it is probably not a one solution fits all, but a good interface component that can handle a lot of different ways of electronically interfacing is a key component to handle an HL-7 flat file feed, an X-12 feed, whatever the stream can deal with, and have that ability isolated from other components of your system so that you can then put that in and run your business rules or your edits or your validations or other quality control checks that are there. That is a key component to be able to focus on the interface capacity, to get this information in and out of these systems.
DR. ZUBELDIA: Why is this not happening? CDC has an HL-7 implementation guide for immunization registries. You showed us the implementation guide for cancer registries. Why is it not happening?
DR. WILLIAMS: I think it is happening to some extent in pilot efforts in various places, and Barry mentioned a couple. It takes awhile to do all of this, and there is a lot of competing priorities out there for what to focus on and so on.
The one way of interfacing with flat files has been around for awhile, and it just takes a slow transition to be able to move to a more structured way of capturing this information. It takes resources, knowledgeable people, commitments, everything.
DR. GORDON: There is some confusion with levels. HL-7 is really at the application level, and that is working pretty well. We are talking about other levels of communication, where you recognize your trading partners and can identify them, and you make those connections.
DR. LUMPKIN: I actually have two questions, and it ties in relationship to -- actually I have a ton of other questions, but let me try to focus in on two issues. It has to do with the interrelationship and the conceptual models that we try to pull together with NHII.
The first is a thought on the immunization registry. It is, have you considered having parents give you access to these reports? There is some discussion about the physician, but what if I want to know if my child needs a shot?
MR. LAMOUREUX: Electronic access, not at this time. If you as a parent want a copy of not only your child's vaccination history, but also of any other data that is captured on your child, including home address, your name as the parent, et cetera, it is just a matter of picking up the phone and calling our office or going into one of our clinics and making that formal request.
DR. LUMPKIN: And for physicians, can they access the reports for their practice?
MR. LAMOUREUX: Yes.
DR. LUMPKIN: That can be done online?
MR. LAMOUREUX: Online, no, not at this time. It is over the phone. We are developing a new system hopefully by the end of this calendar year; they will be able to access it over the Internet.
DR. LUMPKIN: Then the next question related to that, looking at how we interface, I was struck by the presentation on the discussion of many of the initiatives related to the cancer registries that there are two parties that seem to be not involved in these discussions.
The first party appears to be practicing clinicians. There seems to be a lot of discussions with practicing pathologists, but a good bit of the information that is involved in cancer registries has to do with what is the treatment and what are the outcomes, and to what extent have those clinicians been involved in the standards development process.
The second are vendors of clinical information
systems. So if you want to generate an HL-7 message as a byproduct of clinical care, obviously if those vendors aren't at the table, you are still going to have a system that requires double data entry, additional steps to be done by clinicians and pathologists in order to do reporting.
So to what extent have you explored or involved the ability to move forward into the creation of a cancer registry report automatically by a clinical information system?
DR. GORDON: To your first question, physicians have been involved mostly through the American College of Surgeons and their allied organizations. A lot of their standards development comes out of physician committees, basically.
This has not always been a good thing. Every cancer society has its own committee and its own ideas, so things were very fragmented until they decided to try to take a unified approach. So a lot of work has gone on there.
But there are not that many practicing physicians on a number of these standards committees, and a lot of these things are getting passed up. AJCC of course is physician driven.
DR. LUMPKIN: And medical oncologists aren't involved?
DR. GORDON: I don't see them that involved. It is a whole different area. I think there is a lack of clinical system vendors at the table at the moment.
DR. WILLIAMS: I agree, there are not a lot of clinical system vendors at the table. Barry and I mentioned about the pathology checklist. We are engaged with some pathology information system vendors on the conference calls and all that kind of good stuff that you do on a project, but they have been there, actively engaged in what we are trying to do and so forth so these clinical lab systems can interface with hospital registry systems and so forth.
DR. LUMPKIN: Michael?
DR. FITZMAURICE: Some quick questions, because all the really good questions have been asked by the group and answered by the expert panel.
I am impressed with your knowledge that not only standards exist, but that you want to use them. But you know what works in getting the job done where you are. I wanted to ask John, you mentioned 42 percent of your data are reported electronically to Baltimore. Is it useful to follow up with what John said; you have to do double data entry. You have to print it out and enter it again.
MR. LAMOUREUX: Yes, it is very much usable. However, we always take a look at the data and run so QA checks on the data before it actually enters our registry.
Is the data complete? No, it is not. There are a couple of glitches in some of the reporting systems from our local health care systems. CPT codes that don't point to a specific shot, but point to, shots were given, or other QA issues. So the short answer is, yes, it is usable.
DR. FITZMAURICE: The next question is for Warren Williams. I was going to ask, are you working with messaging with HL-7, with developing the codes and the standards, but it is clear that you have been for a long time doing that.
Do you support meetings of standard developers? Do you bring the vendors in to talk with the standard developers and the users of the standards for the registries, so that everybody knows what is going on?
Secondly, can you give us a copy of legible slides for the future? Third, what are ICD-0 codes?
DR. WILLIAMS: ICD-0 codes are the international classification diseases for oncology. It is a whole coding scheme.
DR. FITZMAURICE: Is that part of ICD-10?
DR. WILLIAMS: No, it is separate from that. It is specific to just the oncology domain.
Another question was, are we sponsoring any meetings and so forth.
DR. FITZMAURICE: -- vendors and standards developers and the users, to bring them all together.
DR. WILLIAMS: That happens a lot through the NAACCR organization, where vendors of cancer registry systems collaborate with cancer registry directors, state based organizations and so forth like that. They come together and do things. The meeting report that I mentioned on the slide was where we brought in some specific HL-7 expertise and various people from the cancer registry domain to investigate the use of those types of approaches for reporting data. That was one of the first times that that had happened.
DR. FITZMAURICE: Great. Last question. This is for Barry Gordon. I am getting the message that content is king, that message structures may change over time, but really it is the content. The national data dictionary is useful, and I hope CDC is putting one out. XML is coming, and who knows what is going to be after XML.
But for a national health information infrastructure, we need people to use these standards. Where pathology labs are so slow to use HL-7 messages, where laboratories are so slow to use LOINC codes, eventually they will have to speak to physicians' offices. Physicians will be querying for that information for their patients. What can speed it up? Why are they so slow, and what can speed it up?
DR. GORDON: Well, I ask myself that question quite often, and I'm not the right person to answer it, I think. Why aren't they? It appears that it is cost centered, that they don't want to put money into, they have got a system from five years ago that is tuned for their particular hospital environment, and there is no business reason yet to move on. We want to give them some more business reasons to move on.
Of course, the more we have regulatory standards for the kind of messages they have to supply, that will move them along. There are some things that could significantly do that, but until they hit that bump, they are not moving. It could be that some HIPAA stuff is going to move them along, but I don't think so.
So we are caught. I don't have a solution.
DR. LUMPKIN: Can I just ask a followup to that question? To what extent are you working with the infectious disease entities that are looking at electronic laboratory reporting? So that, by creating one system, it reduces -- because there are some different leverage points for infectious disease reporting, have you looked at leveraging on their aim to have electronic reporting?
DR. GORDON: In California we are trying. It is not easy. It has got two big groups trying to get together, and it is amazing what happens when you -- how long that takes to do. So when we are doing system design, we have people from STD groups involvement when we are sharing co-technology ideas. But that is different than sharing systems, and I am not sure what it takes to do that.
Even within the cancer realm, there are boundaries that haven't been crossed that need to be crossed. So all these boundary problems are kind of frustrating.
DR. COHN: John, I think my question is a follow-on on yours. As I am listening to this -- I chair the subcommittee for standards and security for the NCVHS. I think we are all aware of how far standards get you and don't get you. Standards are great things, but we know that there is a fair amount of optionality in many of the clinical HL-7 standards that permit real interoperability at this point.
So I am listening to all of your standards discussions, and I am going, gee, that may be part of the solution, but I am struggling, if that gets you where you really want to go.
I guess having been involved with the immunization tracking activities sponsored by the CDC and the standards around that, and many of the other standards activities, I am wondering if maybe the solution here is beyond standards, but CDC or somebody else developing turnkey solutions or some consortium of states that become the standard that we insure are interoperable.
I know this conversation has been brought up before, I'm sure, but it just sounds like we are late in the game to be continuing to talk about pilots, aren't we?
DR. LUMPKIN: I think, Simon, if I could respond to the question that you pose, I think we have to define what it is that we are trying to standardize. That is part of the problem. There is one effort to standardize so that -- not to take issue, but one size fits all, that Illinois and Wisconsin and Indiana aren't all using different systems with different modes of looking at the data in our cancer registry.
Then there is the issue of standardizing the -- morphing the clinical data into the registry data, how does that get transmitted. I think that those two different things have been efforts that have mostly focused at the standardization. That is what NAACCR is taking a strong lead on. But in trying to standardize the clinical systems that then feed the data into these registries, that I think is where a lot of work needs to be done.
DR. COHN: If I can comment, once again from the other side of things, of course part of the issue is that everybody has slightly different standards. There is a fair amount of optionality, so the developers of systems on the clinical side don't have a standard interface to send things to. So if you are a large IT vendor, yes, you do it one way for Wisconsin, another way for Illinois, a slightly different way for California because of state legislation.
I reflect on this only because I deal with a large health maintenance organization, Kaiser Permanente, that is involved in a number of states, so we have to send things to immunization registries from state to state. There are certainly significant standards, but there is also significant amount of variation from place to place.
DR. GORDON: In the cancer area, the state to state stuff is like one percent, so we have hammered it down pretty nicely. It used to be really bad. As a vendor, I can tell you, it was bad.
But the turnkey solution is a solution with walls. That is the problem with that. If you want inter-connectivity, you can't just deliver a box that only works one way to other peoples' similar or exactly the same boxes. You need to hook into systems that do all kinds of things. So it is much better to enforce a standard, provide a box that does it, but then say, you can connect to this box if you use these other things, too, so connect your system to our box.
DR. LUMPKIN: If I can suggest, we need to bring back or have some specific questions, because the issue is, to what extent will NEDS or does NEDS answer these issues of inter-connectivity between these various registries, and is there a need for further development, as we have already suggested.
Mary Jo has a question that is a take-home assignment, so it doesn't require an answer now.
DR. DEERING: I'm not handing out blue books, however. Yes, this is a request, and it picks up on a question that, John, you used to ask in our regional hearings almost a couple of years ago now. One of your closing questions to everybody has to do with the role of the federal government.
I guess what I would ask is, -- let me start out by reminding us all that in the NHII report, the concept is not only improving data flow around a particular content area or issue area, but maximizing the linkages among related content areas, and also expanding what is the concept of who uses that data, picking up on John's question of, can parents access this data, for example.
So given from where you stand and given that vision of integrating more data content and making it useful to more users, what priority role would you see for the federal government in moving us toward that goal?
DR. LUMPKIN: And Warren, you don't have to answer that.
DR. DEERING: I was going to say, more money to CDC is clearly not the answer.
DR. LUMPKIN: If you could just e-mail that to myself or to Mary Jo, and we will share that with all of the committee.
At this time, we have a break.
DR. ZUBELDIA: I would just like to make an observation. It seems that I heard something critical, that the one percent difference from state to state may not be avoidable. Maybe we need to look at standards not being 100 percent solution, but being a 99 percent solution.
DR. LUMPKIN: Good point. We will take a brief break. We are scheduled to get back at 10:45. I will just point out that our delay in getting back will take time away from our ability to discuss the next panel, or from lunch, depending on how we want to do that.
I would like to thank the panel. Obviously this was a very thought-provoking discussion. Thank you.
(Brief recess.)
DR. LUMPKIN: We are going to get started with the second panel on population health in the NHII interface. I'll ask this panel to introduce themselves, starting off with Dr. Richards.
DR. RICHARDS: Just introductions first?
DR. LUMPKIN: Yes. We'll do the introduction of all the panelists, and then you'll go into your presentation.
DR. RICHARDS: Okay. Meg Richards. I am the Deputy Director of the Office of Epidemiology and Health Systems Development at the Illinois Department of Public Health.
DR. OVERHAGE: I'm Dr. Marc Overhage. I am a practicing internist on the faculty at the Indiana University School of Medicine, as well as an investigator at the Regenstrief Institute for Health Care.
DR. MORALES: I'm Oscar Morales. I am the Division Director in the Office of Environmental Information at the Environmental Protection Agency.
DR. LUMPKIN: Meg?
DR. RICHARDS: Thank you. I have both slides and a very elegant testimony, which I don't have in front of me, so I'll do what John Lamoureux did this morning and supply that later, and hopefully quickly speak to what is on our slides.
I just want to say from the outset that the overview I am going to present represents the work of many people in many programs at IDPH. I am just the humble presenter.
First, the context. It has been said a number of times this morning that we are preaching to the choir. I am certain that I am in this, but it was helpful for me to put this presentation in the appropriate context. I read your very elegant November 15, 2001 report on the national health information infrastructure. I found this description of the population health dimension, that it will include statutorily authorized data in public health systems, enable officials to track health threats, assess population health programs and services, and include core data elements such as infant mortality, immunization levels, registries, et cetera.
In ten minutes today, I am just going to go over a couple of things. I would like to talk to you about things that we are doing in Illinois that speak to the NHII population health dimension interface.
First I want to tell you a little bit about our technical infrastructure in Illinois, who is included in our system of connectivity, however they are connected. Three examples of systems that exemplify the population health dimension are our birth related data project, tracking our toddlers' shots, which is our immunization registry, and the Illinois version of NEDS, what we call INEDS. Then I am going to spend a few minutes talking about some areas of concern that we have that I know you all share.
In our state as with the rest of the nation, putting together the jigsaw puzzle pieces of this enormous information infrastructure has been a task. Just to give you some idea of where we are at with that, only one of the three systems that I am going to briefly take you through is fully operational, that is, TOTS. The other two, the birth related data project and INEDS, are still in development or in various stages of development.
This is just a pictorial display of our current technical infrastructure. We have over 220 hospitals in the state of Illinois. We have 94 local health jurisdictions. That is a combination of county and municipal health jurisdictions. Then of course, we are the center of that governmental public health universe.
As with a number of other states, we have a health alert network that we use to communicate with the local health departments. Right now, that connection is primarily a 56K modem and dedicated PC connection, but with the bioterrorism monies from CDC, we are working to identify those local health departments that don't have a broadband high speed Internet connection, and help them get there.
With hospitals, we have a number of scholarship programs and initiatives that are going to enable us to set up a hospital health alert network. That is what is referenced down in the corner of this slide, the scholarship program as well.
We have a critical access hospital telehealth and telemedicine program that provides data services, imaging video, video conferencing capabilities to a number of hospitals around the state. I think we have 20 online at this point. I will show you a map of where those hospitals are located later on.
Providers at large and clinics are not yet connected, but what we are moving towards is broad access of all of our public health partners eventually through an Internet web portal.
Just a minute about the birth related data project, which is actually in the RFP stage. We had some seven different programs at the Illinois Department of Public Health that utilize some form of birth related data. I deliberately made this slide to suggest that if you look at those seven forms that represent the seven programs up at the top of this slide, you can see that they are similar.
There is quite a bit of duplication of data elements, mother's name, gestational age, date of birth of the baby, et cetera, et cetera. We recognize that one wonderful partner directed effort in terms of web-based data collection and consolidation would be this birth related data project.
As I said, it is in the RFP stage right now, but we are wanting to develop one master electronic record that can be filled out at the hospitals. That is the summation sign that you see right there, that can be passed to us electronically. Then the information is fanned out again at the other end to the programs that are interested in that data.
Let me just tell you what the acronyms are below. VLBW is very low birth weight, newborn metabolic and genetic screening, newborn hearing system and the adverse pregnancy outcomes reporting system. Those are what the acronym stands for.
The programs have the ability to only see the data in which they are interested when they go to view this data online. I think this is at least in theory a very elegant and very simple effort to try to put together a population database system.
Our version of -- and I was very interested listening to John Lamoureux this morning -- TOTS stands for Tracking Our Toddlers' Shots. This is our immunization registry, which I believe is just over two years old.
There are three ways that immunization data can be entered into our statewide registry. One is a voice response system using a Touchtone telephone. That is interactive. You can enter data that way, you can also request immunization records or history forms, school physical forms.
There is an electronic data interchange that involves whatever the local practitioner's electronic system is. They can ship the data to us that way, or there is a TOTS computer program that has been developed, that exists on CD-ROM, and it has been sent out to our various partners around this state.
The goal is 90 percent coverage. I think John might have mentioned that this morning. Currently, nationally we think that 78 percent of zero to two-year-olds have appropriate immunization level coverage. I'm not sure in terms of state participation; I think we might be at about 58 percent participation in the registry at this point.
Finally, I just want to talk a little bit about NEDS. One way in which we initiate communicable disease reporting in Illinois is through the use of what we affectionately call the morb card, the morbidity card.
As with so many other states, this system for us is still largely paper based. This is just one way that we potentially open up a case for investigation. Part of our INEDS development efforts involve making an electronic version of this, and having virtually a web-based e-morb card that will exist. That is part of some of the second phase development efforts with INEDS.
Now, let me just tell you a little bit about INEDS. We looked at the CDC base NEDS system, and opted to develop our own version, primarily because of issues of timing and adaptability. We have made a strong commitment to make sure that the systems will be interoperable, and that we are absolutely following all of the standards that CDC currently has in place for their NEDS.
This system will mirror the paper system that we now have in place. It will be patient-centric, that is, these records will be historical records that will be event driven. But all of the patients will exist in a central repository, and before you can even enter a new case, you will first have to search and see whether that case already exists in the system.
The whole purpose of INEDS is to allow providers and laboratories to report cases or to open cases for investigation simultaneously with the local health department and with the state health department. Thus, this triangle representation.
Right now, we are on track to pilot a Salmonella module in October of this year. We are going to start out piloting it with ten local health departments, and then hopefully take it statewide by the first of next year.
This is just a glimpse at the architecture of INEDS. It is actually three-tiered. Ultimately we want to be able to do all of this through our web portal into INEDS. I have HAN listed there with a red line through it. That is because HAN as we now know it with the dedicated lines and the dedicated PCs is going to go away or is being slowly phased out. As I mentioned earlier, we are providing direct grants to all local health departments to have high speed broadband connections.
As with so many other NEDS developers around the nation and with CDC, there will be quite a bit of applications security and systems security around this, business rules for access and authorization, et cetera.
Some of the features of INEDS. I already mentioned probably the most important one, which is this historical approach and the central repository feature, the fact that you can't open a new case until you first searched on patient's name, date of diagnosis and the actual disease of interest, the disease event. Before you can open a brand new file, there is going to be a huge effort to avoid duplication of cases in this.
There is also -- and I think this is something pretty terrific -- we are going to have my-case folders that will show up as an icon on your desktop application when you go into INEDS. That is where new cases will be visible to you, as well as cases that are pending further investigation. You can update cases through your my-case folder, and then once a case is closed and it is shipped off to this central repository in the locked area and then shipped off to CDC, it is done. But if a jurisdiction changes, or if there is some recognition that a case that might have opened in one county in fact belongs to another county, it can actually migrate to the my-case folder of the appropriate county when that recognition is made. I am going to talk a little bit more about that in just a second.
A word about interoperability. This is the map that I said a moment ago that I would show you, that shows you where our telehealth critical access hospitals are located around the state. Those are the counties that are colored in aqua.
We do have some concerns -- and I know George Benjamin has mentioned this with one of the inhalational anthrax cases on the East Coast this fall, that worked in Maryland, lived in Virginia and was seen in D.C. or something like that. We have some of the same issues in Illinois. It is very possible that a patient could for example live in Lake County, work in DuPage County but be treated in Chicago for a disease event. At the same time, if it is a bioterrorism agent, or even if not, it is possible that the reference lab is located out of state, and of course we have to report those cases to CDC.
The ability to pass messages back and forth between jurisdictions, the ability to exchange information with the reference lab that is processing specimens, and then to send this information on to CDC is obviously very critical to us.
Assuming that all of the local health jurisdictions participate in INEDS, interoperability won't be an issue. But if any of them were to choose to develop or maintain their own system, then we would need to know that they were building a system that was interoperable and met the same standards that we are trying to meet as we build INEDS.
Finally, just a word about the paper chase. I believe right now there are five separate communicable disease systems in Illinois that all will potentially feed into INEDS, the holy grail of INEDS, as we call it. Some of those systems from the reporting perspective are DOS based. They are no longer supported either at CDC, or we have trouble sometimes finding people in the state health department who know how to operate those systems.
We are hoping obviously that when INEDS comes together, we will have partner buy-in. If their participation in the development is any indication, we think that is the case. The reason I put this picture of the field of dreams in Dyersville, Iowa on the right-hand side is that we often say, if we build it, will they come. Hopefully the answer is, yes, they will come.
Finally, I just like this cartoon. I recognize that the NCVHS committee on NHII has really blazed a trail in terms of interoperability and issues around building a national health information infrastructure. I hope you are not all exhausted from that effort.
Thank you.
DR. LUMPKIN: Thank you. Oscar?
DR. MORALES: Good morning. My name is Oscar Morales, as I said. I am a director in the Office of Environmental Information at EPA.
As I was listening to the earlier presentations, I was wondering what the hell am I doing here. As with Dr. Richards, I want to say that some of the stuff I am going to present today is the work of lots of folks at EPA, and I am simply the messenger at the moment. The projects I am going to talk about are rather large for us anyway, and I am just one of many folks there.
Also, I want to say that they asked us to come down, because of an interest in some of the data standards and standard repositories and registries that we have at the agency. But I am actually here to -- and I am here to share some of that information, but I am also here to express the agency's willingness to participate in some of this work, as I will talk about in a minute.
I do want to say that it is interesting that even though it is a different environment that I am going to be talking about, and our stakeholders are primarily states and not smaller entities or hospitals or doctors, some of the issues are exactly the same, and some of the words and the problems and hopefully the solutions.
On behalf of the agency, I want to thank you for giving us the opportunity to provide comments on the direction that we are taking with regard to partnering with others and to develop environmental information networks and to develop data standards, and we use grants to construct these networks as well as ongoing activities related to all of these.
The purpose here of my comments are to provide the work group hopefully with an introduction to our EPA exchange network and efforts that are being facilitated by our standards program, and open web-based repositories and registries.
As many of you may or may not know, the mission of the agency is to protect human health and to safeguard the natural environment, air, water, land upon which life depends. For 30 years, EPA has been working for a cleaner, healthier environment for the American people. Our information technology mission is to provide the information that decision makers need to protect human health and the environment.
Our primary information exchange, and something I will spend a lot of time with today, partners are the states and tribes. We will move on to citizens and to organizations and to other groups, but at this point in time, we will only be dealing with the states and the tribes.
With our partners, the agency has been developing a network and hopefully this experience will be carried on to other environmental health tracking systems.
As you all probably know, CDC and ATSDR received money from the Congress in the '02 budget to build an environmental health tracking network. In August of this year, the two organizations developed a proposed plan to develop and implement an integrated tracking system.
The purpose of this system was to strengthen the nation's environmental health defense system to prevent diseases by identifying and controlling environmental precursors of chronic diseases, and to establish public health readiness. The lead agencies are CDC and the Agency for Toxic Substances and Disease Registry. But there are other participants, and hopefully the EPA will be one of those participants, federal, state and nonprofit entities that are involved in various aspects of environmental and health data, and we are interested in developing a foundation of a partnership to develop with the EHTM.
What are we now doing to support this new network, or considering doing to support this new network? HHS working through CDC and ATSDR and EPA are formalizing a partnership with an MOU that emphasizes better exchanges of environmental health information, and we will be working over the next few months to develop a plan to facilitate these information exchanges. I would like to say it was signed, but it hasn't been signed yet.
EPA does have regulatory and some ambient environmental information that we think can inform the network, and we are working with CDC to determine the best ways to share this information. We are hosting a series of meetings with our research and development and program offices, the air office and our water office, to discuss the environmental health issues and the information sources that may be useful for the tracking network in the possible next steps.
But I think the biggest things that we can offer to the network is sharing the experience that we have had in developing the -- in partnering the state environmental agencies to build a national network, which we are calling the national environmental exchange network. We would be more than willing to share with CDC some of the technical and management lessons that we have learned in sharing and working with the states on this effort, some of which I will go into today.
Our national environmental exchange network -- and this is just one of a thousand different schemas that I could show you -- is an innovative approach for the exchange of environmental data among EPA, states and other parties with whom the agency and the states exchange information.
The vision is to exchange access on environmental data, reducing reporting burden and improving the quality of the available environmental data, and increasing the efficiency of the data exchanged between network partners, the parties that officially participate in the network.
The network will gradually replace the traditional approach to information exchange that require the states to feed data directly into multiple EPA national systems. We have probably at the agency 220 major national systems and about 200 to 300 minor systems.
The network will gradually replace this traditional approach, and will facilitate the transparent and secure data exchange that supports specific analysis, such as the use of indicators if we are measuring environmental results. While the network participation is voluntary, EPA and the states expect participation in the network to become the preferred method for routine intergovernmental transfers of environmental data.
States and EPA's headquarters and regional offices have interacted extensively over the past three years to build a foundation for the network. The next two slides will show you the framework and the technical components.
The network is only two years old. It was built on a collaborative effort between EPA and one of the several state organizations. The primary group is the state information management work group, the IMWG, which oversees the work of the action teams, the Network Steering Board. It is followed by numerous action teams, we call them, and these are partnerships with EPA, states and tribes, partnering to develop -- for example the Environmental Data Standards Council is a partnership that agrees on data standards for environmental information collection and exchange, and it seeks to promote the efficient sharing of environmental information among all the partners, providing data standards as a basic element for a new data exchange and data integration activities.
The network board provides guidance on the technical specification. Key to the exchange are trading partner agreements. These are agreed-upon data quality standards, exchange formats, frequency of exchange and other specifications.
Some of the framework technical components are listed on here, network security, pretty much the same stuff in any -- used in any exchange of data. But the two that I am going to focus on today are the data standards and data exchange templates. The data standards as defined by the Environmental Data Standards Council are documented agreements on formats, and definitions of common data. They are established to bring consistency and quality of the information that organizations maintain and exchange. The benefits of the data standards are even greater for the network partners because they reduce the ambiguity of the information contained in the templates at the most rigorous level.
Key to the exchange of data are the data exchange templates, which describe the format and the specific restrictions where applicable of the data exchange across the network. They are documented in the process as XML document type definitions, DTDs, or XML schemas. EPA is meeting at the end of July with CDC to discuss the exchange of some information on the network.
Data standards. The way that we have developed standards before the network existed is pretty much as I have stated, as we have got on this one slide. Data standards are documented agreements on the representation of the formats and the definitions of common data. We feel that standards identify the data of common interest, they establish definitions of acceptable values, and they provide a standardized set of information about the data.
They don't tell folks how to define their data. They don't tell folks what data they are supposed to collect, and they don't establish the reporting requirements.
Under the auspices of the Environmental Data Standards Council, these are a list of the standards that we have promulgated to date; biological taxonomy, chem ID, date facility, all the way down to enforcement and compliance. The standards under development include water quality monitoring, and we are under consideration for a laboratory standard.
The reason we focused on these is because these were the ones that we felt were common to the agency. They were core to the business of the agency, and not one program owned the data standards. They were not necessarily low-hanging fruit, although that was initially our interest. The date standard on there for example is a very easy one to pass. We have two databases within the agency, the managers of which will go to their grave before they change the data in their databases, because they are doing it their way, by cracky, and nobody can force them to do it.
The standard process that we currently have is initiated by the Data Standards Council. We have a proposal by either the state or tribe or EPA on a data standard, and once it is approved by the Council, they establish an action team that is made up of members of states, EPA and the tribes. The states are environmental departments, and they are usually departments that have some sort of interest in the standard that is being passed. The members of EPA are senior officials from programs that exchange information. If we can get the tribes to participate in any way, shape or form, they participate as well.
The team develops a standard containing a core set of elements with the broadest applicability, and hopefully the standards are closely linked to other data standards. As we developed the standards, we also developed XML tags, and that is the exchange route that we use in our network.
The process takes about six months. It used to take about a year and a half. It is very slow and time consuming, primarily because -- not because of the communication, but more in terms of the agreement that we have to have amongst ourselves. Sometimes the internal agreement is as bad as the external agreement.
Formal process. Externally, once the standards are approved by the council, they are voluntary standards, internally the EPA that mandated it, meaning the owners of our databases, must implement the standard within a certain time specified. The voluntary nature of the external sometimes works and sometimes doesn't work. Some of our standards are implemented faster with the states than they are with our own agency systems.
I was asked to talk about barriers. Our barriers are probably no different than some of the barriers that I have heard. That is to say, our internal legacy data tend to be the place where most of our problems occur. Traditionally, there have been many barriers to the implementation of data standards. Internally, the legacy data has included vast amounts of widely divergent and sometimes overlapping data.
The systems that have used the data have been complex and fragmented, and that compounds matters. The collection and the documentation practices have not been consistent. With a great deal of data coming from external sources, there has been a lack of standards and implementation among the exchange partners. What we have done is implement a vigorous implementation program internally to try to convince, cajole and/or mandate system owners' program, senior officials to implement the standards in some sort of agreed time schedule.
The environmental data registry. To facilitate the use and the implementation of the agreed-upon data standards, the agency developed an environmental data registry. It is a database
on the web containing the content of the standards and the implementation of the system. The registry is in place to keep facts about the characteristics that are necessary to clearly describe inventory, analyze and classify data.
It is the agency's comprehensive and authoritative source of reference information about environmental information. It provides information on the definition, the origin, the source and the location of environmental data. It is a set of related web-based tools that provide information on the meta data, the data standards, on chemical and biological organisms and terminology. It is a series of one database repository and four or five smaller registries.
The EDR is an implementation of the ISO meta data registry standard 11179. It is the same standard, I might add, that the U.S. health information knowledge base or meta data registry operated by the ANSE health care informatics standards board uses, and was designed as a result of efforts by Commander Robert Mays and the NCVHS, and the design of this drew upon our EDR, or so my folks tell me.
With the documented data elements from the EDR, users may then desire to progress into locating the details of the many uses of data elements. I thought I would throw this in here, because it is probably a good place to start if you are looking for environmental information. It is run by our R&D office. It is an environmental information management system. It provides a repository for scientific documentation that can be easily accessed with a standard web browser to place a virtual library and desktop. It is one of the integrating activities of the information management within our R&D, and provides descriptive information of databases, data sets, documents, projects, scientific studies, spatial information. The user community includes environmental scientists, resource managers and other stakeholders, both within and outside the agency. In it we are storing our latest GIS watershed data and our public and internal partners may submit directories, entries to be considered for inclusion within the database.
Finally, we use grants in order to get people to play with us, so to speak. We have a number of grant programs to foster improvements in the information and exchange integration. A funding of the network grants is being provided to states, D.C., trust territories, tribes for capacity building, for network participation.
One of the grant programs engages the nation's scientists and engineers in targeted research. That complements EPA's own outstanding intramural research program, and those of our partners in other federal agencies. Also, EPA is one of the ten agencies that participates in the SBIR program, the Small Business Innovation and Development Act, with the purpose of strengthening the role of small businesses in federally funded R&D projects.
The star program focuses on health effects of particulate matter, drinking water, water quality, global change, ecosystem management and restoration, endocrine disrupting chemicals, pollution prevention, new technologies, children's health and socioeconomic research.
Our own network has three kinds of grants available to states, one-stop grants to get folks to begin to participate in the network, readiness grants to build capacity, and challenge grants that encourage states to work with each other and territories and come up with joint projects.
In coming up with some sort of summary statement as to lessons learned or what it is that we can share with people or other organizations trying to develop any kind of networks, we currently are doing this with the states. We are going to be opening it up to other entities at some point.
But among the lessons that I think we could generalize is commonly shared data need to be properly defined, stored and hopefully mandated, include partners in all steps, especially pre-planning, assume internal resistance to change, standardization means centralization and oversight, be open, public, go slow and finally, take time to reach agreements.
We are at the process now of negotiating trading partner agreements with states, and most of the people within the agency assume that these would be something that would take under a year to produce. To date, we have produced two, and it took about a year to do. There are many more entities to be considered.
I hope that we can collaborate on this effort as well as many others.
Thank you.
DR. LUMPKIN: Thank you very much. Marc?
DR. OVERHAGE: How much time would you like me to take, since we are running a bit behind?
DR. LUMPKIN: Take your full time.
DR. OVERHAGE: So my usual two to one compression. Great. First of all, I apologize for not having handouts in front of you. I despite my assistant's best efforts left them on my desk when I left yesterday. However, they have been sent by special courier. During the break I checked; the courier was at the airport, and Dr. McDonald will be here shortly.
I am going to spend the time that I have with you this morning describing a microcosm of the NHII that we are trying to create in Indianapolis, Indiana that we call the Indiana Network for Patient Care, which is an operational electronic medical record, and speaks specifically to the implications for population health.
I don't mean to skip through your wonderful diagram so quickly, but only that we are going to focus on the population health dimension this morning and not talk much about the clinical care, health care provider dimension.
I did want to emphasize a couple of things that occurred to me as I was reviewing the document that all of you worked so diligently to prepare. One is that population health data is just individual health data for lots of individuals. It may seem self evident, but I think a lot of times, agencies that look at population health data tend to think of their needs as being unique and different than those of health care providers, but I think the overlaps are remarkable.
Second, when we think about population health data, the document that was prepared tends to focus on public health, certainly a very important aspect of population health data, but there are many other bodies who need that level, that view of our population's health, including payors, accrediting bodies, regulatory agencies, policy makers, health services researchers and others.
The third point is that I am going to focus today a bit on what I think of as health care's last mile. In the Internet world, we think about the challenge of -- there is lots of fiber capacity out there, and if I could only get it to my house, I could actually have something faster than a 56K baud modem. It would be cheap and inexpensive.
In health care, the problem to some extent is that health care delivery systems have lots of useful interesting data locked away in their databases that we would like to get to accrediting agencies, public health and others, but there are a number of issues to overcome in terms of sharing that data.
As I said, we have been trying to do that for a number of years in Indianapolis by building this Indiana network for patient care. I am going to describe a little bit about that, and some of the challenges and issues that we have overcome, and then some of the experience that we have gained from that in terms of developing standards.
The disadvantage of transferring files to another computer; you don't get the pretty pictures.
Indianapolis is a moderate-sized city, 12th largest in the United States, home to the state's only medical school, the state department of health, and there is a major referral center for the entire state, so it is a wonderful area to do that. If you could see this picture, you would have a picture of the beltway which surrounds Indianapolis and identifies the locations of the participants in this process, which include most of the Indianapolis medical-surgical hospitals. I am glad to say that we have made tremendous progress in the last weeks with the VA medical center in terms of incorporating their data, a large managed care system, the homeless care network, the public school clinics and the county and state public health departments and their associated clinics.
Let me go on while this is restarting, and try to continue without getting you too lost. What we have done is created a secure data network which incorporates the majority of the hospitals as well as a variety of other health care providers. In addition to that, we built a database of databases. The figure that I want to show you in a moment will help depict that.
The key thing that that allows us to do is, it allows us to keep the data from each of the participants separate. It is their data; we are merely a custodian of their data, and then to develop agreements on how that data is to be used. But the advantage is that that data is formatted in a consistent format and coding systems, so that it can be leveraged in many different ways.
Let me go on while it is thinking. There is the wonderful picture that you missed; hopefully we will get it back into slide show mode in a moment.
This database of databases, one for each of the participants, as I said. In addition to that, we have data from a variety of sources being added to those databases or those repositories, not just through those institutions' databases, but for example through direct data entry.
An example of this, there is a large gunshot wound prevention activity, a registry if you will in Indianapolis. It uses the IMPC as its primary data entry point and repository. That is how the data is captured. It takes advantage of, leverages, the information that is already being captured and health care registration processes and so on, and the fact that the patient's address and their phone number and other demographic data, and leveraging that, along with some of the other clinical data about, were they discharged from the emergency room or were they admitted to the hospital and so on. That is automatically collected, if you will, as a byproduct of care.
We have leveraged that infrastructure for a large number of projects. We started with the top circle in this pyramid diagram of the medical records system which has data primarily for Wichard Health Services, the county's public hospital. We have begun to graft a lot of data into that, public health data and school clinic data.
We then expanded that to some of our other partner hospitals and called it Care Web. But it is the same database, same infrastructure, same coding scheme that includes a lot of data from more institutions. Then the IMPC, which has even more institutions, a little less data and most recently what we call SPIN, or the shared pathology information network, that we are working on with the National Cancer Institute, which incorporates even more data from a broader range of institutions, and is an example of one of the research activities or leveraging of this database that we have been doing.
The next couple of slides list the data that is shared by all of the institutions, which include the emergency department and outpatient visits, all hospital discharges including diagnoses, procedures, attending physician information that you might find on a UB-92 form, all inpatient laboratory results including newborn screening and immunizations.
As part of the SPIN project, all of the institutions have agreed to add additional data. We have this from several of them finished and we are adding it from the others, all discharge summaries and admission summaries, all operative notes, all radiology reports, pathology reports, and those will be partially structured, inpatient medications and then tumor registry data, that wonderful stuff that the people spend a lot of time distilling out of written records and codifying.
Then some of the institutions provide voluntarily additional information, ambulatory notes, vital signs, information about in-office testing of cholesterols and things of that nature, visit reasons and diagnoses from ambulatory visits, cardiac testing, including echoes, cardiac catheterizations and so on. So it has become a fairly rich data set.
We have been able to accomplish this by building on a number of data standards. We rely heavily on HL-7 and DICOMM. We do have image data from three of the institutions that are completely digital now. LOINC, which I am going to spend a little bit more time talking about for laboratory codes. ICD-9, CPT-4 codes.
We currently use NDC codes for medications, but recognize the limitations and problems of that, and look forward to adopting some of the newer coding systems that are evolving out of current efforts for medications, and likewise organisms. We are still struggling with the issue of how to code them, and we use that wonderful coding system of Freetext today for organisms.
Most of you are familiar with LOINC, which is a standards effort that developed out of a need for a universal identifier for laboratory and clinical observations in order to send in these messages. The LOINC names have the general form of a component, what is being measured, followed by the property, what are you measuring about it, timing, system, scale and optional method.
Rather than try to make or force or cajole the various participating institutions into restructuring their data or recording their data into the LOINC standard for laboratory data, we thought that we would at least try to map it. Our initial attempt at that was to have the institutions' laboratories do that mapping.
We started out working from laboratory masters from those institutions. That effort failed miserably for a number of reasons. First, it was too much time and insufficient resources in the laboratory. There had been competing priorities, and this was not necessarily something that the laboratory viewed as high value, even though the institution was very committed to performing it.
Second, there was an educational problem, a misunderstanding of LOINC at the laboratory level. Finally, the results of the mappings that were done were either too specific or not specific enough in most cases. Most clinicians are reminded of their first surgical case, where they cut all the sutures too long or too short.
Our current mapping approach has been very successful. We have centralized that a little bit, and we have done it based on building a collection of real data. In other words, just turn on the spigot of HL-7 messages and collect them for three months. We build from that a database that describes the kinds of codes that are used, how they are used, how frequently they are used, information about the results, what are the values that you see as the results, what are the exceptions that you see from those, what are the units that you see, and so on.
Based on a review of the units and the laboratory terms that are used, we feed that information into a tool called RELMA, the regulatory LOINC mapping assistant, which is an attempt to make a first pass at automatically mapping the local laboratory codes to LOINC codes, using all of that information.
That gets us typically 60 percent or 70 percent of the way there for most laboratories. Then there is an error check, iterative review process, that uses a fair amount of manual labor. This might sound a little bit daunting. Our first laboratory being a fairly large, complicated one, with over 5,000 tests, took well over a man year of effort to map of fairly sophisticated personnel. Our most recent laboratory mapping effort, a little bit smaller, about 3,000 unique tests that they do or results that they report, was done in less than one month by a brand new person, a physician, but a brand new person who didn't have a lot of experience in this. So we are confident that we can continue to improve that process.
How do we use this data? For clinical care it can be accessed in a number of ways. We push or deliver reports, we call them emergency care abstracts, to physicians in various settings, the piece of paper you see reproduced here, and then there is online web-based access.
But the thing I want to emphasize from a population health standpoint is the data we use. For clinical care, we use this data in a variety of settings. I was very gratified to be giving a presentation to some physician groups a few weeks ago, and had somebody stand up in a meeting and say, you know, that data saved by life. Talk about making your day. We are still tracking down all the details of that one.
The public health uses are obvious. We serve as a poor man's immuunization registry. We collect the data from all these places, make it widely available. We report reportable conditions electronically to the state and local health departments. We are doing some crude surveillance at this point.
But that data is also heavily used for health services research. For example, one of the emergency room physicians in the city did a study called Seven Days of Pain, where he looked at patients who came to the emergency department with complaints of pain during a one-week period, and analyzed in detail their needs, their usage patterns and so on, for clinical research, and heavily used for accreditation reports, because we do have this data across many enterprises.
Because we are running short on time, I think I am going to leave for the handout when it arrives for you to peruse some of the information about how we manage the notification and delivery of public health information. But I want to summarize a few key outcomes.
We are analyzing one quarter of data from the first quarter of 2001. We find first of all that 100 percent of all the reportable results were processed and analyzed through our system. When we use a capture-recapture method to look at reporting completeness, we find 34 percent -- and these are still somewhat preliminary data -- reporting by the health department, 32 percent by the hospital infection control departments, and we find 88 percent of them through the IMPC surveillance system. As one might expect, a little bit more timely, about eight and a half days faster than the health department, and a day and a half faster than the hospitals.
Just to give you one example of how this plays out, this is from April 14 of 2000. The Indianapolis Star, our local newspaper, reported 76 ill from an outbreak at child care sites. We had a large shigella outbreak. If you will notice the timeline here, that newspaper article is clear out here. We clearly knew well before that based on the data we were receiving. In fact, when we saw this large spike back here in January, called the health department and said, something is going on, and they were scratching their heads wondering if something was going on as well.
The other thing, the epidemiologists in the room will recognize John Snowe's work in London in determining the outbreak of cholera, tying it to the Broad Street Pump. Our corollary is, on the day we called the health department -- it is a little bit difficult to see on this small projector, but the green stars represent the cases that we knew about that day, and the yellow dots represent the child care centers that were eventually implicated. The interesting thing I think is this cluster that was fairly obvious, just looking at the data even early on.
I had mentioned a variety of research uses of the system, but there are a couple of points I would like to emphasize for take-home. First, this idea of a national health informat