[This Transcript is Unedited]
NATIONAL COMMITTEE FOR VITAL AND HEALTH STATISTICS
WORK GROUP ON NATIONAL HEALTH INFORMATION INFRASTRUCTURE
July 24, 2002
Hotel Monaco
225 North Wabash
Chicago, Illinois
Proceedings By:
CASET Associates, Ltd.
10201 Lee Highway, Suite 160
Fairfax, Virginia 22030
(703) 352-0091
List of Participants:
- John R. Lumpkin, M.D., Chair
- Marjorie S. Greenberg, M.D.
- Jeffrey S. Blair, MSA
- Simon P. Cohn, M.D.
- Daniel Friedman, Ph.D
- Susan Kanaan
- Eduardo Ortiz, M.D.
- Steve Steindel, Ph.D
- Michelle Williamson
- Clement McDonald, M.D.
- Mary Jo Deering, Ph.D
- Edward Shortliffe, M.D.
- Kepa Zubeldia, M.D.
TABLE OF CONTENTS
- Welcome and Introductions
- Population Health Panels
- Registries
- John Lamoureux
- Warren G. Williams
- Barry Gordon
- Population Health/NHII Interface
- Margaret Richards
- Oscar Morales
- J. Marc Overhage
- Personal Health Panels
- Personal Health Records
- Phil Marshall
- Vik Kheterpal
- Peter Waegemann
- James Cimino
- Integration of E-Mail with Clinical and Public Health Information Systems
- Ted Eytan
- Ron Nath
- Kathryn Bingma
- Personal Health Records
P R O C E E D I N G S (9:05 a.m.)
Agenda Item: Welcome and Introductions
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.
Agenda Item: Population Health Panels - 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.)
Agenda Item: Population Health/NHII Interface
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 information infrastructure, this experiment gives some credibility to. In other words, data can be repurposed and reused in these ways.
Second, the standards are critical. We don't get all the data from all of these sources in wonderful clean HL-7 format or coded in the way we would like, but we do translate everything into that format and that standard, because it makes it possible to build monitors, tools, edits and so on, that let us implement this with a realistic amount of effort.
A third point is, don't assume that there is magic. A little work can go a long way. It seems daunting at first to think about mapping all these laboratory codes and maintaining that, but we have continued to maintain that with less than a half of an FTE for the entire city of Indianapolis, with 14 different laboratory
sources reporting, once we have the map. So it is not an unrealistic amount of effort.
A few other things that occurred to me as I was listening to the testimony this morning, areas where the federal government may be able to help and facilitate moving things along.
First, that authentication continues to be a big issue for us. We rely on the individual institutions to authenticate providers to access the data. In other words, how do we know you are Dr. Smith when you come in our door and would like to have access to the data. I know that there is a lot of work being done with Quicksilver and a lot of federal efforts that may be leveraged to help with that.
A second issue is that coverage continues to be a major issue. Even though we have a huge fraction, probably over 95 percent of certain kinds of health care data in the city, we are still weak in terms of some of the ambulatory visits. It may not be quite enough to tip some of the processes over.
For example, we continue to have a challenge with some of the components of the public health department to get them to use this as a primary data source, because it is not 90 percent of the data that they get. They still count on blood banking data and things like that for some of their case findings.
I appreciate your attention this morning, and look forward to your questions. Thank you, and thank you, Clem.
DR. LUMPKIN: Thank you for the panel. Do we have any questions? Steve?
DR. STEINDEL: Yes, I have a question for Dr. Richards. You showed that very nice slide of the person who lives in Lake County, et cetera. The question I have to you is, what if the person lived across the state line in Michigan?
DR. RICHARDS: That is an excellent question. We have had some discussions about regionalizing this effort and talking about -- at least in the Midwest, I know John has been involved in some discussions about building interoperable systems across state lines. I'm not sure where that is.
I know that there is some interest, and everybody says yes, that needs to happen. Why we haven't gone any further with that, I don't know, I really don't know. I think the majority of states are in fact developing their own NEDS systems. That is the majority. I think it is a smaller number, somewhere in the neighborhood of 20, that are using the NBS, the CDC version. It is a good question.
DR. LUMPKIN: If I could jump in here, I think part of the problem with NEDS has been, it is a two-edged sword with the current environment, after the events of last October and so forth on the East Coast.
One is that there actually now is funding for every state to implement NEDS, but the second one is that there is tremendous pressure to have something up and running. The difficulty with developing a multi-state interaction is that where there aren't good standards, as we have discussed about NEDS being fully specified, then it becomes very difficult to build a system as well as negotiate with another state on how the system should be built, and still meet the time frames established under the grant program. So I think our best intentions are overwhelmed by events.
DR. LUMPKIN: Ted?
DR. SHORTLIFFE: Marc, I am impressed by what you folks are doing in Indianapolis. I wonder about the generalizability or the reproducibility of this effort, and what the unique characteristics are of your environment that allowed you to get this underway.
There is clearly a tremendous amount of cooperation among the provider organizations in the city that is implied by this. The fact that you have a single medical school and not competing medical schools therefore might be one important contributor here, but there also obviously is some kind of a shared recognition of public good that comes from this.
I didn't get the impression that people were required to participate, and that there was a kind of psychological buy-in that this was worth doing, or that people saw the value they would get back. There are some obvious questions about HIPAA related privacy concerns and shareability of the data and the like that you didn't directly address, but I suspect those have come up in spades recently as you have talked about the further evolution of this effort. So just some comments along those lines would be helpful.
DR. OVERHAGE: Certainly. First of all, we are blessed by having leadership at the health care providers that are visionary and looking to the public good, and the value of that.
The second thing, you talked about there being a single medical school. I'm not sure it is so much the medical school, but I think it is important to have a Switzerland. We have to have a neutral body to facilitate this process. As researchers and not as a care delivery system, I think that worked fairly well for us, in the sense that it is not the enemy; it is somebody who you can hold hands with and go down the road, made it much easier to obtain that cooperation.
A third thing was that we were fortunate to have support from some federal agencies in an HRQ to help offset some of the costs to lower the risk of entry into this. Now, certainly organizations have spent more than they were offset to do it, but not tons. That certainly helped lower the entry barrier and make it safer for them to make the decision to participate.
Then a fourth thing is that we move slowly. It is not just that we are slow. Sometimes you have to move slowly and build trust over time. For example, we specifically excluded sexually transmitted disease data in the first days, and those first days stretched out almost five years. That was by design. That was another way to lower the anxiety levels and concerns that, as we went down the road, people became very comfortable sharing that data under the same circumstances as they were sharing serum sodiums. That turned out to be a great thing, because that then gets reported to the health department. In fact, the way the county or local health departments' -- sexually transmitted disease starts their day now, as they dump the data from the system into STD MIS, which is their CDC based STD monitoring system, and they start working the cases.
DR. SHORTLIFFE: Have you in fact started taking the responsibility for that kind of reportable disease reporting, so that the participating organizations don't have to do it?
DR. OVERHAGE: We are not quite there. The data that I showed you about the outcomes from Q1 of last year are the step in that direction. It is actually much harder than one might imagine to validate that you are actually doing a good job. The data all continues to look very good, but we are not quite done with that task yet.
For example, the first speaker talked about matching cases by date and name and so on, and that turns out to be a challenging business, actually. So no, we are not quite there, but we are getting a lot closer.
DR. SHORTLIFFE: What about this privacy issue and the authentication issues?
DR. OVERHAGE: We have been very careful from day one to worry about privacy at all levels. I didn't emphasize the underlying infrastructure, but all the data are handled over a private data network. One could do similar things with VPNs and so on, but today everything is a private data network.
The agreements that are in place between the institutions deal with cross-enforcement and issues like that. So for example, if a provider at institution A were to abuse data that came from institution B, then institution A will discipline that provider in the same way as if they violated their own data and things of that nature.
In the clinical uses of these data, the patients in all of those care venues sign a consent form that contains language that has been, believe it or not, been approved by eight different health care attorneys, they all agreed. That was the most remarkable outcome. And the patients do provide explicit consent for the use of that data.
Then finally, for any research uses of that data, currently the model is, we go to each of the institutions' IRB, because as I said, we are simply the holder of that institution's data on their behalf, or a business or trading partner for them. If we want to look at that data for research purposes, we go and ask, and we go through the process.
One of my goals for the next year or so is to try to streamline that, and we have been looking at a variety of models. There is some published literature on how to attack that one.
DR. MC DONALD: If I could just throw in, in terms of the HIPAA --
DR. LUMPKIN: Well, you could if you introduced yourself.
DR. MC DONALD: Clem McDonald from Indiana University and a member of the committee. The part that is for treatment purposes is very clean under current HIPAA, so there should be no difficulty with it. We do have business relationships with the other organizations, so that is an important part of it. They would have to be permitting us to do that, as they do.
DR. LUMPKIN: Kepa?
DR. ZUBELDIA: I have a question for Oscar Morales. You mentioned this framework component, and the network has a component of security and network flows and data standards and all of this. Could a network like this be used by the health care community? Could the EPA share the network infrastructure that you put together? Because it seems like one of the problems that everybody is mentioning here today is that we don't have a standard way of communicating with each other. Is this something we could use?
DR. MORALES: Are you saying, would you like us to share the experience or you would like us to share the network?
DR. ZUBELDIA: Both.
DR. MORALES: The experience certainly -- I don't know, I would have to find out, in terms of the network. We are just really starting off, to tell you the truth. I think you would probably benefit more from the experience than anything else. I don't think it is mature enough yet to even consider the second one, assuming that it were possible.
DR. LUMPKIN: I think maybe we would like to rephrase Kepa's question into more of a request, which is that as you are developing this networking, getting more experience with it, that consideration be given to the kinds of issues raised in our report of the ability to extract relevant data for the caregiver, the health care provider dimension.
Obviously there are issues that may be pertinent if you are starting to see increased cases of asthma or something in your practice, having access to that database may be important, as well as to the population health dimension.
So it really is an issue of, if it may take a while to mature, if you are not thinking about these other uses, there may be decisions that you make that may preclude those uses being valid, timeliness and other -- quality of the data and so forth, that we would just like to have you consider.
DR. MORALES: Yes, absolutely. Actually, specifically on the network, we could arrange for a lot more technical briefing in terms of -- or more high level. There are aspects of this, I just made one of this whole presentation, but now that I know where you all are at, I could certainly come up with some other folks that you could benefit by hearing from their experience. That includes state folks as well. They are our partners in a sense, and I think that might be useful to you, hearing their side.
DR. LUMPKIN: Thank you. Jeff?
MR. BLAIR: Marc, this question is for you. I think you probably were given guidance that you would be testifying with respect to the population dimension of the NHII. So my question goes beyond that boundary a little bit. It relates to four different areas. Maybe you could help me understand this a little bit better.
Would you give us a little feeling about, number one, how the work in Indiana is encompassing or interfacing or working with NEDS? Number two, how you might be planning on accommodating to either moving to XML and what effect that might have statewide on the investment that you have already made?
Number three, I didn't hear any mention about the use of SNOMED codes, and I thought maybe you might comment on that and number four, could you give me some feeling for whether the network has plans to interconnect to personal health records, or access by individuals?
DR. OVERHAGE: Can I have three days?
MR. BLAIR: Obviously, and I didn't mean to blindside you.
DR. OVERHAGE: They are very insightful questions. First, in regard to NEDS, we work very closely with the state and local health departments, the Indiana State Department of Health is not as far along as Illinois, for example, in their NEDS development and deployment. In fact, we are in some ways acting today as the HL-7 information exchange broker for the state department of health NEDS system.
So for example, the state has asked the major national laboratories to forward their reportable data in HL-7 to us to them, and we have a formal agreement with the state department of health and are an agent of the department of health, and therefore can act on their behalf to receive that information, and then forward it on through the system. So we are very closely interacting.
The second question about XML is that we are somewhat opportunistic. We use what is available and out there. We are very involved in HL-7 version three, which is strongly XML based. When health care providers' data sources are ready to start sending data in those formats, we will be standing ready to accept it in those formats. I am not worried about that happening any time soon. There is not a big push among the providers to do that. Although I should point out -- with the technical difficulties, I didn't spend time on the map, but one of the -- in some ways, it is a blessing and a curse that we have, that with the different major health care systems that we have in Indianapolis, today we have interfaces to IDX FAMUS, we have one that is doing a SERNER install, one that is doing a McKesson HBFC install, one that is doing a GE install, including some that claim to be all-digital institutions when they get done. At least, that is what the TV commercials claim. So we have the opportunity to work with a whole range of the health care system vendors and see what they are doing and where they are, which has been very helpful.
The third point was about SNOMED. Other than the large commercial laboratories, I have yet to see a SNOMED code in a native message from anybody. So we rely heavily on, like I said, that wonderful coding system of Freetext for identifying organism names, for example, because they simply are not coded when they are sent. So we could do all the SNOMED we want, and it wouldn't get us very far.
Then everybody in this committee is well aware of the licensing concerns and issues that one has to worry about as well.
The final question was about personal health information. We have not directly tackled that, partly because we have plenty to do with the other parts of it. But partly too, the issues of authentication and so on become even more overwhelming, at least with providers. At least with providers, you have some way to figure out who they are, but with patients it gets remarkably harder.
We do have some practices who are doing that and leveraging information in that way, but we are not directly doing anything with the personal access to the information.
MR. BLAIR: Thank you.
DR. LUMPKIN: Thank you. Mary Jo?
DR. DEERING: For those of you who did sit in or at least came to the end of the last panel, you know that I have a take-home question for two of you, and then I have a second question that would be for all three of you.
For Marc and Meg, the take-home question is again, it builds on the idea of regionalizing, building across borders. It builds on the concept of adding content areas beyond what you may currently have, and adding users beyond those which might most traditionally be associated with the kinds of information that you are currently working with.
So given the vision of the NHII to move in those directions, what would your top priority be for federal action to help promote that?
Then the second take-home question that would also be for Mr. Morales has to do with trying to -- I know that the Secretary and the Assistant Secretary for Health as they look for things that they can do, obviously like all people they are interested in cost implications. I'm not sure any of us really know exactly what the most useful cost benefit information is necessarily, or whatever the right parameters are to look at.
But if any of you had to offer as an experience to the Secretary of HHS some cost information about what it is you do, offer us whatever you think might be useful to judge how much it costs to do what you do, and how much would it cost to do it on a bigger scale, whatever you seem to have available that you think would be helpful.
DR. LUMPKIN: We have two more questions, then we are going to break for lunch. Clem?
DR. MC DONALD: I had a question and a comment. The question harkens back to the EPA slides. I unfortunately didn't get to hear your talk, but there was a slide that shows why standards are important, and it has the classic bucky-ball looking set of connections.
But then it sounds later in the slide like you are doing standards inside your own place, which leaves you in that bucky-ball situation. So I just want to clarify if you are engaged with any of the standards activities outside of your organization.
DR. MORALES: We are. There was more problems internally than externally. That was the only point I was trying to draw there.
DR. MC DONALD: Okay. I was going to maybe offer another thing the feds could do in terms of Marc's good work. It is true, we have to take what they send us, so we can't make other people do anything.
In Europe, I was at a bunch of meetings for awhile, and they would get really mad at me, because they couldn't understand why I didn't make the Americans use a standard or another standard. They didn't understand how it is here. You can't make anyone do anything. They sent us three texts, but when you give an organism a name, there is not 500 ways they say Mycobacteria tuberculosis, so there are two or three ways they say it.
But the thing that is devilishly hard is how they say the negatives. If we could force them to put in a normal flag -- I think it is required in the HL-7 message -- so that one could not have to wrestle with the parsing of all these phrases that hedge the fact that the organism is not there, though it sounds just like it is there to the computer. That would be a great help, and it wouldn't be that much work. It is just a matter of encouraging that extra little --
DR. OVERHAGE: So you want us to make them do it.
DR. MC DONALD: Yes, I want to see if you can make them do it.
DR. FITZMAURICE: I am impressed with what is going on in Indianapolis and also with what is going on in Illinois, not only from what you presented, Meg, but also from discussions with John in the past two or three years.
I have a question for Oscar, a series of four questions, but they are short-answer ones. The first one is, are all of EPA's data sets describing your meta data registry, or what percent would you say are described in the registry?
Secondly, are all your laboratory data coded in a standardized way, that is, coded as a response to a specific lab test information request?
Thirdly, to what degree can EPA mandate the use of its standards across state data reporting? Can you withhold money from them, for example, if they don't report it the way you would like it?
Then fourth, what is the purpose of the EPA CDC collaboration? Is it for bioterrorism or is it broader? Again, short answers, since we do want to eat.
DR. MORALES: I guess about 30 percent, no on the second, yes on the -- you said short answers. The issue of mandating states, we have back-door sorts of ways that we use, in terms of, if you want to play and participate and stuff, even though the standards are not mandatory for them, they assume they are, for all practical purposes. We got $25 million this year for state grants. One of the requirements to submit a grant is that you have to accept the standards. And a bunch of other things too, by the way.
The last one was?
DR. FITZMAURICE: The purpose of the EPA-CDC collaboration.
DR. MORALES: It is that and a lot of things. I think that is what started it initially.
DR. FITZMAURICE: Volunteerism?
DR. MORALES: Yes. But a lot of things as of late came on. One thing comes to mind right now is, we are building a situation room -- God knows why -- for our administrator, and it is the situation that -- this is a bias that I am expressing -- rather than join on real-time data, it has more of an interest in scenarios. So there are those who want to use some sort of health related data, combined with environmental to build scenarios, the what-ifs. So that is just something that came recently.
DR. FITZMAURICE: Thank you.
DR. LUMPKIN: I would like to thank the panel very much. Obviously we could go on with additional questions, and we will probably try to corral a couple of you if you don't leave immediately after the break. We do have other panels this afternoon, and we are going to break for lunch. We are scheduled to come back at 1 o'clock. Thank you very much for coming.
(The meeting recessed for lunch at 12:15 p.m., to reconvene at 1:05 p.m.)
A F T E R N O O N S E S S I O N (1:05 p.m.)
Agenda Item: Personal Health Records
DR. LUMPKIN: We are going to get started with the third panel on personal health records. I=ll ask this panel to introduce themselves, starting off with Dr. Marshall.
DR. MARSHALL: My name is Phil Marshall from WellMed.
DR. KHETERPAL: My name is Vik Kheterpal from Medicalogic/GE.
MR. WAEGEMANN: Peter Waegemann from Medical Records Institute.
DR. CIMINO: James Cimino from Columbia University.
DR. MARSHALL: (in progress) I could simplify that. In our experience, a personal health record could really be any system that enables patients to view or manage their own health information. So I think anything that falls under that very broad definition could be considered a personal health record.
So who exactly wants them, and who provides them? First Consulting Group did a nice study a couple of years ago which looked at patient attitudes towards personal health records systems, found that a majority of patients showed some interest in having one. Many organizations now, two years later after that study, are beginning to implement them and provide these kinds of applications directly to patients, to consumers.
It is very exciting. Drugstores and PBMs are allowing patients to manage their medication profiles, using the web. Health plans are allowing patients to view their claims online, their explanation of benefits directly online. Doctors are beginning to share some of their in-depth clinical information that is in their electronic medical record systems directly with patients through reviewing applications.
Employers are getting into the mix. Certainly we have a lot of involvement with large employers like Ford Motor Company, Chevron and Microsoft, where they are beginning to enable their employees to securely privately manage health and benefits information directly online, manage their own information, their health plan that they have chosen, their more in-depth clinical issues, directly using the employer desktop.
Some of these organizations and systems are building them themselves, which is a daunting task to build a system like this yourself, but many of them are using vendors like us. Some of your larger information systems companies like GE Medical, McKesson Serner, are beginning to provide some of these applications as well. So a number of vendors are certainly in the mix.
One of the things that I know you are very interested in hearing about today is, what have we encountered with regard to the need for standards, what kinds of standards have we talked about in the personal health record community, and what kinds of standards could help us out. We have certainly given some thought to this in preparation for this presentation today.
I have boiled it down to a few of the things that we have talked about the most, and that we probably need the most help with. One is a minimum data set to facilitate data sharing. I know that this group has a nice long history in minimum data sets and working towards them. I think that in the personal health records base that they become very important, and I'll explain a little bit more about that in a moment.
Interoperability between electronic systems is something that when done well and facilitated in a way that maintains privacy and security can really help to realize the benefits of personal health records. Patient control and privacy standards certainly extended to these systems is important. Authentication standards; I'll talk about a couple of different areas of authentication where standards could help us out.
Finally, one that is a little bit less important and I'm not going to spend a lot of time here, I have a couple of reference slides at the end that you have in the printed materials, are about consumer terminologies to facilitate ease of use. We have created the consumer health terminology, the CHT thesaurus as our infrastructure for helping to translate various terms and clinical codes into consumer understandable phrases and to translate consumer slang, if you will, colloquialisms into medically valid concepts. So that is something we know something about.
It is interesting, when you see the use of thesauri and terminologies and clinical coding systems, that really speaks to a maturity or robustness of these kinds of systems. I hope that what that reflects for you is that this marketplace from a few years ago has come a long way.
There were a lot of companies a few years ago that were getting into the personal health records space, some that were hoping to throw up a web portal and make hundreds of millions of dollars at that. That has subsided, as we all know, and some organizations, some vendors, have persisted. Those that have paid a lot of attention towards their infrastructure for privacy and security, towards coding systems and being able to recognize clinical codes, to being able to use things like HL-7 and other interoperability standards. So the systems that persist today are doing I think a pretty good job of realizing some maturity they didn't have a couple of years ago.
So with personal health records, what really is the goal? What should standards that are supported in this space really help to achieve? What is the goal? I put a couple of thoughts down here.
Enabling patients to aggregate, integrate and share data across multiple providers and multiple systems. It enables greater consumerism, which results in greater cost management and health self management, as well as enabling critical information to be available at the point of care.
MR. BLAIR: Is that the same as continuity of care, or are you not using that word for some reason?
DR. MARSHALL: I don't use continuity of care here. I use point of care, because I think continuity of care is implicit in the fact that personal health records are an entity which stays with the patient. They are not necessarily associated with the points of care, and therefore by very definition, because they stay with the patient and they are the only kind of such system that would stay with the patient, that by its very definition it does go across the continuity of care.
So here is what I think we need. We need a way to incent or encourage the systems and organizations that hold patient health data to share basic data elements electronically and securely with other systems of the patient's choice. So when patients choose to use a system, to aggregate and integrate their data, they should be able to do so. So that is what I am going to be talking about here through the next few slides.
How to achieve this goal? Define the minimum data set, define a simple way in which minimum data set data can be shared between systems, insure that privacy safeguards are applied to these systems, address the challenges of systems authentication and individual authentication, and I will go into what I mean by those two different things in a moment, and incent and encourage organizations to share the data with consumer driven systems.
Minimum data sets. Starting here provides the foundation of portability, the portability of the minimum amount of data that can go across the continuum of care with the patient. Minimum personally identifiable information data set accessible by patients could insure that the minimum amount of data is available to guide care decision, cost prediction and self management.
I have listed some of the examples of what I would recommend as a minimum data set for personal health records here before you. In fact, I think that all told, there are only about 50 different data elements with all of these that could comprise a minimum data set.
Many systems hold data that would be part of that minimum data set, if you looked at that list on the slide before. But how will patients get access? How will they actually aggregate and integrate that data.
One of the questions that we might ask is, should all systems that hold such data be required to allow patients to view the data electronically using the web. There are a couple of questions that come up there. My sense is no. We work with a number of the organizations that hold this kind of data, and they don't have necessarily the wherewithal to do the user interface, to address the authentication issues that would allow their data to be directly viewed by patients. So I would say probably no to that.
Another question we should ask is, should all systems that hold such data enable patients to access it electronically? I believe that that is something that we need to go in the direction of, but then the next question is, download to what? What are they supposed to put it into? Are they supposed to put it into a smart card? That is one option that a number of organizations have looked at. Countries in Europe certainly have looked at it. But unfortunately, smart cards require readers, which is an overhead that not a lot of organizations are willing to bite off.
What about web-based applications? The nice thing about using web-based applications on behalf of patients to aggregate and integrate this kind of data is that they are generally readily available throughout the U.S. at care facilities. Certainly patients whether in their own home or at work or at the local library are gaining a degree of access that we could almost call ubiquitous. I don't know at what point you call it ubiquitous, but we are at least approaching that, I think.
So I am going to go in the direction with this line of thought, of what it would take to allow patients to use web-based applications that may be of their own choosing, a web portal if you will, or perhaps they want to use the web-based application that is being sponsored or offered by their employer or their health plan, or their pharmaceutical chain or what have you, whatever organization that would be sponsoring it. How would they be able to utilize that application to go out and get the data that should be a part of that personal health record?
They need to have some system interoperability to go in and grab that data. So how would we go about having a common interface? HL-7 in the CMS format are not necessarily focused on easing the exchange of patient viewable data. They have their own purposes in life. Especially with regard to HL-7, that can be relationship complicated.
We have implemented a number of HL-7 interfaces, but I know in working with the organizations who hold some of this data that HL-7 can be cumbersome. They always ask, why can't we implement a simple little XML exchange for just the data we want? And we are like, no, you are going to use our interface for HL-7, gosh darn it, and then about eight, nine months later we finally get rolling, because it take some time.
XML is becoming the default mechanism for data sharing, but even with XML, you have to define the content of the XML, so who is supposed to do that?
Well, I think that the need to standardize in this area is there. I think that standardization of electronic interfaces for showing minimum data set data will first enable patients to use personal health record applications to aggregate and integrate their information and to enable patients to share the data they wish to share with others.
A simple XML interface for the minimum data set would be easy for almost any organization to implement. I'm not going to make any recommendations for who should oversee the definition of those simple XML interfaces for that kind of minimum data set data. Perhaps it is an organization like HL-7 or others. But I believe we need some standardization there.
This interoperability standard really only needs to accommodate, like I said, maybe about 50 data elements in order for the minimum amount of data to be able to be nicely exchanged between systems.
Then the next challenge is authentication. You have system level validation and authentication, so when this system gets a request from this system to grab a patient's data, how does it know that this system is a valid system, a system that adheres to certain standards, that it is okay to give it data? You could have system certificates that say yes, I am WellMed or I am GE Medical Systems, and I want this data, so certificates electronically can make that easier. But even with certificates, how do you know that you should share that data with that system?
So a question I ask, and I don't know the answer to this, but I will throw it out, is, should we recognize accredited or authorized personal health record systems, whether they be those systems offered by EPIC Systems or Serner or McKesson or WellMed, or a system put together by Care Group or anyone else? Should we have a way of saying, yes, these systems adhere to certain
standards, it is okay to allow them to have access to certain data.
Then once we address that issue, then there is individual level validation; how do we know the person is who they say they are. Without a national identifier, you have to have some sort of master person index process in place to be able to do that. What are the standards for having a master person index that actually works, that you have a certain level of certainty that you are getting the data for that person. I think we are all aware of those challenges.
So I'll move on. The patient controlled privacy and authorization standards; do we need anything new here? With HIPAA, with High Ethics, with some of the other groups that are in place today that have established such great foundations for privacy and security, do we need anything new?
I don't know that we do, but I will say that standards for authorization and permission by patients for who should have access to what data will become increasingly important. I'm not sure that anything today with regard to standards or regulations or anything else that is in place really adequately address the issue of giving patients some control over who should have access to their data.
Systems that share patient data should comply with some baseline permission standards. You should know that sensitive data for one person may not be the same thing that would be sensitive to another person. So having simple rules that say anything that has to do with behavioral health, or anything that has to do with addiction or sexually transmitted disease is under this class of protection that should be considered sensitive, so you have to have patient permission. Unfortunately, you get into a lot of gray areas.
What we have found is that it almost has to be an item by item level of permission, because what is sensitive to one person may not be sensitive to another.
Then one of the other final issues is insuring that when these systems are exchanging data, that there is an audit trail in place to make sure that you can always look back to say who saw what when, and who exchanged what when. I think that that is an important issue to address.
This is my last slide, and I'll just make some quick recommendations. I think that it would be helpful to establish a minimum data set and through incentives, support and encourage that all systems collecting any data in that data set must be able to share that data with other valid personal health record systems.
Again, what is a personal health record system? It is a broad definition. This would give patients a mechanism for aggregating and integrating basic data across multiple systems, and the benefits will arise from there.
Number two. Support simple XML interface specifications for the exchange of minimum data set data.
Number three. In lieu of a national identifier, establish minimum master person index requirements for matching data back to an individual.
Number four. Establish minimum requirements for individual level authentication such as the use of certificates or alternatively, certificates saying that when a certain kind of organization says a person is a member of that organization, such as -- we work with large employers. When we get a person passed over to us from Microsoft Corporation, that person has been authenticated by the Microsoft intranet. They have a password that they use within the organization. Perhaps that level of authentication by organizations such as large employers is adequate. So I'll throw that out.
Number five. Support accreditation of personal health record systems to enable their access to other systems. Accreditation should require compliance with privacy, authentication, master person index, permissions and audit trails standards.
Who should do this? I know that IRAC is an organization that has been very involved in accreditation of increasing kinds of things lately, so that is one possibility. I'm not going to make any assumptions or presuppose anything, but that would be one possibility.
Then finally, number six. Support the wide-scale use of the patient's minimum data set and the use of personal health record systems. One way to do that -- and there are a number of ways to do this -- would be to support simply emergency room access to this kind of data and these kinds of systems that would allow this minimum data to allow a positive impact on the point of care. This is just one of many examples.
So with that, I will turn it over to the next speaker.
DR. KHETERPAL: Chairman Lumpkin, distinguished members of the committee, good afternoon. My name is Vik Kheterpal. I serve as the general manager for clinical information systems for GE Medical Systems. My comments here today are in the context specifically of a commercial vendor supplying clinical information systems to provider organizations to enable them to achieve whatever definition of personal health record that we evolve to.
In that light, I think we may wish to begin by recognizing that digitization within health care lags behind most other industries, at least within the United States. As a start, I offer an example of another industry, say banking, for example, that if it was run in a paper-based medical record or analogous work flow mode that the typical health care provider organization tends to operate today in interacting with patients on a day to day basis.
This chart essentially makes the point that access to the information about me as a patient from the health care provider to whom most likely I am paying significant sums of money in one capacity or another, that I engage and choose, is difficult at best.
The consumer adoption, taking the model of using other industries to teach us lessons about digitization in health care --
DR. LUMPKIN: Let me go back to your slide, if you would be nice enough perhaps to read it.
DR. KHETERPAL: Okay. Your bank, if run as our health system, you the patient, I'd like to check on my balance. Clerk, have a seat, we will send for your records. Waiting, waiting, waiting. Clerk, when did you make the deposit? The patient, last week. Clerk, how much was it? You, the patient, worried now, I have the deposit slip here somewhere. Clerk, hm, it must be in here somewhere. Did you make the deposit here at this branch? You the patient, no, across town. Clerk, oh, we will send over there for those records. Pause. Wait.
DR. LUMPKIN: Thank you.
DR. KHETERPAL: Taking the analogy further to say, the Quicken of health care is maybe what we tend to think about when we think about success being achieved as a personal health record. There are two specific lessons I would like to highlight for the committee here today. One is that populating your own record is an extremely onerous task. If the financial providers like Quicken had come out and said, please go through your bank statements and enter every last piece of information manually from here on out, that likely would not have resulted in the success that they have achieved today.
So first of all, the issue is, what do we populate it with and who populates it? The notion of the patient populating their own personal health record, we think, is a deal breaker by and large, for a second reason, not just for onerous, but secondly, because it is dangerous.
In health care, as a trained physician, I know we generate clinical information for consumption by medical professionals. The best example I have of this is, when we talk to patients, if we were to read aloud a typical Xray for some lesion that may appear on it and say, your Xray was negative, to the typical lay person, that sounds like bad news. That is an example of how we generate data within health care. So simply exposing it and populating records for patient viewing directly in their native state is likely a dangerous issue. Not to mention that the medical jargon that is used is not understandable by the lay public.
The second big lesson learned from Quicken is that we cannot apply the financial model of taking actual transactions from the banking industry and populating the Quicken record, and take that directly to the health care model. There must be a translation offered.
The second part is comprehensiveness. A partial record by itself, unless there are appropriate notifications, is a dangerous record. So only one provider populating a subset of the record for example, a partial medication list, for a patient to think that it is comprehensive as they go to the next provider is a dangerous record. That is something that we have to keep in mind.
However, the Quicken example teaches us some lessons that key transactions can be key catalysts in adopting such technologies and capabilities. For example, the ability to do automatic payment, even if I cannot balance my checkbook. So there may be examples in the health care industry to populate the personal health record, managing the dangerous aspects of it, but still offering certain capabilities to consumers and patients, that they do adopt it in mass numbers.
The point here simply is that the consumer behavior regarding self service, while it teaches us certain key lessons, they are not analogous and identically applicable to health care. Our experience at GE Medical Systems stems from two areas. Our logician ambulatory product was known as 98.7 and several other names through time. It was on the marketplace for two years, 24-plus months, where the patient was able to see the record that their outpatient was populating, and then managed and amended.
On the inpatient venue, on the acute care side, we have done controlled studies, controlled rollouts, and my comments today about lessons learned are related to about more than a thousand patients over two years that have used a personal health record from this provider populated model.
An example of such a screen is a patient health summary that our systems or systems like this might be able to generate for a patient to view directly online using the web. This particular screen, that is a screen shot of a health summary, and on the left-hand side are alerts and reminders.
We may want to see discrete data as a patient such as key lab results and previous history like an operative history, past surgical history, or a patient may actually be scheduled for a pre-operative -- would be scheduled for surgery and be interested in a pre-operative state. In this case, they are not looking for historical information, but actually more interested as a PHR, looking forward prospectively to where is my appointment, when is it, what does it mean to have a clear liquid diet, and things of that nature.
The point behind these screen shots is to quickly identify the scope of what a personal health record is. We think first of all, we ought to think about it from a self service perspective, what a consumer is looking for first and foremost is access to their health record, with choice related to where they access the record, when they access the record, and what mode they wish to see. Not only may they want to see it online, they may wish to get a print or fax in case they are looking for a second referral, and it is actually to take to another provider.
A second component of self service is approach. This is a key lesson we have learned. Is the purpose of the personal health record to deliver information in real time to the patient, such that as lab results become available this morning, I am interested in providing that lab result in real time to the patient for prospective care for later in the day. That is a very different purpose to a PHR than a retrospective longitudinal record that they would have access to in order to allow them portability in achieving health care.
So to us, that is a very important distinction and purpose of the PHR that drives certain usability and standardization issues.
A second their of capability in the personal health record. First we spoke about a uni-directional discrimination of information. The second is patient alerts and reminders. This is the classic health maintenance tips; you are due for your colonoscopy because five years have been up and you are over 50. That is oftentimes confused with a PHR system, however it is a very different capability of alert and reminder.
A third model that tends to come up in discussions of PHR in our experience is the ability of the patient to modify and communicate back to their provider. Again, here we think this is very different than having access to your longitudinal record. This is now changing the manner in which I communicate back, so a bidirectional record, in a matter of speaking, such that I can amend that which my provider is showing me, and then somehow communicate back to them regarding that change.
Our comments today are restricted to the information
access and discrimination as a primary area, not alert reminders and not bidirectional communication. I believe that is the purpose of a later session today.
The lessons we learned through this journey can be categorized in five areas. Insofar as the patient is concerned, technology and culture are really not the issue as a summary statement. That is not what we have discovered.
What we have learned is that stratification of a patient population and personalization are key success factors in driving usability and safe personal health record systems. An example here is to focus for example on chronic disease, and what you would deliver to patients for such a model is very different than a preoperative state that they may be living in.
From a provider perspective, the biggest struggle we have run into is that each clinician within a health care system believes they control the record. The current paper based record system allows the systems to continue to avoid a patient-centric global record, even at a specific provider entity.
A perfect example of this is discrepancy between the emergency room, the outpatient clinic and the ICU on something as elementary and so critical as an allergy list. There is no reconciliation in the paper world, so if we were to populate that, a paper based approach really causes problems.
From a policy security perspective, the enrollment process seems to be a universal need in the adopting organizations, a formal informed consent process, where patients who wish to participate in such a system actually are advised of the risks of participating in it, and to insure that they understand that a personal health record viewable by them anytime anywhere does not replace the clinical interaction and discussion that is intended when such results are reported, typically.
Work flow. If we were to move to bidirectional communication, the real success challenge tends to be the work structure inside a provider system to be checking for example e-mail or some other manner of a work cue as opposed to responding to pages or the phone ringing.
Finally, the organizational challenge tends to be a return on investment model that is dubious at best in the industry today, for a health system to invest in the capability to do this. The upshot is that the consumers are way ahead of the providers in this space.
A deep dive on usability. If we are to deliver real time communication, we believe that the population that is targeted needs to be stratified. For example, the education level and support systems, family support systems for the targeted patient, must be identified, whether they can digest that information. The phase of care that they are undergoing, are they looking at an upcoming clinic visit or are they preoperative or recently discharged makes a difference. Finally, the disease state; chronic diseases and how you interact with patients regarding communication and trending information there is very different than elective disease states such as cosmetic plastic surgery or something of that nature.
If we focus on longitudinal availability, primarily it becomes a policy issue for the provider. However, it is intended not as a stratified patient population, but to serve as a longitudinal record for the entire population that the provider system tends to serve, a very different model.
Finally, the real game changer here is the ability to take the personal information about a patient, disease states and such, and cross reference them to the reference information, so they are not having to do the search, thereby providing validated known sources of reference information about how to take care of themselves. Again, the devil here is in the details of how we go about implementing which definition of the PHR.
The challenges are a lack of a common lexicon as we all appreciate across health systems, which limit any pilot project to a particular provider entity in most cases. Even within the provider entity, a limiting challenge is the level of CIS -- clinical information system or electronic medical record implementation within the health system. The return on investment model for the adopting entity is immature and tends to be a challenge in accelerating such initiatives, and security concerns and risk aversion present long and -- in quotes -- delays to the process. Though well intended, they seem to be repetitive and we keep re-inventing the wheel there when we go from one system to the other.
Finally, scope creep and immature project phasing tend to threaten even a project launch.
Where we think we could really use help is to actually take a more realistic view of what needs to be done. In our view, that is a multiphased evolutionary approach to developing a lexicon standard. As my colleague Phil Marshall just went through, maybe focusing on a minimum data set, what we internally have been calling the problem summary list, and creating standards around that first and foremost is the best way to get started, which would include things like lab results, visit history and contact demographic information.
Secondly, ratification of a recommendation regarding security and enrollment processes would lend a lot of credibility to such projects, and insure that systems do not have to replicate through their legal departments every time they undertake one of these projects.
Third, while much of the work tends to be on lexicon and standards related to that, some research funding available for implementation and execution approaches we think is an area that tends to get neglected.
Finally, maybe a regulatory mandate for a basic universal registry, just as we talk about cancer, trauma, cardiology, would accelerate such initiatives.
Thank you.
MR. WAEGEMAN: Good afternoon. I do not have slides. I would like to structure my short presentation here into three parts. First of all, I think we should look at the issue of what are personal health records. The second part will be, what are the issues regarding personal health records. The third part will be what is going on in that market, in that field, what is going on internationally.
The first part is that we have to understand that an increasing number of people want a copy of all their health information. I personally some years ago got from 18 different providers copies of my medical record, 88 pages. I tested them on five different websites, an additional personal health record for providers. People want to understand in general terms the content of a medical record; others want to use any resource to learn more about their health issue and to be a partner to their practitioner and caregiver.
We have to understand that there are five different types. The first one is the offline personal health record. If you go to any software store, you find at least one or two products for family health doctor or personal health doctor, your medical record. I found five of them. There may be six or seven; two of them I haven't been able to locate. My research has shown that those have sold approximately 100,000 copies, where people are asking physicians and providers for their health information and are putting this onto their PC structured according to the software.
The second one is what Phil talked about. It is the web-based commercial organization of the personal health record. We have to understand, there are four different kinds, very different in their model.
The first one is the commercial organization, that derives revenue from sponsors and data mining. A patient provides information for free. The funding is coming from a sponsor. The sponsor has certain rights and certain influence over the information. It is not every patient's will to do this kind of thing, particularly if it is your employer or if it is some additional organization.
The second kind is where organizations are charging a fee. A fee ranges from ten dollars a year to $35 a year, is the most common kind. There are some organizations that are charging as much as $80 or $90 per year to have your personal health records stored there.
The third one is a free service to members. So you are a member of certain organizations, and they provide this as a part of the service or of the membership. There are increasing local, regional and national health organizations who provide this kind of service to their population. There are two cantons in Switzerland where they have taken the immuunization data, and on a population wide basis gave that information to one company, which contains such information and populates the information with practitioners' information and so on. This is increasingly done by a number of countries, particularly also in Scandinavia and in Asia.
The third kind is the functional or purposed based personal health record. If an individual is interested in diabetes and goes on a web-based system and looks up for any symptoms or solutions, he or she is being asked to provide personal information. This is identifiable information, it is health information. In return for being able to search for information for his or her health condition, they provide part of a medical record, if you like. This is not regulated, and it is being used by these companies for a number of reasons.
The fourth one is the provider based personal health record. We probably will hear next from Jim on that. It started out with four basic elements, appointment information, medication information, allergies, lab results.
I have not have any research, or I haven't seen any in the last six months. Six months ago, we had 89 clinics and hospitals identified which had this kind of service to their patients. The larger ones go from Care Group in Boston to some of the hospitals and clinics in California.
They seem to add one to two elements. They start with four elements. First you have access to lab information, then you have access to your medication list, and it goes on and on. As people become more acceptable to this way of opening information up to patients, it increases substantially.
The last part is partial patient information, where you find for an individual it is giving information to a website, because he or she is looking for some specifics in some way or another.
There are to my knowledge about 13 million people who have put their health information up on one of these websites. At this point however, we have less than ten million in active use. This comes to one of the issues. With the burst of dot-com, about 40 to 50 companies in the United States went bankrupt, were merged or purchased by someone else. There is no guarantee or no support for the patients who were in good belief that they could at some point have their health information on there. They are finding now that they go to that same website, and the website has been closed or is not available, or whatever.
In response to that, we at ASTM have worked on a standard which is specification. It just was piloted in May and is now becoming a national standard. It requires a number of issues for any of the sponsors. For instance, they need to make sure in regard to authentication and privacy that certain guidelines are there. What we have found is that there is not one company where they require the same confidentiality training for their database operators as a normal hospital would. They just hire sometimes database folks and they just work there.
The standard requires for instance that if at any time any of those companies are being sold, that their last action is at least to send an e-mail to all your patients and notify them that this is going on, and that you could potentially get that information, and so on.
It would take me about ten minutes to go into all the issues. I have quoted some parts on page four and five of my written text here.
What we have to realize also is, there is a big question of trust. I have spoken to many physicians, I have spoken to many clinics who have said, under no circumstances would we trust the information a patient brings in her as his or her personal health record.
It may take some time to get used to the idea that a patient has a complete health record. Of course, any practitioner has to rely on symptoms of patients anyway, so there is a fine line between the two things.
It was a dream about two or three years ago that the regular provider based record and the personal health record could be merged. Medicalogic was probably the main event to try this at some time. The figures I have at least are that patients weren't interested in that. From the many thousands and thousands of patients who had their records there, very few hundred were interested in having their clinic to download information into their personal health record. I may be wrong on that. If you have better information, I would be interested in hearing about that.
So what we have is a real problem of two different records being developed.
As I mentioned, in the United States we had more of a decrease in personal health records than an increase in the last two years. Most of the current number of personal health records are worldwide, and the main increase mont by month is in developing countries. If you go to India and if you look there at the ten percent of educated and wealthy population, they are interested in paying 30 or 50 dollars for a personal health record. If they ever get really sick, they fly to London or to New York and they have their health record immediately available.
So that is where the current growth is in the marketplace. What we have to realize at the same time is a really interesting part for the information infrastructure is coming from a different angle. There are now two or three international companies working hard and trying to create in countries some kind of an infrastructure based on a commercial personal health record.
I had to testify to the Knesset in Israel, where they are considering a system where for ten dollars to be paid by the health insurance system, nationwide, continuity of care would be provided where every provider, every hospital could get to this web-based information system, and it would not cost any hospital or the ministry of health any money, because it is in the interest of the people. They haven't decided on it, and I don't know if they ever will, but it is an interesting proposal.
The same is being done -- and I understand some organization is in Washington, trying to interest some departments of HHS on that. They have recently opened an office and are trying to create a nationwide system based on a personal health record which is a combination of provider record and would create continuity and would save substantial money, and could be paid for by health plans or by insurance companies who are willing to pay additional money for that.
What will happen, we don't know. All these are early proposals. The bottom line here is that personal health records have been an area where we had hundreds of organizations starting on it. Most in the United States are not there. At this point we have a few survivors like WellMed based on sponsorships. What we have otherwise is an increasing number of provider organizations that have plans putting information available to patients. What we have to look for in the future is how these various different movements will merge into one system for the benefit of the patient and the provider at the same time.
Thank you very much.
MR. BLAIR: While James is getting his slides ready, consistent with our practice of full disclosure, I am employed by the Medical Records Institute and I report directly to Peter Waegeman.
DR. LUMPKIN: Well, you won't be able to vote today then.
MR. BLAIR: Nuts.
DR. CIMINO: Sorry for the delay. I was asked to come and talk about some of the experiences we have been having at Columbia University with patient access to health information. I define health information to include both patient specific information and non-specific, more generic health information, because the difference between the two is becoming blurred as we start to have things like personalized messages that can include elements of both.
So I am going to talk today about two projects, one called the patient clinical information system, or PACIS, and another one, the myocardial infarction health education aimed at rapid therapy, which coincidentally has the acronym MYHEART. Then I will talk about what we learned, and standards issues we came up with, and where we go from here.
So first of all, the PACIS project was a project that was funded by the National Library of Medicine through the national health information infrastructure program. It started about six years ago, I think, and we had a 40-page proposal that basically said two things: we would give patients access to their records, and we would see what happens.
And in terms of seeing what happens, it wasn't simply, would they use it and how they would use it, but also what was going on in their heads a little bit as they used it, were they understanding the record, was it causing problems with the doctor-patient interactions and so on. So it was more of a cognitive study than a technical study.
The PACIS architecture just very briefly was a web-based front end to the New York Presbyterian Hospital's clinical data repository, so it is a repository that has been accumulating data since 1988. We simply put a web-based front end on it for patients.
We had to address security issues obviously for access. We did not however attempt to create a patient view of the record. This was simply a view of the data in the repository, pretty much the way their clinicians would see the data. Then we added other things, educational resources, guidelines and something we called info buttons, that I will show you some examples of.
As you can see, we do not spend a lot of the government's money on developing a flashy interface. It was more of a functional one, but our users found it quite functional. The main parts are over here; you will see them better in your handout, I guess. We have data entry, data review, advice and education, were the four main components of the system.
right now, we are looking at data entry. We had vital signs and blood sugar as two of the options. This is a screen that was designed to allow patients to enter their data. If patients enter data in this, the data would be stored in our clinical data repository and their practitioner would get an e-mail message notifying them that their patient had entered data into the system.
This is an example of data review. Here we are looking at a list of blood gasses, potassium, sodium and so on. At the top you can see the different kinds of laboratory data available. Over here are things called info buttons, which are links to specific information about what the user is seeing on the screen at the time.
Here is another example of a data review screen. This one is from a Pap smear. We have an info button here again. I'll just read the diagnosis here. Within normal limits, no endocervical cells present, no squamous metaplasia present, no date of last menstrual period provided, inflammation. So that is an actual report.
We were curious about what would happen when users saw such a report, and we surveyed women and showed each woman ten different Pap smear reports and asked them if this was your report, what concerns or questions would you have. It was interesting. Someone else mentioned, a negative test Xray was seen as a bad thing. When people saw within normal limits, limits seemed somehow like a bad thing, so they were concerned about that. No squamous metaplasia, they weren't sure whether it was good to have no squamous metaplasia or not, or whether it was good to have no endocervical cells or not.
So we built an info button application to take the text, parse out the findings, and then show them a customized report to explain what was actually in that report, and then give them links to other resources.
Here for instance, it says, within normal limits means there was no evidence indicating cancer. Endocervical cells are normally present in a Pap smear, and so on. Then there are a number of resources down at the bottom that they can go to, including signing up to get a reminder to get their Pap smear every year.
Finally, the advice was a place where we started to bring together patient data and medical knowledge, to give patients more customized messages. I have a picture of the data input screen for this cholesterol guideline here, but patients would -- if they selected the cholesterol guideline, the system would go out, pull up whatever clinical data it could from the repository, in this case cholesterol levels, age, gender, so on, and then the user would have to fill in other information if the user knew it, what diet he or she is on and so on. Then if you click Start Guideline, it would give you a customized result. It runs the NCEP guideline and gives you the appropriate message for those data.
I'm not going to show you the education. That was just a collection of links to other outside resources.
The evaluation consisted of several different things, questionnaires online. We looked at the usage lives to see what people were doing, and then we had interviews over the phone an din person. Interviews were both with patients and their physicians.
The results. We followed 13 patients for a total of 36 months, 223 patient months in total. It is a small patient population. This is an artifact of our institutional review board, who required that I go to the physicians first, and they had to volunteer patients for this study; I could not go to the patients directly.
The technical barriers to PACIS were not an issue. Patients were very easily able to log on, fill out the enrollment forms, use their log-in password and secure ID number to get in. It really was not a problem.
If we look at the usage, this is over the first 17 months of the study, we broke down each of the things in the usage log, and we found that the overwhelming majority of usage was data review. So over three-quarters of the usage was data review. Of the data review, more than three-quarters of that was laboratory results. So it was pretty much laboratory results that they were interested in seeing.
They were not particularly interested in the educational materials or the guidelines or any of the other things we put up there. We found that they were looking at their lab results and discussing it with their clinician, and it was improving their understanding of their condition. It was also improving the communication between the doctor and the patient.
The other project, MYHEART, is a little bit different project. This was sponsored by NLM and the NHLBI as part of the national heart attack alert program. This project in general was seeking to decrease the time from the onset of symptoms, a myocardial infarction, to the institution of appropriate therapy in the emergency room.
They actually had a lot of success decreasing what they call the door to needle time, the time from patients coming in the door of the emergency room to getting the thrombolytic therapy, but the biggest part of that time period they were having trouble attacking was the time from when the patient had onset of symptoms to the time that they called 911 or otherwise initiated a trip to the emergency room.
So we were looking at ways to use computer-based resources to help this, one of which was to use the web as an educational medium for educating patients about signs and symptoms of myocardial infarction, what to do about it, and the other was to look at how we might use clinical data to customize the messages that they get, for instance, by tying it to data in an electronic medical record.
We had a controlled trial. We had three patient groups. The first was a control group that was the standard. They used paper based materials. There was a non-tailored group that got the standard materials, but in a web-based delivery mechanism, then we had the tailored group, that received customized web-based messages based on their clinical data.
We used online questionnaires to collect data from all three groups, and we did it at baseline prior to getting the educational materials one month after getting it accessed, and then three months. We looked at how well they were able to understand their personal risk of heart attack, whether they had the appropriate knowledge for what to do in the case of a heart attack, and also self efficacy, how well they felt they would be able to perform the required functions.
This is our front page, and I'll leave it for you to read in the handouts on the MYHEART project. We allowed patients to do things like customize the text, because we had a lot of diabetic patients and elderly patients who might need help with the font size. You can see we started to get a little more sophisticated in our user interface design. This is just a standard message, information about heart attacks that all patients would receive, and there were also things like testimonials, and we had patients and physicians who provided sound bites about what to do in case of myocardial infarction.
This is an example of a customized screen, where we have taken the patient's risk factors and built a message about those risk factors for this particular patient, not a real patient.
Here is one where we customized the message. Instead of saying, if you are supposed to take nitroglycerine, then take nitroglycerine, but if you are not supposed to take nitroglycerine, then don't, instead we know that Ms. Amy Sharp is supposed to take nitroglycerine, so we can create a customized message that tells her about that.
Here is one where we take information from the questionnaires that they filled out to give them more educational materials, saying, since you said you didn't think you had an increased risk, but you were not correct. You thought your risk was low and it is high, and so on.
Finally, we can use the questionnaires to give them other messages, just for reading in the handout, as an example of what the questionnaires looked like.
Results. We had a little bit better recruitment this time, over 120-plus subjects. Although the study officially ended, we actually have some patients that enrolled rather late, so they are still finishing the study, so we are still continuing to collect data and do some of the analysis.
But what we found so far was several interesting things. One was that the two web-based groups improved on the scores, as compared to the paper based groups. So web-based education seemed to be a better educational medium.
The second was, to our pleasant surprise, the tailored group showed sustained improvement at three months compared to the other groups. So both web-based groups learned at one month, but the effect was more sustained in the tailored group.
What we learned from these two projects. First of all, patients can handle the technology. We really didn't have much problems with access issues from our patients. Patients seemed to want their results. Sometimes they don't even want the actual results, they just want to know they are in the computer so they can then go to the doctor and say, my results are in the computer, please tell me what they are and what they mean, but I know they are in there, so you should be able to get them for me.
Patients want to collaborate with their physicians. They are not trying to take over their care, at least in our experience. They want to know what their physician knows, so they can have a more informed discussion.
Finally, the EMR, electronic medical record, and the web, together can be an effective educational medium.
The standards issues that we ran up against. One is browsers. I don't know if it is within the NCVHS' purview to set standards for browsers, but I can tell you that you will double the software productivity in the entire field if you can get everybody to standardize on one version of one browser.
DR. LUMPKIN: And that would be?
DR. CIMINO: Not having stock in anything right now, I can offer an unbiased --
DR. LUMPKIN: You don't have to answer that.
DR. CIMINO: Patient identifiers some of the other speakers have talked about, because identifying who the patients are obviously is important.
The terminology for patient data is obviously a big concern for this committee, is one of the things we found we needed, not just for representing the data itself, but also for linking to other information resources, such as the info buttons and guidelines.
The access to high quality resources could use some standardization. Each of our links to educational resources had to be custom built based on that resource, and then when the resource changed its user interface and moved around somewhere, it became problematic, either for us to get access or for the patients to understand how to use these things. The structure and access to guidelines also could bear some standardization.
For instance, we could take any set of patient data and pass it to a guideline system, and any site, and get back a relevant message from that guideline.
This also brings up the terminology issue again, because the terminology used in patient data and the terminology typically using guidelines is often at different levels of granularity. So standardizing the terminology should address both those levels of granularity.
So where do we go from here? Where we would go if we had all the standards that we could make use of, first we would have to identify the agenda by involving patients in this decision making. A lot of this was done as, let's see if we can do this and let's see what happens, but really, what is it the patients want to do with this information, what do they want to get access to, and how do we best do that.
Then we have a number of infrastructure issues that we have to address. Obviously the standards are the first one, identification of patients is the second, dealing with confidentiality, and other speakers have discussed this at length, access.
One of the biggest problems we had with the MYHEART project was people coming up at the end of talks we gave to different populations in the community and yelling at us, because how dare we only do this on the web, why can't we do this on a paper based access. So a lot of people were afraid they would not have access to this technology, even though it is in public libraries and so on.
Education, learning how to use the technology to get to the stuff, and also have an education level that people can understand the information when they see it.
Then we need data. We need a standardized format and content for data, and we need a standardized content and format for the educational materials or health information resources.
That's it.
DR. LUMPKIN: I would like to thank all the panelists. This has been a fascinating panel. I'm sure that we will have many more questions that we won't have time to discuss. Mike?
DR. FITZMAURICE: I would like to start off with a question for Jim Cimino. Jim, you are well known for undertaking desirata for classification terminologies. I just wondered if you have given some thought to the needs, the criteria for good browsers, what should they have, what shouldn't they have.
DR. CIMINO: I think for good browsers, first of all a standard language, for instance, a standard for Java script, a standard for HTML, a standard look and feel to a certain extent, so that people don't have to learn a new thing every time they encounter a new piece of software. I think those are big obstacles to users. Beyond that, I haven't given it that much thought.
DR. FITZMAURICE: So that should take about a month. We are talking about problems that are years in the solving.
DR. CIMINO: All you have to do is say what the standard is, and if everybody hews to it -- HL-7, there was a lot of grousing about HL-7 when it first came out. When we turned to all the folks in our institution who were trying to put data into that clinical data repository, we went from three systems over a course of maybe two years, to two years and three months, we had 12 systems, because the people just wanted a standard. They didn't really care what it was. They didn't have any vested interest in one versus the other. They just wanted some rules to follow, so they could play the game.
DR. FITZMAURICE: Who should advocate the standard? Should NCVHS advocate that one exists? Who should then follow the dictates of the recommendations of NCVHS? Is that something that the Secretary of HHS should do, or is it something the industry should do? Who should do it?
DR. CIMINO: Well, that is a good question. Since I am sitting here, I'll say that NCVHS should do it, because I can't get anybody else to do it.
I think there are other mechanisms. Other standards groups could promulgate some. I haven't seen any. They may be in the works, but you are really outside my field of expertise there.
DR. LUMPKIN: And our plate is a little bit full.
DR. COHN: I think I am going to try to get back to something I know a little bit more about instead of browsers.
I'll ask a question, Phil, start off with you, and then Jim Cimino and the others can comment on. Both of you in your presentations -- and Phil, you put it in your reference material at the end -- talked about needs for reference terminology, which is probably the physician ICD-CPT diagnosis and procedure stuff, at least in your terminology, and also coming up with something that is appropriate for the patient. Jim Cimino was making the same sort of comments.
My question about this, you described it as an interface terminology, others may describe it as a patient centered terminology or whatever. I guess the question I have for both of you and others is, is this an area for standardization? Is this an area where there is propriety differentiation and should be left as something the company holds as a proprietary distinction? How should we approach all this?
DR. MARSHALL: I think that is a very interesting question. Let me give you a little background on where we come on this. I think that there were some very small efforts prior to 1998 when we set out to create the consumer health terminology, the CHD thesaurus. I created that with Dr. Michael Rosen and Dr. Brad Bowman, and then we increased it from there.
Our notion at that time is that we were going to create a competitive differentiator for the company, potentially a licensable vocabulary product. We set out from the outset to create an interface terminology to other underlying reference terminologies.
In fact, we used SNOMED-RT, moving to SNOMED-CT. So we used that as the underlying reference terminology of our system to provide the taxonomic integrity that our system needs in order to do several things, to deliver personalized information and content, to be able to walk taxonomic trees, in order to be able to understand truly what the patient has, and the like.
Now, having said that, we also use the UMLS as the inter-mappings between the different vocabularies that we support. So if we import lab results in LOINC, if we import ICD-9 codes from folks like Empire Blue Cross Blue Shield, which is a client of ours, if we import CPT codes, we can even recognize mesh codes, what have you, we use the UMLS to intermap that.
We use that in order to be able to first of all build a profile on the user that is consistently coded, and then to be able to deliver information that is indexed to the reference terminology layer back to them.
Now, let me tell you how this unfolded. It is a little bit of a differentiator for us, and it has been a real important differentiator for us. But the thing that didn't happen is that we found that there was a market per se for selling vocabularies. In fact, we found the vocabulary market to be not all that interesting or lucrative.
We are still kind of alone in the consumer health terminology bit. There is the personal health terminology put out by IMO that is very respectable. I think that -- I can't speak for them, but I know from our standpoint that what we found is that standardization would be fine, I think we could participate pretty actively in that process if we were to pursue that. I think to the extent that there are several different kinds of personal health record systems from those not just like web portal kinds of personal health records that Peter mentioned, that are not just EMR extensions that a couple of others mentioned, but there is also all the drugstore chains that are showing medication profiles, there is claims histories being shown from a lot of health plans online, all these fall under that.
You realize that there is a lot of latitude for misunderstanding by the patient of what these systems are putting out there. They are running into all the same kinds of problems. So I think that there are potentially some opportunities for standardizing that, and it wouldn't necessarily be that tough. We set out to create the most terms possible, the most preferred terms, the most synonyms, to cover the gamut. What we have come around to is that although we have over 35,000 terms in the CHT thesaurus right now -- the terminology extends out to several more hundreds of thousands of terms and concepts out to the UMLS -- that we actually only need to be able to translate those things which patients are going to run into. They are going to run into ICD-9 codes when they get claims histories from their health plan. They are going to run into laboratory results from their laboratory, and should be able to translate LOINC or SNOMED codes.
You don't need to do it for all the granular concepts. You can map things up to a little bit higher level concept and be able to do it at that level, and that is why you need that taxonomic integrity underneath. So you don't need necessarily 100,000 or 200,000 consumer terms and phrases out there. You simply need to be able to translate those things which they are going to run into, and you don't even need it translated at the granularity that it might come in at.
You might be aware that ICD-9 codes can get very granular. The type one diabetes mellitus without mention of ophthalmologic manifestations, that really just means type one diabetes, that is really all that means. You don't need all that other gobbledegook. But yet, it is a little bit different level granularity.
So you need to be able to map it up to something that is still consistent, still accurate, but you don't need hundreds of thousands of terms.
Anyway, the short answer to your question, I think that there is some opportunity for standardizing this. Certainly we would be happy to participate if there was a sense of this group that that would be valuable.
Jim, what do you think about that?
DR. CIMINO: I tend to think about the problems at the conceptual level, and then mapping from the conceptual level, which is really what a reference terminology is about, to the level of the user.
So for instance, the concepts that clinicians and patients talk about are really the same set of concepts; it is the terms that they use that are different. So the standardization, the first steps are to define standards for representational schemes, so we can exchange these terminologies. Having standards for how we represent the terms, that is, if we are going to talk about a disease or symptom, what is it that we need in a representational scheme to do that, then finally, the content itself needs to be standardized.
After that, I don't think it is that difficult to map. I would rather see patient terms mapped to such a conceptual terminology rather than trying to create a separate terminology, and then map it to the clinicians' terminology.
So for instance, when a patient says cold, my patients talk about two kinds of cold. One is the thing that we can't cure, the common cold, and the other one is a term for phlegm or sputum. So when they say I have a cold, they mean slightly different things. I don't want to just record that the patient said cold and not know which one they meant. I want to have it mapped to the concepts that the rest of us understand and can do something with.
To do that, we need not just standards for the terminology, but ways to represent it so that it can be explained to patients. I think going one step further, it is not simply just move up a level and explain it at a higher level, but also we can generate for instance from a definition of a term, a formal definition, we can create definitions that patients can understand in an automated way.
So I would look at standardizing the concepts and then the mappings from the interface terminology, whether it be patient terminology or clinician terminology into the reference terminology.
DR. KHETERPAL: From an implementer's perspective, I totally agree with the other two speakers' comments. Structural lexicon integrity needs to be in the way the clinical information is being generated by the provider. If we had integrity there, it is simply another manifestation or another view, a patient understandable view.
We look at a variety of things. There are language issues. You want it in English, you want it in Spanish, you want it in French, so you would have many things. So the standardization from our perspective is not at all in the patient terminology world; it is actually the underbelly, which is the manner in which clinical data gets generated by the provider. If we had that, then there would be market differentiators coming from commercial entities and others that would say, I have a better, more easy to understand patient handout on diabetes, and patients tend to prefer this one versus that.
So it is not the handout that we are necessarily trying to standardize, nor a standard term, the way a patient would think about diabetes. There may be multiple ways, and there are cultural differences, so very much not on the patient's side.
DR. LUMPKIN: I have a couple of other names, and then I have two quick questions myself. Then we'll go to Catherine and Clem.
The issues raised in the minimum data set, to what extent do you believe that the role of government, in other woos, this committee and its advisory role to the Secretary, is to anoint something that may already be in process, such as through the ASDM or other development process? Or do you believe that there isn't enough happening out in the private sector that there would need to be some other effort by government which we have not done much of as a committee for probably ten years now?
DR. KHETERPAL: It is rare for a large organization like GE to come and say we invite regulation, but in this particular event, I believe voluntary participation -- one is the availability of a standard. Much of what you are describing is the emergence of the standards. What isn't there is the burning platform for folks to jump onto the standard.
So I wouldn't recommend that the government establish the standard necessarily alone. However, where one begins to emerge, enforcing it. The real commercial examples of this are, the reason ICD and CPT codes get used across the board is because that is how you get paid. Medicare started that and everybody else followed. You may hate it, you may dislike it, you may like it, but the fact of the matter is, it is something we can all rally around. It is not perfect.
I think the minimum data standard, having some body that says, if you are going to participate in Medicare payment, you must be able to, just as you do a UV-92 on various kinds of administrative information, you must be able to ante up the following clinical information, for example. That would drive an adoption and maturity, and get everybody to settle and move to resolving some things much quicker.
DR. MARSHALL: I agree. I think that again, if you go back to the goal of enabling people to be able to aggregate and integrate their own data, we believe that there is value in doing that from a democratic standpoint, from an empowerment standpoint, from a cost containment standpoint, because empowerment does lead people to be more cost conscious when making care decisions.
I think that somehow, empowering, incenting, enabling organizations who have any of that minimum data that we might define, making sure that they will ante it up is something that can be very important. Yet, they have to be able to ante it up to other organizations or systems that are working on the patient's behalf to gather it and aggregate it and integrate it.
So I think that your group could be very helpful in supporting that.
DR. LUMPKIN: The second question, which I almost hesitate to ask, because we are in Chicago and this is the last place that we had a discussion about this issue, has to do with the unique identifier for individuals, which I think was mentioned.
Obviously, there is utility for that. Do you think that through the mechanism of developing personal health records there may be a voluntary way to establish a criteria or a methodology or a master index of these identifiers that then would be available to be subscribed to? When someone would sign on to one of these records, they could subscribe to that. Do you think that may be a workable solution, other than a system of assigning a unique identifier, which obviously is not very popular?
DR. MARSHALL: I think from our experience, you can define a mechanism which meets a minimum level of criteria to say, if you have a combination of this kind of data, there may be several different kinds of combinations, that you can be reasonably assured that you have got the right individual. It is that mechanism, it is that system of matches, if you will; there is a statistical component of that as well, that systems if they adhered to it would be able to then work this out without having a single national identifier. That is my experience.
DR. KHETERPAL: I think this is an area again of utility and pragmatism. If we were establishing a health system in this country 150 years ago, we would say that is a great idea. But we are where we are, and the path of least resistance to get there from here likely is what I think large complex organizations that have acquired other hospitals which use other systems have learned.
The manner in which you do that is to take a cross referencing master patient index approach, essentially a subscriber model. What tends to work is an execution issue, it is an implementation issue. An organization that tends to own multiple hospitals and clinics that have different identifiers finds themselves with a very distinct business need to do so, and they find their way around it eventually.
What is lacking is, there is no such incentives today across health systems, across entities. Given the fact that health care providers are a highly fragmented entity in the United States, what is needed is a reason for them to do that subscription model.
That is hard to imagine without some external force providing that. But as an approach, I think that is the right model.
DR. CIMINO: I think to the extent that patients start to drive this process, maybe there will be some voluntary efforts on patients' parts to participate in having their own unique identifiers. So that if a patient is deciding, I am going to create my record and I don't want to do it twice or three times or five times, I want to do it once, and I want to be able to bring in data from each institution that gives me my care, then I am going to identify myself appropriately to those institutions so that I can get the data.
So it may be that patients will buy into it when it is in their interests to do so. Right now, they may not see that it is in their interests.
DR. ZUBELDIA: I want to take a step back, because I think we still think of the world of islands with standard bridges that connect them.
Going back to your presentation on the banking versus health care, it seems to me like if we are building the personal health record based on the concept that I am going to download the information from the providers into my own box at home and then I own it, and whoever another provider wants it, then I will give it to that provider, it will never be in sync. I think the provider that has the original source information will have a different view than the one that I have at home, maybe because my translation dumbs it down to the level that my children can understand, or for whatever reason. It may not be in sync.
I agree that I need to have control over my demographics, street address, telephone number, insurance coverage, all that stuff. But as a consumer I wouldn't have access to lab reports, to change those. That should be totally out of bounds.
Instead of data that migrates from the personal health record to the provider record to the public health record, is it possible to build a connected infrastructure, where I have part of the record at home with my demographics and employer information and so on, and my providers, physicians, suppliers, have their view, and if I need something, maybe there is some sort of robot in my system that goes and fetches it to display to me. They can do it the other way around. When I go to the pediatrician with my children, they can pick up from my home computer or my Palm Pilot or whatever I want to carry, the demographic information necessary to complete that view.
So there is one view rather than a multitude of replicated pieces all over the map that will never be in sync. Is that possible? Because if that is, I think we will get closer to what the NHII described. I think it would remove that term, like the personal health dimension, which would be the personal view of the same data that the physicians are seeing from a different viewpoint, but it is the same data. Is that feasible, or we don't have the connectivity yet?
DR. KHETERPAL: I think you raise an excellent point, which peels the onion a little deeper to say, physically how does one execute this personal health record, where is it replicated, who has it.
The paradox here is that by law and by all expectation, the patient owns their record. Just as on paper they tend to never have the complete copy of it, there is something to address a consumer's concern of saying, who do I allow to hold it on my behalf. We tend to take, because of various lexicon and other issues, a paternalistic approach to the patient in saying, I will own it. Today, the I tends to be the provider system, the doc's office, the hospital where they get care.
In our vision, as a practical matter, it is in fact the real struggle and why I am most interested in participating here today, that it is hard for a business entity, given the current environment on the trust issue, to say I will be there, not just the trust equation with the patient, but also potentially the anti-competitive issue.
The providers have no real reason commercially speaking to allow portability of the information. It allows me, the patient, to go across the street more easily and find another provider.
Therefore, there are two folks who are not willing to trust this to happen. The physical model, whether it be a peer to peer model, technical architecture perspective to be able to do that, we can do that with ten gigabyte videos and other sorts of channels and then downstreaming audio content.
Certainly the technology exists out there. These same folks, many of them, are able to do that, peer into other peoples' servers to be able to download the latest audio track from -- I don't even know what the current fashionable singers are, I apologize. But I think the technology does exist. It is a policy issue and a trust issue.
DR. LUMPKIN: Clem? And unfortunately we will have to make Clem the last questioner, because we are running into our break.
DR. MC DONALD: I had three thought threads. One is, you were talking about simple XML. It is always simple between two people, and once you get to 20, it is the same standardization problem. So I think you have to be careful about that.
But what I heard actually from Vik and from Peter, this is very, very tough. Vik, I thought you really characterized all the dimensions of it, where I have never heard it done quite that well. But this is very tough. Maybe no one wants it.
Could someone elaborate on that? That is, why are we so worried about this, if the patients aren't asking for it? That is what I thought I heard Peter say.
DR. MARSHALL: I think you have to be clearer on that. I have to comment there, because I think if you are looking at commercial portals as PHR companies, there has really not been a success there. We have never seen ourselves as a PHR company, really more of a systems vendor.
If you look though at the success that health plans are having in showing their EOBs online to patients, if you show what pharmacies and PBMs are doing with their medication profiles directly to patients, if you see what some of the EMR systems are now doing, which I know you are real familiar with, all of those taken together show I think very much an increase in niche areas of success on personal health records, if you put everything under that umbrella, where patients are getting much greater access to a lot of the information that these systems hold. It is not the PHR portal play, but it is other plays that are gaining some success.
So I think patients do want it. I think for certain commercial interests, it works well. I agree with Peter that the PHR portal is not something that has gained success.
MR. WAEGEMAN: What we really see in health care is the same what happened at the end of the 14th century when lay people could read the Bible. We are starting a process of patient empowerment. We haven't talked about -- personal health records create patient empowerment, which has shown that it has much better patient compliance. People who know why they get a medication and what it does are more likely not to flush it down the toilet or even throw it out and so on.
These studies have been made. In our firm we haven't talked about them. The second part is, there was one study which had shown that also patient involvement and the patient knowing his or her health information, that uses health care costs. Unfortunately, they ran out of money. It is not conclusive. But the first information was that this is really good.
So what we really see is that more and more people want to get involved in that. What we have to realize is that the commercial organizations are somewhat shrinking. Phyllis is a representative of one of the few ones which seem to be doing quite well to survive. But many of us have been going under.
What we have to realize here is that business is switching over to providers, realizing that patients want to see their lab results, their medications, their allergies and so on. So that is where the whole field is moving.
A couple of points, since I have the microphone here. I was proud of myself in not jumping up here when we talked about a national identifier. I think we do not need one for personal health records as such. We may need one otherwise.
Secondly, we don't need a specific health care identifier. I was asked some years ago whether the airline industry should create a passenger identifier. There were people from the health care field who said, yes, it is only the government which doesn't allow it, but you should issue a card for every frequent flyer of any airline, and so on and so on.
What we have to realize is that people are working -- I don't need an identifier for my Amazon business relationship or any of the 20 or 30 others I have. What we have to realize is that there are different people working on that. We have the MS passport for Microsoft, now we are looking at Liberty, which may be successful. There is a third one coming out of Sun at this point and Microsoft, and all of this will probably end up with some registration system for PKI. But I think we are wasting our time if we are saying that personal health records and their success depends on an identifier. That would be misleading in some ways.
DR. KHETERPAL: If I may make one comment, Clem, it is hard to do, was really my point, more so than, people don't want it. I think in the studies we did, patients absolutely -- to have a work station with browser capability to the Internet say yes. Forgetting the health system for awhile, every doc who has to take care of a patient says, this would be great, because I finally get to step up to the patient and know their holistic history.
DR. MC DONALD: What I was actually getting to, Peter said -- and you could have the answer to it, that he heard it did its thing and a very small number actually used it. You may know the details on that.
DR. KHETERPAL: There are security concerns. That is the number one reason -- and we do have the data if you would be interested -- that those who chose not to participate, what were the top reasons, number one was inability, just don't have the work station, et cetera. Number two was security concerns, because they don't have clarity about who has it. Those are the top two reasons. Utility, use, those are not the reasons that folks say no to this.
DR. LUMPKIN: Unfortunately, we are completely out of time. Actually, we are over time. As I mentioned earlier, we find the suggestions of this panel to be really quite fascinating, and will be something that we will have to revisit as a work group and I think as a full committee. So we really appreciate you coming in.
We are going to have a ten-minute break, and then we will resume for the final panel of the day. Thank you.
(Brief recess.)
Agenda Item: Interation of E-Mail with Clinical and Public Health Information Systems
DR. LUMPKIN: We are going to get started with the last panel, consistent with the focus on trying to define issues related to the personal health dimension. We are going to be looking at issues related to the integration of e-mail in clinical and public health information systems.
I understand that there will be a slight change in the agenda and Ted will be going first. But I am going to ask the panel if they will first introduce themselves.
Also, since we are doing live over the Internet, this is being simulcast or digicast or webcast -- anyway, I am just casting about for a term, I know, but please speak very closely to the microphone. They get a much better sound quality.
So Kathryn, if you will just introduce yourself, we will go down the line with introductions, and Ted will start.
MS. BINGMAN: I am Kathryn Bingman from Cerner Corporation.
DR. EYTAN: I am Ted Eytan from Group Health Cooperative.
DR. NATH: I am Ron Nath with Apelon Incorporated.
DR. LUMPKIN: Ted?
DR. EYTAN: Good afternoon. I am honored to represent Group Health Cooperative in informing the important efforts of the work group on the national health information infrastructure.
My name is Ted Eytan, and I am a practicing physician and clinical lead for Group Health's patient Internet portal, www.mygrouphealth.c.org. We have been asked to inform the work group with our experiences providing online services to our members.
This year alone, Group Health primary health care teams across the state of Washington and North Idaho have exchanged 17,500 secure messages with patients. These are in addition to other services such as pharmacy online, shared decision making tools and discussion groups. Group Health is in the process of implementing a comprehensive clinical information system that will include a patient personal health record accessible from our website in 2003.
A little perspective on Group Health. I am not going to read all the numerical statistics up there, but it is important to know we are the largest consumer government health care system in the United States. In looking at the document put out by NCVHS, I think we represent multiple categories of stakeholders, including health care provider, health plan, community foundation, consumer group, research institution and health agency, in a lot of the work we do.
Our reason for existence, our purpose, is to transform health care, working together every day to improve the care and well-being of our consumers and communities. Our record of innovation in the areas of evidence based care, population health and patient empowerment is well characterized.
On to what we are doing online. Our stated vision for online services is to enable unparalleled access and transparency by connecting members, staff, community providers, purchasers and brokers with Group Health and with one another at the right place and the right time.
This is a screen shot of the current mygrouphealth patient portal. I am going to focus in on secure messaging, but you can see on the right there under enhanced suites some of the services we offer to patients.
Secure messaging. Secure messaging services were successfully piloted in November 2000 at our Redmond Medical Center in Washington State. The pilot ended in May 2001, and services are now available across the cooperative to 100 percent of our adult patients receiving care at Group Health medical centers. One hundred percent of primary care health teams who provide care at Group Health medical centers are available to their patients through this service.
When we embarked on creating online services for patients, there were few if any standards available to us as a care delivery organization. The situation is largely unchanged two years later. A team of information services professionals and clinicians co-developed secure messaging at Group Health. This team was the forerunner to today's medical informatics division at Group Health, which provides strategic leadership and coordination on issues related to our information infrastructure, which is similar to the ideal described in the NHII strategy.
Part of what we developed is a lexicon for these health care services. We do not use the term e-mail, since it describes a different interaction than secure messaging. Secure messaging is a protected online exchange that includes elements such as security, privacy, confidentiality, participation by the entire health care team rather than just the physician, service standards for turnaround time, integration with the medical record and population level monitoring and improvement.
This is a screen shot of patient access to the talk to your health care team application. There is more below, but in that little popdown menu they can choose any member of the health care team at their medical center. That is driven by a database, of course. I will show pictures of what the staff sees in an upcoming slide.
One of the issues of standards was that of authentication. We did not find a community standard for granting access to personal electronic health care information. This has been alluded to by several of the speakers before me.
We recently completed another review, and still cannot identify a community standard, largely due to the fact that so few organizations are granting us access today. We currently requirement the patients to present physically to Group Health or a notary public to authorize access to their information or the information of those for whom they have durable power of attorney. This is to verify that at at least one point in time, both patients and Group Health verified that access to this information was desired by the patients.
This is a copy of the two-page identification verification for access form that is filed in the chart.
Regardless of the method employed to authenticate patients, we empower them to make the choice regarding access to clinical data. Those patients who do not fill out this form are given access to a basic suite of services, as opposed to the enhanced suite of services, on mygrouphealth that does not allow display of demographic or clinical data on the member website. So those numbers, clinical data, is effectively blocked from being accessed on the Internet.
In terms of medical record integration, Group Health has defined processes for integration of online activity into the legal medical record, which are separate for health care teams, consulting nurses, patient care representatives and business office managers.
We put out these quick reference guides, and here is a screen shot of the quick reference guide for the business office around secure messaging. There is a discussion of medical records responsibilities, where various pieces of documentation go, and some guidelines about what can and can't be discussed over secure messaging.
Although Group Health has several online clinical systems currently, at the current time the legal medical record is the paper chart. So health care teams use their professional judgment in placing secure messages into the record. This is done by printing the message and placing it into the chart today.
Each printed out message like the one displayed above has relevant identifiers, plus the complete interaction thread between the patient and the health care team, as well as an audit trail and tracking information for service quality. You will notice, this is what the staff sees when they open a secure messaging from a patient, and this is the complete data set except for some auditing information that is not displayed here that they see. Specifically, there is no linkage to their problem list, diagnoses codes, level of service, et cetera. That is to balance the need for quick service, training 300 physicians to use the service, and usability by patients.
Messages are placed in the documentation portion of the chart alongside visit notes. ID verification forms are placed in the correspondence section of the chart. Through this process and the associated technology, we now have a medical record that is written by patients and health care teams at the same time.
In the future, when Group Health has transitioned to its electronic medical record, our plan is to include secure messages which are listed here as patient e-mail in this test system as encounters, on a par with office visits and telephone encounters, but able to be filtered by staff users.
Group Health is not a standards making body. However, we work vigorously to apply standards in the informatics realm, just as we have done in the clinical realm using evidence based care. EPIC Systems Incorporated, who produces this medical record, is working with us to implement our clinical information system.
We have defined our clinical information system as an a automated tool for the provision and documentation of care to Group Health patients at the point of care, regardless of where, when or how that care is delivered. So it is not a tool just for Group Health staff.
Because we tie secure messaging into the process of care, the issue of portability of this data is likely to be integrated into the issue of portability of all clinical data. So we are transitioning from a system that we developed ourselves to one that is hosted as part of this clinical information system, and so the secure messages will be tied into how you move all clinical data, because it is now part of the record.
Now and in the future, secure messages will be a conduit to other health care services, such as information prescriptions, medication prescriptions, testing and other followup. We are working with EPIC to design systems that allow the seamless movement of secure messaging data into aspects of clinical care as well as self care, self management and shared decision making. So a physician today might use secure messaging to guide a patient to use other services.
On the left you see a picture of the member in-box, too small to read the message, but that is a reply from a physician, which might be linked to shared decision tools which we have on our site today. Our online pharmacy, where patients can get their medication list and have medications shipped to their homes, and information therapy, so a link to a piece produced by Healthwise Incorporated on hypothyroidism at the bottom there.
Secure messaging may also be the conduit for bringing structured data into the clinical record, such as medical devices for patients, health risk assessments and shared decision making tools. In Washington State for about ten years it has been law that patients can examine their records and amend them as needed, so this might enable the process. We believe that clinicians probably need to be involved in patients putting data into the clinical data repository, so this is a future idea of how it might work, where from a health risk assessment or personal health record, clinical data might travel into the in basket where a clinician will review it, and it will populate the clinical data repository, and maybe have attached to it order entry or documentation relevant to that interaction.
Here is a blurb of the EPIC Systems personal health record that we are looking at. You might envision that a patient sees a physician and that day or in near-real time, they will have a visit summary of what went on in that transaction, including orders, patient instructions and plans for followup. This would come directly from the clinical information system.
In terms of moving patient data into the clinical data repository, this must be done in a way that is transparent to the patient, so the patient knows how the data is being used and where it is going.
Health systems who seek to transform health care like Group Health can assist by critically assessing standards under development and applying them successfully as demonstrations to other health care systems. Our expectation when we assess and select technology is that we use systems compliant with the latest standards. This is the expectation we set for ourselves when we develop our own systems. Our experience tells us that this approach supports a better and more affordable care experience for patients.
A current barrier to the development of standards in the online patient arena is the lack of adoption of online services across the greater proportion of health care providers and plans. So we often find ourselves out there by ourselves, trying to educate people about the value of these services.
In terms of what the Department of Health and Human Services can assist organizations is through their leadership. Our experience has shown us the benefits of secure messaging in terms of care coordination, improved service and access to health care teams, and better, more timely information to assist in decision making.
DHHS can help educate the public in the health care system on the value of secure messaging and patient-centered online services and improving care, coordination of service, and access. This will speed adoption by promoting adoption of plans by patients that offer these services, and promote competition on the basis of better service to patients.
In addition, DHHS can provide leadership by bringing all of the stakeholders together that are involved in the online area to develop solutions that allow maximum transparency, that foster innovation, and that incentivize health care systems to be responsive to patients 24 hours a day, seven days a week to treat patients as equal partners.
This concludes my remarks. I think in the last several minutes, I am going to show a short video, making this real and what it means to patients and doctors that use this service.
(Whereupon, a videotape is shown.)
DR. LUMPKIN: Thank you. Ron, are you next?
DR. NATH: Yes, I am next. I think I will take this opportunity to make a couple of apologies. One, I apologize for not having a handout. I was hoping to print them out when I got here, but that didn't work out. Two, I apologize, I am going to have to leave shortly after my presentation because of time constraints. I have a flight earlier than I would like.
DR. LUMPKIN: That has never happened to any of us.
DR. NATH: My name is Ron Nath. I am a practicing neurologist and a clinical consultant at Apelon. Dr. Steve Steindel asked me to talk about consumer health vocabularies, so you can blame him for my being here.
With respect to how this ties into e-mails, I will mention that later on in my talk, I thought it would be interesting to discuss how Apelon went about creating a consumer health vocabulary. The things I am going to talk about briefly are a little bit of a background as to consumer health terminologies. I know that we have already heard a little bit about them from previous speakers, from WellMed and NGE. I was also going to talk about our specific approach to how we developed a consumer health vocabulary, the current status, what I see as the applicability to patient-provider messaging or e-mail, and what I think are some important future directions for this effort that we have undertaken.
As far as the background, I just want to mention some of the previous and related efforts, what we felt was our motivation at Apelon to go out and do it again, essentially, and what our specific goals were for the Apelon consumer health vocabulary.
As you have heard, other companies have already undertaken and done this. WellMed and IMO were two that were mentioned, and those are the two that I am familiar with as well. The UMLS which was also mentioned actually does have quite a few consumer health terms embedded within it; unfortunately they are not specifically identified as such, which would have made this whole exercise unnecessary, if that were the case. Then there have also been a few academic papers that have been published as to what should be the scope of a consumer health vocabulary and so on.
In fact, doing my research, I found that there are some terminology issues with consumer health vocabularies; people have called it all these different combinations and permutations, whether it is personal health terminology or consumer health vocabulary or consumer health thesaurus and so on, so there is actually some issues with the naming of this whole idea as well.
So what was our motivation? Obviously there was a need to do this sort of translation. We recognize that it had been done before, but these things were only available from other commercial entities. We weren't sure of their quality. We didn't want to license it and then find that it wasn't something suitable, so we felt that we could do it as well and hopefully better. We wanted to do something to differentiate ourselves from other commercial vendors of medical terminology content.
So our goals then were to add value to the standard vocabularies that we provided to our customers, without additional licensing. This would be included as part of the license to whatever they got from us, whether it be SNOMED or ICD, et cetera. We wanted to make sure it had what we felt was the appropriate breadth and depth of concepts, as well as mappings to these standard vocabularies that we have already discussed.
Our approach to development. Since we were starting from scratch, which is always a daunting challenge, we had to figure out how we were going to do this. It is not something that you can just sit down and start brainstorming, and coming up with a list of thousands of consumer health terms.
We wanted to figure out where could we go to get some of these consumer health terms, because we knew they were out there. Then we had to figure out what was the appropriate level of sophistication, the educational or grade level of these terms. Then the scope of terms. We had to figure out, how much did we want to cover, and how in depth do we want to be about it. Doing this, we learned a few caveats along the way. Then finally, we had to figure out the mappings we wanted to do. To do all these things, we wanted to use our own in-house tools and expertise, which we have an extensive amount, working with the UMLS and other government agencies.
The content sources that we worked from. We started with the UMLS. As I mentioned, there is a number of consumer health terms that are embedded in there, and we tried to come up with strategies to extract some of them and identify them. We also went to various consumer oriented medical websites, had both human volunteers as well some machine mining of these websites.
We also did what we thought were some hopefully useful reverse mappings. As has been brought up before, not every clinical concept deserves to have a consumer health term attached to it, so instead, we looked at what we considered the top one thousand and top 500 CPT codes, and tried to make sure that either we already had a term from one of these other sources, or one of our clinicians had to come up with it.
Then we also looked at some searches that have been done by people who go to the NLM websites. Some of that information has been available to us, and we looked at that as well.
As far as the level of sophistication of terms, we didn't want anything that was too offensive. I'm sure there are a lot of terms out there that people use that I don't think we would expect them to use for doing this sort of searching. We also didn't want the terms to be too simplistic or childish. So we basically went with general newsprint article level, which is, we estimate, about an eighth grade reading level.
As for the scope of the terms and breadth, there is a whole range of possibilities, and we wanted to limit it to the things that we thought consumers would be interested in. It just so happens that at the top of the list is alternative health. That is a big thing now among consumers, and we wanted to at least have some representation of that. As it turns out, later I will show that there is actually very poor representation of alternative health concepts in the standard clinical vocabularies that are out there.
Of course, the other things are also things that people are interested in. They will talk about various problems with anatomic locations, obviously all the diseases they have. Then with drugs, it wasn't so much specific drugs that we wanted to map, but more categories of drugs; yes, I am on a high blood pressure pill, or I am on a water pill, or I am on an acne medication, that sort of thing, the various providers, but other people as well. Then the procedures that people have undergone, and various general medical concepts as well.
As for the depth of terms, we estimated we would like to have anywhere between 10,000 and 20,000 terms. I know WellMed mentioned they have 35,000 terms. I think part of it depends on this whole notion of overlapping with standard medical terms. As it turns out, consumers are increasingly having a lot more sophistication with their own vocabulary, so what we found is that terms that I would normally consider clinical professional medical terms are actually falling into the lay category. So we had to decide, are we going to keep these out or are we going to keep them in.
Then we realized that there really isn't such a sharp distinction between the two, but rather it is a continuum. On one end of the spectrum, there are terms that are obviously consumer terms that no professional would use, and the same thing on the other end of the spectrum; there are professional terms that no consumer would ever understand. But then there is this gray zone or this overlap between the two vocabulary sets. Recognizing that, we decided to go ahead and keep them if we felt that somebody with an eighth grade education would know these terms.
One of the things that we found as we were developing this scope of terms is this notion that for a medical concept such as otitis media, there wasn't a simple translation; you had to express it as middle ear infection or a nosebleed for epistaxis. One of the risks you run into doing this sort of thing is that the consumer terms start to become more of a definition rather than an actual term, so that was again something we tried to keep track of. We didn't have these long sentences to describe a medical concept, because at that point you weren't coming up with a terminology, more something like a dictionary.
The other thing we noted is that consumer terms are very imprecise, so we expected the consumer health terminology to be much smaller than the total clinical vocabulary that is out there. So for instance a patient may say, I had a broken leg, and that could mean any number of official clinical diagnoses.
The mappings issue of course is a very central one to us, particularly at Apelon, since we work with a number of medical vocabulary content. We initially decided to have SNOMED-RT as the central mapping, but as we have gone along, we have decided to also have mappings to ICD and CPT independent of SNOMED, and perhaps even map it to the UMLS codings.
There is this difficulty though. We found that there are a number of consumer terms that we have located that really don't actually have a professional term to map to them. That was something that we felt was surprising. We had the opposite view, you would expect, but there are a number of these things that people are talking about, that right now there is not a good representation for.
DR. LUMPKIN: What is an example of that?
DR. NATH: Well, particularly in the alternative ALF domain. That comes right off the top of my head. But it is something that patients are interested in. They are talking about magnetism and crystal healing, things that we would just say that is a bunch of baloney, but that is what people are interested in.
DR. LUMPKIN: Thank you.
DR. NATH: So as far as the in-house software tools, we tried to use tools that we already had, but we also had to do some custom development of tools to go out and mine these websites. Then we used our Apelon CBRI product, which helped index the terms that were harvested from these websites, and then go back and map them programmatically to UMLS concepts. Then finally, we used the Apelon TDE, the terminology development environment, to actually see these mappings that were done automatically, as well as identify those consumer terms that didn't have an automated mapping. Then we actually had to get nurse terminologists to go and map those consumer terms quite laboriously to SNOMED, is where we started. That took over a year to do that.
What is our current status? We have about 15,000 total consumer health terms. We found that about 10,000 of those were algorithmically mapped, and of the remaining 5,000 we were able to manually map about 4,000 of them. There were still about 1,000 that we really couldn't map. Again, it was quite surprising, but the nurse terminologists say, there really isn't a good standard clinical concept for these things that consumers are talking about.
Then I'll just mention a little bit on the usages as well.
So these are some of the numbers here, just to get down to the nitty-gritty. We have about 7,000 terms that describe various medical conditions, about 5,000 of those were algorithmically matched, 1800 were matched by the editors, and that left about 200 that couldn't be quite mapped.
I think the interesting thing to note again is something like the alternative health care terms. There weren't too many of them. There is only about 400, but you can see that there just isn't good representation of that. We only mapped about 20 of those automatically, and only 80 of those by human review. That still left the vast majority of them unmapped, which brings up the question, does it need to be added to something like SNOMED or is it something that we are just going to ignore.
As far as the usage of our consumer health vocabulary, we envision people using it not just for e-mail and messaging, but for going to web portals like the NLM or other medical websites and typing in terms they are familiar with to learn about their conditions. We also envision this terminology working as an interface terminology. You get an explanation of benefits or some other clinical information that you can't understand normally, but through the use of tools in this terminology, it will hopefully be understandable to the consumer.
Then we also think that there may be the reverse. If people are putting in information, it could conceivably be translated to a professional term, although I am not quite so sure about that one, because I think there is again this issue of imprecision.
As far as the applicability to e-mail and messaging, I have to confess, this is something that Apelon didn't initially consider when we set out to develop our consumer health vocabulary. As I thought about this issue, to me it made me wonder, if this e-mail is going to be automatically generated, okay, I can see a role for something like this. But if it is being written personally by a provider, hopefully that provider will be doing the translation and writing consumer understandable terms. Perhaps though there could be some software to verify that. That would be my only other thought, as to how this terminology might interface with provider messaging.
So as far as future directions go, obviously standards are a big thing. Right now, there is no standards body saying this is what a consumer health vocabulary is or what it should be or what the scope is, all those things that we had to wrestle with. It would be good to have something like that put out there.
The participants -- to this point we have had three commercial organizations, some academic papers put out, but nothing cooperative at the national level. I think this is where I would really like to see something like this become part of the UMLS, perhaps. I think it would be important to have some sort of distinction that these synonyms or these term types are actually consumer health terms, and going forward I would like to see something like this maintained by the NLM, as opposed to a private organization such as ourselves.
That is all I have to say. I'm going to have to leave in a few minutes, I'm sorry.
DR. LUMPKIN: Thank you. Are there any clarification questions before Ron leaves?
DR. DEERING: Simply a point to think about. When you said right offhand that you had a hard time thinking about how it could apply especially to structured e-mail, and that is understandable. But to the extent that I understand some organizations are considering much more structured e-mail, it is much more like a checklist. You don't just have a preformed narrative input from the patient. Clearly the need to have identifiable terminology for them to check, I am writing you about, and that is when you have the vocabulary.
DR. NATH: Right. You are envisioning the consumers writing these e-mails to providers? Then they are going to be read by the providers?
DR. DEERING: Again, I don't know how far along many of these models are. It is much more like filling in an on-screen form, as opposed to doing an open-ended narrative question.
DR. NATH: Right, I think that is where it would be particularly useful, exactly.
DR. LUMPKIN: Thank you. Have a good and safe flight.
DR. NATH: Thank you.
DR. LUMPKIN: You may have missed my earlier introduction, so as you are walking, don't forget to stop in some stores and spend some tax dollars. Our economy needs it.
Kathryn?
MS. BINGMAN: I am Kathryn Bingman. Again, I wanted to thank you for allowing Cerner to be represented here today.
I just wanted to discuss some of our insights regarding personal health records. I currently serve as a vice president and general manager of Cerner, and I head up the division called IQ Health. I do have this focus on providing health care consumers with both access to their personal health information and online connections with their health care providers. We believe that this will ultimately improve health, patient safety and the overall health experience.
Cerner has been around for over 20 years, and we are a visionary leader in providing information management systems designed to improve health care. We are based on Kansas City, Missouri, and we have clients that span the globe, U.S. to the United Kingdom to Malaysia. So I have covered this in many different areas. We are considered by many to be the world's leading clinical health information technology company for hospitals and clinicians.
We design all of our solutions to accomplish one mission; that is to connect the appropriate persons, knowledge and resources at the appropriate time and location to achieve the optimal health outcome. That vision is at the core of our goal to enable consumers to access and proactively use personal health records to manage their own health and that of their families. That is an underlying premise of what we do.
Today I am going to outline what Cerner has discovered as some of our important considerations in creating systems, processes and standards that enable clinical and personal health records to be all inclusive, connected, and ultimately improve the quality of health care delivered.
We have 24 projects that cover a wide variety of initiatives, all attempting to connect the consumer to the health care process. I am going to describe a couple of those that we have worked with directly to creatively deploy technology for consumer-driven health care management, and get into some of the messaging components that we are interested in.
In 2000, we partnered with Winona Health and Hiawatha Broadband Communications to connect the health care community. Winona, Minnesota is about 35,000 people and it was the ideal site for an online demonstration project because of its size. It is a very close-knit community and is a self sufficient medical community, and has ready availability of the Internet. Over 70 percent of the people of the town are connected via the Internet, so that is very good for this.
The primary goal of the Winona Health online project is to place the individual person at the center of his or her own care and to arm them with the tools needed to better manage their health. This is achieved by providing the individuals with their own personal health record, where they can record and store and manage health information for the entire family, and with permission from the consumer, grant physicians and other clinicians access to that record. This is enabling the clinicians to make better and informed decision. Secure messaging and the triaging of those messages to the appropriate clinicians provides enhanced communications and the most efficient use of the clinical resources.
Currently we have 40 of the 50 physicians in the town connected. We have the hospital and four of the seven pharmacies connected, and so we have had some very interesting results on that, and are still making additional progress.
In 2001 we partnered with Eastern Maine Health Care to provide online solutions for consumers in response to the governor of Maine and his blue ribbon commission on health care findings. The personal health records have been deployed as a care coordination solution to support citizens of Maine in making better health care decisions and in accessing necessary care and information.
We are also partnering -- Eastern Maine is partnering with large employers in the state, so that they can enhance their rural health initiatives. That is using communication vehicles to secure messaging to supply support of care, rather than having somebody have to come and visit the health care provider.
Through our experience in Winona and Eastern Maine, we continue to learn about the challenges of consumer-driven health information management. I will share with you some issues regarding standards today, but I am happy to discuss any issues regarding adoption in the projects that we have embarked on so far.
From a perspective of health care information system suppliers, typically in the personal health care realm, they provide a view into the EMR. I think that came out in a couple of the discussions earlier today, as a personal health record solution.
We don't consider that the true personal health record. A personal health record differs from the electronic medical record because the information is owned and maintained by the consumer. Cerner believes that the ideal personal health record is one that is populated both by consumer entered information and clinical data collected across a continuum of care via messaging and other interfacing. It is accessible by health care professionals at the appropriate time. It is controlled by the consumer, and is portable. So it is not owned by a health organization that may sponsor it; it is owned by the consumer, and they can continue using that even after the sponsor discontinues sponsoring the program.
In order for personal health records to succeed, physicians in hospitals have to save the data electronically. This is a self populated PHR, and it is not going to be successful in the long run. So a standard currently does not exist for the electronic medical record, and that is really a necessary component of being able to have a standardized personal health record as well.
HIPAA requires that providers give patients access to a designated record set, a DRS. Although that is not well defined, it calls for individuals to have access to all their data that their physician believes can be shared safely without harm to the patient or other individuals.
As the DRS is standardized in electronic format, using existing standards such as HL-7, that should eventually reside in the personal health record. The DRS coupled with consumer entered information allows for better management of a person's health.
A very simple example of this is an adverse drug reaction that can happen that a consumer could be alerted to when they enter that they are taking aspirin and they have been prescribed Prozac. It will send back an alert saying, don't take those together.
Standardized personal health records would speed the submission of data to public health organizations via electronic means rather than paper, as it often happens today. A standard format combined with security standards in a standard vocabulary will create huge benefits for research, disease detection and surveillance initiatives. This in turn would facilitate the development of new and improved guidelines, which would ultimately improve health. So very important to make these steps to start collecting all this data.
The standards alone are not going to be enough, because they don't insure that the information is going to be shared across organizations, and the benefits for public health and for really being able to improve the health of our country can only be attained when there is enough critical mass in a given community or across the nation to get meaningful information. This is particularly true when applying surveillance technologies which will capture sometimes very subtle indicators that signal an attack or outbreak.
Currently there are many different agencies and health systems providers that recommend self care standards. A good portion of the care that is given to people in the United States happens outside the four walls of an organization.
National self care guidelines would predict more predictable outcomes across the country if it was integrated with the personal health record, so that somebody could help manage it themselves. The standards can be used by personal health record systems to send reminders, to give information in the context of the individual's health status, and to alert the patient and the provider if their measurements are not within normal ranges.
In some of the discussion earlier about, the consumer does not understand the data given, what we have done in our current projects is to template that information so it is interpreted for the consumer before they receive a message. So they don't say that their lab results are abnormal, it says what it means for it to be abnormal, and then what their followup steps should be.
Providing guided self care extends patient safety to the home, which is something that I think is really key. The Institute of Medicine tries to put the consumer in the center of this. Being able to collect all this data would allow for further refinement of guidelines, helping to eliminate the unnecessary variance in the self care process and across the health care system in total.
Health vocabularies have been discussed quite a bit. We agree with a lot of the approaches that have been talked through today. We agree that the eighth grade reading level is extremely necessary. We also have to take into consideration the bilingual and multilingual needs within the nation, and that is becoming more and more prevalent, and so we have to address that as well. Then being able to take that information and have it truly be usable by the consumer, so not just giving them the vocabulary, but giving them access to information that explains what that vocabulary means. So we are in support of that as well.
We use the UMLS in our core system. We have to extend that to be able to address consumer needs as well, but that is our backbone for being able to tie all the clinical information that is captured today. While this helps in the clerical area, we have to make sure that it is changed for consumers, and they really use it.
Security continues to be a vitally important consideration. With Winona and Eastern Maine, the protection of consumer information was of paramount importance. In our systems, consumers use a personal password and username, and they also have to come in and show a valid ID to say that this is really the person.
We had initially in the first rollout with Winona a personal digital certificate on top of that, and we found that consumers did not understand that additional level of security. They got encryption; they didn't get, why do I have to go through this next step, so we took that out in a later phase of the project, and have not had issues with privacy concerns. But all communications are encrypted messages rather than simple e-mail.
The security standards are extremely necessary to make sure that the information shared remains safe. Security ascertainment, markup language will allow different systems to exchange standards based tokens, identity tokens, enabling one-time sign-on to become a reality. That single sign-on is very crucial. The Liberty Alliance launched the first version of its plans, which defines how companies can deliver the federated identity management capabilities. Both Microsoft and Sun have agreed to support this language within their web services and security plans, and that is very good for the rest of us, because if we get some of the big players doing that, it makes it simpler for us to make that happen.
The SAML security language defines three ways that consumer health information can be secured through a web browser which involves a typical scenario of a consumer visiting a website, and then having his or her identity information passed from a second site in the same session. That is going to be the most common one deployed, especially at first.
Then there is another type of security, another way it can be used, which supports remote authorization. So a site could ask another site to authenticate a user and maybe get some information about it. So I have asked for a new drug, and it will go to my personal health record, the site that has been asked to get the new drug would go to the personal health record and say, find any allergies to drugs and find that, yes, they are allergic to penicillin, I can't prescribe that. So that enables some smart communications.
Then the third scenario involves authenticating web services. So for instance, if we had a giant database of personal health records and a public health surveillance system, that information being shared, it would say can this other database actually receive the information, are they authorized to receive the information from the personal health record database. All of those will be very good things for maintaining security.
A national health identifier -- we have talked about this before -- that would ease the use. We have a master person index within Cerner which we use today, and we have had to do this even in our very simple deployments, because we are giving lab results as well as clinical information, so we have a disparity of systems in even these very small projects that we have begun. So we have had to use that capability already. So that is going to be a necessary component to all current projects. A single identifier would really ease the tedious process, manual process of authenticating an individual, but we realize that that is a dream. But we can always hope.
One of the important pieces of this is, if it was adopted with a national digital signature for consumers like we do on the physician side, physicians would have complete confidence in the validity of the sender of the health information. We found that the initiatives done by the AMA, where there is a database that says this is truly a physician and there is a standard digital signature infrastructure, so you know the physician who was sending this information is the right one, would be a good thing to have. We think that consumers would actually sign up for that type of thing, to enable communications, despite where they are.
From a communications standpoint, the Internet provides ability for consumers and providers to access the personal health record from anywhere at any time. And people typically use e-mail. As I stated before, that is not going to be adequate to control personal health information. So messages containing person-specific health information ideally should have a digital signature that encrypts the message, as opposed to having to send it that way, because only the intended person can read the digitally signed messages.
The messages should also be structured to enable the information contained in the message to be saved discreetly rather than in a text message. So we have templated our messages so that you can send discreet results, you have XML tagging. The HL-7 version three would provide some good guidelines to help make that happen. We are very supportive of moving in that direction, so that the data can be used and not just stored as a document.
As standards are developed, many health care technology suppliers are going to fight some of these standards. They are going to fight for ones that support their methodologies so that they can reduce their implementation costs and deliver solutions to market as quickly as possible. It is much, much faster to develop a proprietary standard than to use an industry standard.
The standards development to date has been very slow. We have been waiting for a long time for some of the final decisions on HL-7. We know that they are very difficult to do, but I agree with the comments made earlier that there is not a compelling business event for people to move to a standard. It is very good for the health system as a whole, but most organizations are going to focus on solving their own problem. So because of that, the greater good suffers.
We believe that incentives can be provided from both the public and the private sector to fund a broad industry initiative to develop standards. The coalition would need to be large enough to raise all the related concerns of this, and interoperability has obvious disadvantages for some suppliers, and differing technology platforms may impede a single standard that serves all technologies, so we have to be cognizant of that.
HHS or nonprofit foundations could work to insure compliance in support of the coalition. In addition, it is critical that the neutral development environment be used to insure common interaction such as XML.
Existing regulations such as the HIPAA mandate provide some important building blocks for standard code sets and paperwork reduction. The requirement of the designated record set to follow electronically formatted standard XML schema, standard vocabulary and be digitally signed by the health care providers would be a significant first step. We are very supportive of moving in that direction. It should also be used as a starting point to standardize additional code sets and vocabularies.
Standards development is a critical component in allowing consumers to manage their own health, but solving the broader challenges surrounding the cross-organizational sharing of the clinical information and getting people to actually do that will yield the benefit of having personal health records be truly all-inclusive and connected.
Thank you very much.
DR. LUMPKIN: Thank you. Questions? Jeff.
MR. BLAIR: I am still thinking through my question.
DR. LUMPKIN: Okay. I see a couple of other folks, but let me just ask a question. Winona, Minnesota, isn't that where Winona Rider comes from?
MS. BINGMAN: Yes, actually. They don't promote shoplifting, though.
DR. LUMPKIN: I missed that one.
MR. BLAIR: She said they don't promote shoplifting.
DR. LUMPKIN: I see. That is why she left town. Do you have something you can send us, an evaluation or a writeup on that? That seems like a very fascinating project that you describe. I think we would all appreciate having something.
MS. BINGMAN: Absolutely. We can give you current status and plans for next steps. There are a lot of learnings and findings in doing this, and you discover barriers. Physician adoption and consumer adoption, those two, that is the chicken and egg of the personal health record, because consumers will participate if their physicians are, physicians will participate if all their patients are. So how do you get them both to do it? We found that physician driven adoption efforts work better.
DR. LUMPKIN: If you happen to remember us from time to time, not only what goes on now, but as time goes on in that particular project, we would appreciate periodic updates.
MS. BINGMAN: Okay, happily.
DR. LUMPKIN: Thank you. We are going to go with Clem and then Mike and then Jeff and then Kepa.
DR. MC DONALD: I have two questions. You went from certificate based, and that was a certificate on the machine and the home machine?
MS. BINGMAN: Yes.
DR. MC DONALD: To standard password. You used an SSL as your --
MS. BINGMAN: Yes, we still do.
DR. MC DONALD: A lot of people have done that. What kind of passwords did you give out, and how hard were they?
MS. BINGMAN: The initial registration was painful, so we had four challenge questions. So there were two challenge questions on your password, four challenge questions on your digital certificate, so it was pretty cumbersome. We had lots of consumers complain about, I can't come up with enough questions. So we had to say, try this one.
DR. MC DONALD: What is the percentage adoption by the patients? You mentioned that patients had to sign up. Was that a barrier? Did thousands of them sign up or millions?
DR. EYTAN: Yes, we are looking at how to overhaul that right now. It is a barrier, especially for employers. They don't want their workers to leave their site to come sign up. About ten percent of eligible enrolled members are signed up at the basic level and currently two percent for the enhanced suite of services, so about 10,000 people are using it.
DR. MC DONALD: Do they then use it and you can verify that?
DR. EYTAN: The best guess I can throw out now off the top of my head is about 20 percent per 100 ID-verified enrollees use the system each month. What we found is, it basically parallels the use of health care. It is not the overwhelming flood of messages that people thought were going to happen.
MS. BINGMAN: We have had the same kind of barrier. But so people could sign up at the pharmacy, sign up at the physician's office, we gave them a number. Then at health fairs we did set up kiosks and things like that, and had employer meetings as well, so people could sign up then. Did some things with the schools. So there were some big initiatives to get adoption. We have got about ten percent of the community signed up today, and there is about a third repeat users on a consistent basis. We did a migration from our first version to the second version, and first did all the people who had accessed their record over the six months, and three days later did the rest. We had over ten people call to say what happened to my record, which is I think true of how health care is accessed; I only need it when I need it, I don't need to do it every day.
DR. EYTAN: Also, we get a lot of comments from patients saying, thank you very much for doing this ID verification, I really appreciate that you took the extra step. So it has come from both ways.
DR. LUMPKIN: Mike?
DR. FITZMAURICE: Two questions of Kathy Bingman. One of them is, is your identification of people common across installations? That is, can you identify the same patient across two different Cerner systems?
MS. BINGMAN: We use the master person index to do it.
DR. FITZMAURICE: Across all your installations?
MS. BINGMAN: Yes. Right now, we have all of our installations for our IQ health solutions in a single database, so it is across everything. So they could truly go to another area and participate there as well.
DR. FITZMAURICE: Secondly, you had a good couple of paragraphs on incentives to use standards, and how sometimes it is not in a company's interest to go to a common standard, but if everybody else, then you get drug into it. That is like a business incentive.
One of the standards commonly used for laboratories is the LOINC system. I wonder, if Cerner uses LOINC, does it participate in the development of LOINC, and what are the business reasons for doing it or for not doing it?
MS. BINGMAN: We participate heavily in any of the standards setting, because we think that is going to help us. We are very rarely the only system in a health organization, so we have had to interface with the world, basically. So we are very supportive of that, and have that as our backbone. I know we do LOINC.
DR. FITZMAURICE: Thank you.
DR. LUMPKIN: Jeff?
MR. BLAIR: Kathy, could you help me a little bit, by doing a little bit deeper with your interest in XML? There are several different XML standards generally. XML is more generic than just a health care standard.
MS. BINGMAN: Sure.
MR. BLAIR: So number one, what are the application areas where you are interested in XML? Number two, what specific health standards that use XML do you feel NCVHS should consider, in terms of recognizing for standardization? Let me just leave it at that.
MS. BINGMAN: I think certainly the health vocabularies get in some standard there, and saying that those should be presented in XML format would very beneficial.
I am not technical, I am over the IQ health piece and I am not the technical person. I can certainly get you all the information you would need on how we are using the XML standards today. All of what we have written with IQ health solutions use XML.
DR. LUMPKIN: Kepa?
DR. ZUBELDIA: I want to go back to the PKI question on authentication. One thing that struck me, I have never been to Winona, Minnesota, but I suspect that with 70 percent Internet connection it is not a typical inner city type of environment. So probably the educational level of the residents is a little bit higher than that.
It is kind of surprising that after trying certificates, they were rejected and withdrawn from the project, and you go back to the traditional ID and password. I can understand that, I have been through that, too. But then in your recommendations, you talk about a digital certificate system --
MS. BINGMAN: Signature.
DR. ZUBELDIA: A digital signature that will provide encryption. Well, same thing; if you have to have a digital signature, you have to have digital certificates in order to have the signatures and the encryption. Is that for consumers, or are you just talking about providers?
MS. BINGMAN: Ideally we would have the same kind of thing they have done on the physician side for consumers, and let people opt in for that. So if you had a central database like we do for providers that, yes, I have authenticated that this is me, this is my digital signature, then it is going to be easy.
DR. ZUBELDIA: But didn't you try that and have to take it out?
MS. BINGMAN: It was a personal digital certificate tied to the IP address of the PC and allowing for roaming based with security questions. So if somebody accessed the same system from a different PC with a different IP address, they would have to answer the roaming questions to make that happen. So it was done by archive systems, but we could do a smart card, you could do a thumbprint, you could do a retinal scan, any of those additional levels of security.
DR. LUMPKIN: So I would be in trouble because I used DSL, and it is always a random IP address that is assigned.
MS. BINGMAN: You would have to answer your challenge questions all the time.
DR. ZUBELDIA: Even if you used it from home, you would have to answer them all the time.
DR. LUMPKIN: Yes, with DSL.
MS. BINGMAN: Right. But still, even without that extra layer of security, people still have to show a valid ID to say that I could call myself Mickey Mouse in the personal health system, but they need to tie Mickey Mouse to Kathryn Bingman to the medical record.
DR. FITZMAURICE: Can I follow up on that? Did you drop it because of the expense, because the value to the consumer wasn't worth what it cost to do it?
MS. BINGMAN: No, it was not an expense. We got many, many questions, like, why do I have to do this extra thing. The capability still exists, so if a client said we want to do it that way, we could.
DR. FITZMAURICE: They just felt that it wasn't worth their effort?
MS. BINGMAN: Right. They felt safe. We haven't had issues surrounding security come up. Privacy, yes, security, no.
DR. LUMPKIN: Mary Jo?
DR. DEERING: I get to ask my take-home questions. These are for you to send back to us. Actually, the first question, if you were here earlier, I think both of you have already addressed in your testimony. The first question I have asked people to think about and get back to us is, and I am asking this as a representative of HHS, given the goal which you are already pursuing of integrating personal health information with the clinical record, and you may not have referenced links to the public health system and other population health uses, but given that goal, and from where you particularly stand, and the issues and interests that you represent, what would be the single top priorities for the Secretary or for federal action?
I think you have sort of mentioned them, but if you want to take the liberty of elaborating on those, this is your time to tell the government what you think it should do.
Then the other take-home question -- and this can be very burdensome, which is why I leave it very open-ended -- gets to the costs, the ROI issues, et cetera. What kind of financial information or cost information or cost-benefit information do you have fairly readily available that you would be willing to share with people who are advising the Secretary to help him understand what the economic parameters of all of this are.
Again, I could try and frame a very precise question for you, but you might not have that information, and I don't want to be unduly burdensome. But whatever you think would be helpful for him to understand what this is all about from the economic point of view.
MS. BINGMAN: Okay.
DR. LUMPKIN: If I can speak to that --
DR. DEERING: And you can e-mail it, by the way.
DR. EYTAN: We get that question asked a lot, what is the incentive to do this. I think our incentive structure is such that whatever we can do to keep patients healthy is worth the investment. I think that our leadership feels that it is a little bit premature to do that kind of an analysis right now, because we are just trying to get critical mass. If we were do that analysis right now, it would not be very informative.
I think the analysis
for return on investment for CIS is a very reasonable thing to do, because that has been done a lot, but you probably won't be seeing any cost-benefit from us for a little while. You will see patient satisfaction and provider satisfaction.
DR. DEERING: That is very useful, because as I think is the case in Kaiser Permanente and DoD, a lot of the people who are doing it are saying, we have got to do it. We are going to go ahead and do it. It costs a lot right now, but -- and I think that hearing that over and over again from not only the thought leaders, but the practicing leaders across health is an important message for the Secretary, if indeed it is true, because otherwise all we are throwing up there is a barrier to the adoption of this stuff. Nobody is going to do it unless you can prove the cost effectiveness of it.
Well, it ain't true if the big folks are doing it, sort of on faith at this point, but testing as they go.
MS. BINGMAN: We found that the ones that are willing to invest in this in the early stages of this, in visionary projects, are the ones that control the health economy. So it works well in communities, it works well when you have a state outreach. It certainly fits in with all of the health systems' mission statements. If you are not-for-profit, this fits in very well.
But the proven ROI gets in some of the self service aspects that were talked about earlier. That is very different than the true PHR concept, allowing somebody to do their own scheduling, allowing somebody to do their own refills and renewals. That is all really great stuff, and we will get consumers to use it as well as making for good ROI on the clinical side. But it is not PHR as a health system.
MR. BLAIR: Could I ask Mary Jo, could I broaden your request a little bit? Here is the way I would broaden it, as divided into two parts. One is, I think it would be helpful if we received information that reflects maybe the standards that you are using. I think that those are the ones that very often vendors will put forward, because that way, they don't have to worry about losing the investment they have already made in developing application systems based on a particular standard. Very often, the response doesn't go past that.
Here is the second part of my friendly amendment. I ask you to go past that, and also indicate those application areas where you failed to get a satisfactory business case because of lack of a national standard. Those are the standards where we could work as a catalyst to facilitate and enable either more clinically specific standards or new standards or new business functions or new applications or new markets, okay? Those are the ones that I think are at least as important as the earlier ones that protect the investment you have already made.
MS. BINGMAN: Okay.
MR. BLAIR: Mary Jo, does that fit in with --
DR. DEERING: Thank you, Jeff.
DR. LUMPKIN: Clem?
DR. MC DONALD: I wanted to emphasize both the difficulty of signing patients up and the advantage of having that already done, either through a national number or something. It is really almost impossible. When we asked earlier why didn't Marc do the patient record, we can imagine getting 3,000 physicians in Indianapolis working with us. We can't even conceive going out as a research project to 1.2 million people and getting them hooked up.
So this thing I think is really important, if one could come up with something that achieved either of those goals, a patient identifier, not in disguise, but encrypted. But some way that there is a pre-trusted identifier system that you can have someone log into your hospital, pull out data, and not go to jail tomorrow because someone else was the wrong person and pulled it out. So it is a tremendous barrier. I think that is a great idea.
The other is the part about these certificates. When you put them on the machine, there is a triple question. Microsoft's operating system at least until IBX is not secure. So someone can steal your certificate, so you always have these extra passwords, just to verify that you are the one using the certificate, the right person. So these layer of passwords are killing it. People don't know which is what and they look the same. That is the little things that really block these things.
DR. LUMPKIN: We all just need to have embedded chips that we can put on a meter.
MS. BINGMAN: Bar code, tattoo.
DR. LUMPKIN: I would like to thank our final panel. All the panels today have been very thought provoking, and have really helped us move forward in some of our thoughts related to furtherance of the NHII, and perhaps tossed a glove to the Standards and Security Subcommittee. But we will talk about that later.
We will just need to make sure that we schedule some time for the work group at the next meeting, so we have a chance to digest this for a little time, and then talk about where we are going to go from here. This has been very helpful.
MS. BINGMAN: Thank you very much.
DR. LUMPKIN: So thank you and the other panelists. I think unless we have any other items to discuss, we have run through our agenda. Since Jeff has declared a conflict, we can't take any votes on any matters, which is good, because we didn't have any matters to take votes on, anyway.
So I think we stand adjourned. Thank you.
(Whereupon, the meeting was adjourned at 4:03 p.m.)