| up a level Goals of JOSMC Subscribe post article search Editorial Policy Editorial Board Contact admin main |
from the dept. A Master's thesis on a proposal for Open Source National Health Information Network by Corazon Valdes, MPH, PA-C can be found here: http://josmc.org/PDFs/OSNHINProposal.pdf. Abstract: The United States is developing a national health information program named the nationwide health information network (NHIN). The aim of the NHIN is to improve the quality and efficiency of healthcare through nationwide adoption of health information technology (IT). This paper will demonstrate that free and open source software (FOSS) is a viable model for achieving the goals of a NHIN. To understand the NHIN and FOSS, a review of the literature concerning the public health significance of a NHIN, trends in health IT adoption, past and current health IT policy, barriers to adoption of health IT, and development of FOSS will be undertaken. A spectrum of three possible IT development models for the NHIN will be compared and contrasted. These models are pure proprietary, mixed FOSS/proprietary and pure FOSS. These exercises show that FOSS is a viable model for addressing the major barriers to achieving a NHIN infrastructure...' THE NATIONWIDE HEALTH INFORMATION NETWORK: A PROPOSAL FOR FREE AND OPEN SOURCE SOFTWARE By CORAZON MARTIN VALDES, B.S., B.S. APPROVED: CARL HACKER, PH.D., J.D. KATHY KLOS, PH.D. Copyright by Corazon M. Valdes 2006 DEDICATION For my children Luis and Thomas Valdes THE NATIONWIDE HEALTH INFORMATION NETWORK: A PROPOSAL FOR FREE AND OPEN SOURCE SOFTWARE By CORAZON MARTIN VALDES, B.S., B.S. THESIS Presented to the Faculty of The University of Texas Health Science Center at Houston School of Public Health in Partial Fulfillment of the Requirements for the Degree of MASTER OF PUBLIC HEALTH THE UNIVERSITY OF TEXAS HEALTH SCIENCE CENTER AT HOUSTON SCHOOL OF PUBLIC HEALTH Houston, Texas May, 2006 ACKNOWLEDGEMENTS I began my education in Public Health in January 2001. I was pregnant with my first child. Five years and two children later, I completed my Master’s in Public Health from the University Of Texas School Of Public Health. My interest in Public Health emerged after a medical mission trip to Guatemala where I served as a Physician Assistant. My memories of smiling Mayan faces created in me the desire to do more for people in need, therefore, I entered the International Health module. Over time, the excitement, demand, and newness of family life refocused my energies to within our borders and I switched to Health Services Organization. Health Services was a perfect fit for my interest in policy development. My desire to shape public policy emerged in 2004, when President Bush proposed national electronic health records for all Americans. This announcement enticed me to work with my husband, Ignacio Valdes, a physician and computer scientist who has wanted to revolutionize health information systems since we met in 1997. It took seven years for me to finally understand Ignacio’s ideas of software freedoms in medicine. Not only have I become a believer but I can finally comprehend his website www.LinuxMedNews.com. We hope to change health care with computerized medicine for the benefit of all. Thank you to my family and friends who have supported me during my education. Several deserve special mention – especially the people who played with my preschool age boys so I could study. Thank you to Grandma Nelie and Grandpa Steve Steficek, Ignacio, and the Partridges (Cathie, Mike, Will and Pat) for opening up many spots in your schedules. Also, thank you Lala and Lolo Valdes (Luis Valdes, MD and Thusnelda Valdes, PhD) for the good food and the marathon play dates. Thank you to Atty. Grandpa Beaumont for my persevering nature, and a desire to aim high. I will have warm memories of the UT School of Public Health which has always been a friendly place, you can’t walk in their without breaking a smile. I want to thank several people at the school for their guidance on my thesis. Thank you to Rebecca Novak in the proposal office for her suggestions. Also, thank you to my supervising professor Dr. Carl Hacker, whose love of American history, numerous talents, and encyclopedic knowledge Thesis submitted to the M.P.H. Committee on March 24, 2006. v never cease to amaze or entertain me. Some of his memorable works are: the Houston marathon, the school rooftop garden, and his school-wide presentation on the Constitution in period attire (while the rest of Houston was buying plywood to protect their homes from the approaching Category 5 Hurricane Rita). A special thank you also to my committee member, Dr. Kathy Klos, whose energy, steady flow of ideas, and organizational skills brought my thesis together. Thank you to my God for the gift of the Sermon on the Mount and the prayer of St. Teresa of Avila: Christ has no body now on earth but yours. No hands but yours. No feet but yours. Yours are the eyes through which must look out Christ’s compassion on the world. Yours are the feet with which He is to go about doing good. Yours are the hands with which He is to bless people now. Thesis submitted to the M.P.H. Committee on March 24, 2006. vi THE NATIONWIDE HEALTH INFORMATION NETWORK: A PROPOSAL FOR FREE AND OPEN SOURCE SOFTWARE Corazon M. Valdes, B.S., B.S., M.P.H The University of Texas Health Science Center at Houston School of Public Health, 2006 Supervising Professor: Carl Hacker Abstract: The United States is developing a national health information program named the nationwide health information network (NHIN). The aim of the NHIN is to improve the quality and efficiency of healthcare through nationwide adoption of health information technology (IT). This paper will demonstrate that free and open source software (FOSS) is a viable model for achieving the goals of a NHIN. To understand the NHIN and FOSS, a review of the literature concerning the public health significance of a NHIN, trends in health IT adoption, past and current health IT policy, barriers to adoption of health IT, and development of FOSS will be undertaken. A spectrum of three possible IT development models for the NHIN will be compared and contrasted. These models are pure proprietary, mixed FOSS/proprietary and pure FOSS. These exercises show that FOSS is a viable model for addressing the major barriers to achieving a NHIN infrastructure. TABLE OF CONTENTS LIST OF TABLES...................................................................................................................ix LIST OF FIGURES .................................................................................................................. x INTRODUCTION .................................................................................................................... 1 METHODS ............................................................................................................................... 2 REVIEW OF LITERATURE ................................................................................................... 2 The Public Health Significance of an NHIN ................................................................ 4 Medical Errors.......................................................................................................... 4 Cost Savings............................................................................................................. 5 Surveillance.............................................................................................................. 5 Trends in Health IT Adoption....................................................................................... 6 Past IT policy ................................................................................................................ 8 Current health IT policy................................................................................................ 9 Barriers to adoption of health IT................................................................................. 10 Free and Open Source Software Development........................................................... 12 Definition of FOSS ................................................................................................ 13 Development process of FOSS .............................................................................. 14 DISCUSSION: THREE NHIN MODELS.............................................................................. 16 Pure proprietary...................................................................................................... 17 Mixed model – FOSS/proprietary.......................................................................... 19 Pure FOSS.............................................................................................................. 22 CONCLUSION...................................................................................................................... 28 LITERATURE CITED ........................................................................................................... 30 VITA...................................................................................................................................... 35 viii LIST OF TABLES Table 1: FOSS benefits and their capacity to address barriers to health IT adoption........23 Table 2: Models compared by their capacity to achieve each of five health IT qualities..26 Table 3: Models compared according to their capacity to address barriers to adoption....27 ix LIST OF FIGURES Figure 1: Commercial software running on Linux. ...........................................................20 Figure 2: Enhancing FOSS with proprietary software.......................................................21 Figure 3: Commercial software managed with a dual-license...........................................22 x INTRODUCTION Meaningful computerization of medicine to improve the efficiency and quality of healthcare has become a goal for the nation, yet progress has been slow1. To accelerate the process of creating nationwide health information availability, the United States is developing a national health information program named the nationwide health information network (NHIN)2. Both the public and private sector are studying business models, IT infrastructure, and health IT adoption issues to determine what aspects will facilitate a viable NHIN. This paper aims to demonstrate that free and open source software (FOSS) is a viable model for achieving implementation of a NHIN. Free and open source software (FOSS) is both a process of software development and a method of licensing that can be a viable model for creation of the NHIN. However, a close examination of the literature focusing on the public health significance of a NHIN, trends in health IT adoption, past and current health IT policy, barriers to adoption of health IT, and development of FOSS is crucial to understanding how FOSS will address the difficulties of creating a NHIN. Three broad models of current IT development will be examined for their suitability to address the barriers to adoption of a NHIN: pure proprietary, mixed FOSS/proprietary, and pure FOSS. The strengths and weaknesses of each model for creation of a NHIN will be elaborated. 1 METHODS Articles published in peer-reviewed journals were selected through the UT School of Public Health library online databases such as LexisNexis, PubMed, and Academic Search Premier. These databases were searched using the following words: computer information systems, electronic health records, national health information network, health information technology policy, open source software, barriers to electronic health records, economics of electronic health records, and health information technology interoperability. There are few journal articles concerning FOSS in the health care field; therefore, two books and one report written about FOSS were also reviewed. This literature was chosen because they were often referred to by the FOSS community as a respected source of information. Additionally, an internet search using the Google search engine with key words ‘economics of open source software’ confirmed these publications. The literature reviewed was the following: • The Cathedral and the Bazaar, by Eric Raymond3 • The business and economics of Linux and open source, by Martin Fink4 • The business case study of open source software, by Carolyn Kenwood5 Information was also taken from the internet using the search engine Google. The internet information was evaluated based on its source. Information found on websites published by health care organizations, FOSS organizations, government magazines, IT magazines, and highly ranked websites as determined by the Google PageRank™ search algorithm were considered reliable. Official government websites published by the U.S. Department of Health and Human Services and the Centers for Disease Control and Prevention were also accessed to determine key issues for the development of a NHIN. REVIEW OF LITERATURE The nationwide health information network (NHIN), is a program designed to improve the quality and efficiency of healthcare through nationwide adoption of health information technology. Health information technology is defined as information processing 2 involving both computer hardware and software to address the storage, retrieval, sharing, and use of health care information for communication and decision-making6. Examples of health IT include telemedicine (where the doctor communicates with the patient through television), Internet use (email communications between provider and patient, or health information web sites), and electronic health records (EHR). Scholarly literature, federal government policy, and private sector leadership have referred to health IT as an effective tool that will improve the quality of medicine, reduce costs, and facilitate public health surveillance7,8,9 . These are the benefits of a NHIN. The purpose of this literature review is to describe the public health significance of a NHIN, trends in health IT adoption, past and current health IT policy, barriers to adoption of health IT, and development of free and open source software. 3 The Public Health Significance of an NHIN Public health is a discipline that aims to advance the health of the population. In public health, the community is the patient10 . The Institute of Medicine report, The Future of Public Health, describes three core competencies for a public health professional: assessment, policy development, and assurance11. Information is the foundation for these three activities, and the use of computers in health information management can advance the work of public health10 . Realizing the benefits of information technology, public health professionals have embraced health IT increasingly over the last decade10. The field of public health informatics (which studies the implementation of IT in public health information management) was begun by a 1995 partnership of the Centers for Disease Control and Prevention (CDC) and the University of Washington School of Public Health10. The field of public health is adopting information technology and moving towards a nationwide health IT program. Important facets of the public health significance of a NHIN include the role of health IT in medical errors, health care costs, and public health surveillance. Medical Errors Public cognizance of medical errors materialized largely due to the Institute of Medicine (IOM) report, To Err is Human, which reported that about 98,000 Americans die annually as a result of medical errors12 . Health IT has been found to reduce the number of medical errors. David Bates consistently published articles on the effect of computer systems on medical errors7,13,14,15 . Bates’ study in 1998 on physician computerized order entry with decision support found a 55% decrease in serious medication errors14 . RS Evans, also studying the effects of health IT on the quality of health care, found that decision support improved quality of patient care through lowered drug dosages, decreased hospital stay, and fewer adverse drug events16,17 . This foundation of research has strengthened the role of computers in medicine. 4 A limitation of these studies is their focus on large hospitals. Gaps in the literature include studies on systems interoperability, and FOSS applications. Additionally, some researchers found an unexpected increase in mortality after implementation of a computerized physician order entry system18 . However, response articles have detailed the flaws of the computer implementation (for instance, inadequate wireless bandwidth and insufficient development) which may have lead to the increase in mortality19 . For this reason, it will be important that computerized health information applications undergo extensive development (which includes testing, adaptability, and standardization). This type of development can happen with a FOSS infrastructure. Cost Savings In the 1990’s research surfaced studying the effects of specific IT applications on hospital cost savings. A drug dosage alert system has been found to be an effective aid in treatment of hospitalized patients with renal insufficiency20 . Over the 2 month study, 74% of drug dosages were changed because of the alert system, resulting in a drug acquisition cost saving of $7082. A computerized adverse drug event surveillance and alert system was found to reduce hospital costs by about $7000 per affected patient due to reduced length of hospitalization16 . Computerized physician order entry was found to lower costs as well. An inpatient order application connected to electronic medical records reduced hospital charges by 12.7% through reduced length of stay, lab tests, and medications21 . This reduction translated to cost savings of more than $3 million annually for this public hospital. The role of health IT in health care costs is significant. Surveillance Public health and public health surveillance rely on obtaining accurate information in a timely manner10 . Public health is driven by information which is collected through surveillance. Public health surveillance is defined as the systematic collection and 5 interpretation of health-related data for use in planning, implementation, and evaluation of public health practice10 . Lessons learned from recent events concerning bioterrorism, emerging infectious diseases, and natural disasters have launched policymakers’ efforts to improve the current surveillance system. The current national surveillance arrangement is fragmented and prone to error. The CDC uses 120 surveillance systems of which 71 are tied into state and local health departments10 . Information is collected through interviews, medical record review, and vital records. Additionally, data is gathered from a variety of sources such as laboratory records, physician reports, administrative data, and hospital discharge reports. These multiple data transfer points create a surveillance system that is resource intensive and vertically integrated. The multiple areas of redundant data entry also create a higher possibility for errors 10 . The federal government is motivated to improve the flow of information. They have proposed a public health surveillance network named the Public Health Information Network (PHIN) that will function on the framework of a NHIN22 . The goal of the PHIN is to advance interoperable information systems in the many organizations that participate in public health23 . The PHIN advances the nationwide health IT program by reducing the burden of manual health information reporting through the automated use of electronic clinical data. The goals of the PHIN are similar to the NHIN with a framework built on standards and interoperability. Additionally, a PHIN can work through information channels created by a fully functioning NHIN. The resulting efficiency will optimize collection of clinically relevant data for public health surveillance. A strong business model should combine both projects to conserve resources and this model should be built on an FOSS platform which will be described later. Trends in Health IT Adoption A PubMed database search using keywords “computer information systems” reveals several trends in health IT systems. In the 1990’s, an international presence dominated. France, Germany, Russia, Italy, Australia, and Scotland lead the way, publishing multiple articles on global efforts in computerized patient information. American interest in health IT 6 systems followed but remained short-sighted, focusing on implementation of computers in the pharmaceutical industry, radiology field, and administration of paperwork24 . Most of the articles in this time do not reach beyond applauding computer usage in medicine25 . Towards the end of 1991 and into 1992, U.S. interest in electronic health records surfaced. The scientific community of the early 1990s called it the CPR (computerized patient record), today it’s the EMR or EHR (electronic medical record or electronic health record). The CPR gained popularity in literature over the years (despite its ominous acronym). These beginnings are evident in the Journal of American Medical Records Association article “The computerized medical record: an invitation to dialogue”. Described is a future where the control of health information is one of the “greatest medical advances of all history”25 . Starting in 1994 the first signs of frustration are seen in a paper titled “The elusive paperless medical record”26 . The acronym “CPR” is dropped and replaced with “EMR/EHR” and it was a foreshadowing of the difficulties of health IT implementation to come. With early enthusiasm dampened by an inability to implement health IT, a much needed assistance to the process was given by the Institute of Medicine in 2001. The Institute of Medicine stressed the need for safety systems and demonstrated that poorly designed systems, rather than human error, were largely responsible for medical errors. The IOM’s two reports, To Err is Human and Crossing the Quality Chasm, were important in helping stakeholders realize the promise of using health IT to address the quality problems of U.S. healthcare12,27 . The reports were of paramount importance in rejuvenating efforts to adopt health IT. The IOM reports did an extensive review of literature on the role of health IT in the quality of health care, and concluded that “IT must play a central role in the redesign of the health care system if a substantial improvement in health care quality is to be achieved.” 7 Past IT policy During the early 1990s, the federal government began to push medical information networks. In the proposed Medical and Health Insurance Information Reform Act of 1992, the Bush administration asked Congress to give the secretary of HHS authority to mandate formats for electronic data28,29 . Part A of this Act asked for development of information systems that provide quality and outcomes data with respect to health insurance plans29 . The purpose was to assure the availability of comparative information to purchasers of health care, thus empowering consumers to compare the value of health plans. The focus of the policy was to establish electronic data formats in government transactions and, through quality data, to help consumers chose among health plans. These efforts were continued into the Clinton presidencies. During 1993, the Clinton administration proposed extensive health care reform, which included computerization of medical information. The Health Security Act of 1993 supported health IT with the following proposals: health quality management through outcomes measurement resulting from electronic data, development of a health security card, and development of a national health information system30 . Other initiatives in 1993 included the National Information Infrastructure Act and the National Performance Review which established the Department of Defense health care system as a testing ground for electronic patient records31,32 . The political climate, interest group efforts, and American anxiety surrounding privacy issues defeated Clinton’s health care reform plan and greatly hindered the move towards computerized patient information. In 1996, the Health Insurance Portability and Accountability Act (HIPAA) was created to improve administrative efficiency in health care as well as to increase patient privacy protections33 . HIPAA aims to reduce administrative paperwork by encouraging the development of health information networks through the adoption of national standards for electronic health care transactions34 . October 16, 2003 was the deadline for compliance with HIPAA’s electronic transaction and code sets provisions34 . 8 HIPAA resulted in a shift in attitude that was more receptive to health IT35 . The health care system is still adjusting to HIPAA regulations. Shortliffe writes, “passage of HIPAA and the subsequent rulings regarding data transmission, patient privacy, and systems security have forced health care organizations of all sizes to recognize the importance of data security and to seek computer-based solutions to problems that defy solution in a paper-based world”36 . HIPAA has raised the demands for information, and thus the appeal of electronic information as a solution to the burden of paper work35 . These early efforts in health IT policy development have directed government efforts to propose a program for nationwide health IT. Current health IT policy The U.S. government is motivated to implement a NHIN for a variety of reasons. First, the government is America’s largest health insurance provider and hopes to see cost savings through improved quality of health care and reduced administrative paperwork costs33 . Secondly, increased public awareness of medical errors, along with research confirming that health IT can improve the quality of medicine, has made implementation of the NHIN a public health issue10,37 . Third, a NHIN framework will enable a more effective response to threats from bioterrorism, emerging diseases, and natural disasters through improved public health surveillance and computerized exchange of information10 . To illustrate the federal government’s activity in electronic health information policy, a search of Congressional records of the 109th Congress (2005-2006) was performed and revealed 31 bills containing the words “health information technology”, with 6 bills containing that word combination in the title. For perspective, the same search of the 106th Congress (1999-2000) had no articles with that exact word combination38 . This trend demonstrates the federal government support of health IT and has culminated in Executive Order #13335 that calls for nationwide electronic health information. Executive Order #13335 was signed April 27, 2004 by President George W. Bush8. The order called for a plan to manage all U.S. patient medical information through 9 interoperable computer systems. This plan was named the Nationwide Health Information Network (NHIN). The NHIN is described as a network that will “link disparate health care information systems together to allow patients, physicians, hospitals, public health agencies and other authorized users across the nation to share clinical information in real-time”22 . The expected benefits of such a network are improved quality of health care and greater efficiency of patient information management. The Executive Order goal is to provide leadership for the development and implementation of a nationwide interoperable health IT infrastructure for the purpose of improving the quality and efficiency of health care8. In his State of the Union Address, January 31, 2006, President Bush stated to help control costs and reduce medical errors, wider use of electronic records and other health information technology will be undertaken39 . Federal government efforts are aligned to achieve the nationwide health IT program. Barriers to adoption of health IT The Office of the National Coordinator for Health Information Technology (ONCHIT), which is the federal government office charged with developing a national health IT program, in concordance with research findings of the scientific community has identified barriers to adoption of the NHIN40-45 . It is important to understand these barriers when designing an interoperable health IT application since a viable implementation must address these issues. Barriers identified by ONCHIT that will be focused on are: adoption difficulties, high failure rate for health IT implementation, and limited capacity for interoperability. Data security will also be discussed, but was not identified by ONCHIT as a barrier. The literature often refers to adoption difficulties as the ‘adoption gap’, meaning that health care providers in small offices have a lower rate of health IT usage then larger offices. The rate limiting factor for nationwide health IT adoption is implementation in the primary care small group office setting7,40,46 . More then two-thirds of U.S. physicians practice in this setting, thus collecting a large amount of patient medical histories40,47 . The diffusion of a 10 national IT system will depend on the adoption rate of this group40,47 . Studies show that about 18% of practices with 10 or fewer physicians use an EHR, while 57% of offices with 50 or more physicians use an EHR40,46 . What drives this adoption gap? The financial outlook is dismal for the small office. They face challenging times as reported by Bates, “expenses outpaced the increase in physician compensation in primary care for three straight years”46 . Compensation issues hold back the physician that can’t afford business down time for implementation of an EHR which may soon be obsolete. Miller provides a break down of the costs a small group practice may face. Initial costs (software training, hardware, lost revenues) were averaged out to $43,826 per full-timeequivalent provider in his study of 14 solo/small group practices47 . The financial threat experienced by physicians is also seen in Valdes’ study on a American Academy of Family Physicians survey which found that 81% of this group reported interest in EHR’s; however, 61% reported cost as a major reason for not purchasing it43 . Software development for healthcare is slow, expensive and difficult. As well, the speed of technological advance often renders software programs obsolete. All of these difficulties lead to a high failure rate of health IT software implementations. Literature confirms that about 70% of all IT-related projects fail to meet their objectives48 . The Standish Group study in 1994, found that 31.1% of projects get canceled before they ever get completed49 . A follow-up report in 2004 found that 29% of projects succeeded, 53% were challenged (late, over budget, and/or less then required features), and 18% failed (cancelled prior to completion)50 . IT failure is largely due to the inability of the product to meet the unique work demands of a variety of users (nurses, physicians, pharmacists, technicians) in a typical health care setting where personnel have varying knowledge and skills51 . Interoperability (which permits disparate health information systems to communicate) is a requirement for the NHIN. Standards, market fragmentation, and data fragmentation, the three impediments to interoperability, slow health IT adoption. Standards have been proposed as a way to create interoperability. Standards have been discussed, developed, and disagreed upon for more then 10 years52,53 . Mandating a single IT infrastructure is controversial. Policy makers and established health IT companies 11 have placed their hopes in enforcement of standards to “preserve” the market; however this will result in a slow and costly incremental bottom-up approach to health IT adoption4,5 . The cost of migrating or updating large numbers of software programs to meet standards hinders the creation of a NHIN40 . Interoperability is burdened by market fragmentation. Fragmentation of the market is exhibited through the use of hundreds of unique IT systems. In an American Academy of Family Physicians (AAFP) survey of physicians who use EHR software programs, Valdes found that less than 1% of respondents used the same EHR/EMR system43 . The current health IT system is fragmented by the wide variety of EHR applications that cannot interchange data because of the diversity of software programs, and licensing restrictions that slow the progress of interoperability. Additionally, data fragmentation is a barrier to interoperability. A patient's medical records are fragmented across multiple treatment sites, posing an obstacle to medical care and public health efforts54 . EHR system interoperability will be difficult in this health care system in which insurance companies, hospitals, physicians, laboratories, pharmacies, and radiology facilities all create patient data on different computer systems. Data exchange across multiple sites greatly hinders the sharing of patient information41 . The federal government does not list data security as a barrier; however, this is a common theme in the literature and should be addressed by any viable NHIN solution41,55 . The sensitivity of medical information coupled by public knowledge of past security breaches in health IT make data security a significant issue55 . Intellectual property laws in a proprietary system hinder the insurance of data security because disclosure of security vulnerabilities is illegal and limits research in application security56 . Free and Open Source Software Development The barriers to adoption of health IT show that the challenge for the NHIN will be creating a functional program that is economically feasible, interoperable, and adaptable. In- depth examination of the definition of FOSS and its development process is important for understanding why FOSS is a viable model for the NHIN. The licensing structure and 12 development process of FOSS make it a strong candidate for the NHIN because its benefits favorably address many of the barriers to nationwide health IT adoption. These five benefits are low cost to development, enhanced ability of a company to leverage its resources, application adaptability, prevention of vendor lock-in, and third party verification of privacy. After a discussion of these strengths, three development models for the NHIN (pure proprietary, mixed, and pure FOSS) will be compared and contrasted as to how they address the barriers with these strengths in mind. Definition of FOSS The terms ‘free’ and ‘open source’ with regard to software are often misunderstood. Grasping their meaning is essential. Software is what drives a computer and is built with ‘source code’ which is written by computer programmers. If the source code is ‘free’ or ‘open source’ that means the code can be accessed, shared, built, improved, and distributed by software engineers because their rights to do so are not restricted by the license. ‘Open source’ software is very similar in meaning to ‘free’ software (‘open’ emerged as a marketing term because people often thought ‘free’ meant at no cost)4. The terms are grouped together as ‘Free and Open Source Software’ (FOSS). ‘Free’ software does not refer to the cost. It is free as in “freedom of speech”. The Free Software Foundation defines ‘free’ below:57 Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software: 1. The freedom to run the program, for any purpose. 2. The freedom to study how the program works, and adapt it to your needs. Access to the source code is a precondition for this. 3. The freedom to redistribute copies so you can help your neighbor. 4. The freedom to improve the program, and release your improvements to the public, so that the whole community benefits. Access to the source code is a precondition for this. 13 These rights are safeguarded by Free and Open Source licenses. The two main licenses that allow these arrangements are the GNU General Public License, often referred to as the GPL, and the Berkley Standard Distribution license or BSD license. There are other FOSS licenses which are often referred to as ‘compatible’ with the GPL and BSD. The gold standard for free licenses and compatibility of other licenses is maintained by the Free Software Foundation (http://www.fsf.org). It is important to understand these licenses because they enable the variety of business models that combine FOSS with proprietary software. The BSD license allows BSD licensed code to be incorporated into proprietary code which can then be sold as a package without having to return the source code to the community. This is a popular license with proprietary companies and has been used in Microsoft products4. The GPL license (most popular with the FOSS community), written by Richard Stallman of the Free Software Foundation, ensures that modifications to free software be returned to the community. This license preserves the free and open source development process. Some have wrongly concluded that the GPL is “viral”, meaning that proprietary code used with GPL code will have to be opened to the public, but that is not the case. As long as code modifications and software are not distributed or sold to the general public, private modifications are not required to be returned to the community. Development process of FOSS FOSS has many advantages over proprietary software development because of two factors: the free and open source community and the licensing structure. The development process of FOSS has achieved industry success in a manner that puzzles many because the process is supported by a large community of software engineers that often work voluntarily without payment of royalties. This condition is created through its licensing structure. FOSS is a good candidate for the NHIN infrastructure because its development process can alleviate many of the barriers to nationwide health IT adoption. FOSS benefits 14 both the business and the customer by: low cost of development, enhanced ability of a company to leverage their resources, product adaptability, removal of vendor lock-in, and third party verification of privacy3,4 . A discussion of these benefits follows. The community of FOSS engineers (that collaborate through the internet) often work voluntarily and develop software without proprietary licensing restrictions. Because of this arrangement, the FOSS process maximizes the number of people working on a program. Problems in the code can be realized and fixed quickly. This effect is described by Eric Raymond as Linus’ Law of Software Engineering. The law states, "given enough eyeballs, all bugs are shallow" and inversely “given few enough eyeballs, all bugs are deep" (bugs refer to problems in the source code)3. The community arrangement enables the correction of problems quickly, thus lowering the cost of development for the business owner. Also, the responsibility for writing the code is spread out, unlike a proprietary arrangement where licensing restricts the number of engineers resulting in only a few developers that bear all the responsibility of development. These FOSS effects lower the cost of development for the business by producing a reliable product in a timely manner. The second factor that makes FOSS attractive is the phenomenon created by the FOSS community that allows a software development company to leverage its resources. Leveraging can occur because the base product is already developed by the FOSS community and company resources can be redirected to creating value add-ons for the product. This ability to leverage is important because the software market has been devalued in two ways. First, devaluation has occurred through the emergence of FOSS (similar to the effect generic drugs have on their trade name equivalent by forcing competitors to lower their price and increase their value). Secondly, devaluation continues to occur through the natural commodity effect of time (by which customers expect more value for their money). The devalued market has given FOSS a competitive edge because a company can create more value for the customer by leveraging the FOSS community. This leveraging frees a company’s resources to produce better support services, customization of applications, and low-cost updates. 15 A third benefit of FOSS is adaptability of the product. This is especially important in achieving computer system interoperability for the NHIN. If a NHIN is mandated, software developers will have to change their product to meet national standards. One may find this is easier to do with the FOSS licensing structure that permits developers to access code, make appropriate changes, and distribute those changes. Another advantage of FOSS is its prevention vendor lock-in. The paradox regarding the free market and health IT is that there is no free market currently due to the phenomenon of vendor lock-in. As has been demonstrated, implementation of health IT software is expensive and difficult for the customer. Converting to a competing system is a costly and daunting task. Therefore, once software is installed, the customer only has a theoretical free market because in reality the customer has very little freedom to switch to another vendor because of cost. In contrast, FOSS licensing specifically permits the customer to preview the application and does not require the customer to change software when they replace an under-performing support company. Finally, another benefit of FOSS is the safeguarding of privacy analysis by third parties made possible through its licensing. Proprietary software, since it is the property of a corporation that has no obligation to open its code to other individuals or organizations, can be less secure because there is uncertainty surrounding the verification of product security. With FOSS, the right to examine the source code is specifically granted and safeguarded. The unique arrangement of the FOSS community and the licensing structure permit a business to reduce development costs, leverage their resources, and adapt their product. For the customer, because the applications are available through the internet by way of the FOSS licensing structure, vendor shopping is possible and privacy issues are lessened because the code can be viewed for security vulnerabilities. DISCUSSION: THREE NHIN MODELS A discussion of the public health significance of a NHIN, trends in health IT adoption, past and current health IT policy, barriers to adoption of health IT, and development of FOSS was undertaken. The information that was reviewed suggests that 16 FOSS should be considered for the infrastructure of the NHIN. This paper closes by arguing that FOSS is the optimum environment for the NHIN infrastructure by comparing and contrasting three IT system arrangements: pure proprietary, mixed FOSS/proprietary and pure FOSS. Following is a description of how each business model addresses the barriers to adoption. For review, the barriers to a NHIN are: adoption gap (there is a negative business case for EHR’s, especially in the small office setting), IT failure rate for implementation (due to the product’s inability to fit the user’s needs), limited capacity for interoperability (standards, market fragmentation, data fragmentation) and data security. Pure proprietary A proprietary model for the NHIN is limited in its ability to address the barriers to adoption. The first barrier, the adoption gap, refers to the disparity in health IT usage between small and large health care settings. Expense drives the adoption gap and will be the greatest obstacle to implementation of nationwide electronic medical records40,43,47 . Proprietary licensing (which restricts access, study, change, and distribution of the code to only the company) does not address expense issues found in the adoption gap because its licensing structure and development community create three problems for the small health care setting: higher software development costs, limited product adaptability, and creation of vendor lock-in for the customer (vendor lock-in is caused by migration costs created through proprietary licensing). These three factors lead to a product that may stay entrenched in the development phase or worse, a product that is unreliable. The primary weakness in a proprietary arrangement that creates the above scenario is the restricted development community in which programming capabilities are held by only a few software engineers. This alludes to “given few enough eyeballs, all bugs are deep" thus, complicating the process of identifying problems in the source code.3 A proprietary infrastructure, with the expense, stagnancy, and risk of vendor lock-in for the customer leads to an undesirable situation for the small health care setting. A proprietary model does not address the adoption gap. 17 The second barrier, high IT failure rate, is due to the inability of the product to fit the user’s needs. A high risk situation for health IT failure has the following characteristics: high cost of development, limited adaptability of the application, limited leveraging ability for the company, and risk to the user of vendor lock-in. These conditions are promoted by a proprietary software infrastructure. High costs and low adaptability result from proprietary licensing which limits the number of programmers that can work on an application. These restrictions decrease their ability to collaborate on problems in the code, thus development is prolonged and can lead to an unreliable product that is difficult to adapt to the user if changes are necessary. Also, proprietary licensing contributes to health IT failure by limiting the company’s ability to leverage their resources. A company’s ability to leverage their resources is important because the software market has been devalued two ways: through the emergence of FOSS and the commodity effect of time by which customers expect more value over time. Limited leveraging capabilities in a proprietary model may lead to failure of a health IT project. For example, if a business decides to start a proprietary EHR, they would have to create a product from the bottom up. Company resources will be concentrated at the beginning of the development cycle, rather then the end of the development cycle (the end of the cycle focuses on customers’ needs). Software companies must perform in a devalued market; therefore, a corporation’s ability to leverage is crucial. Another condition leading to a high IT failure rate, vendor lock-in, is promoted through proprietary licensing. Proprietary licensing puts the software development company’s interests rather than the customer’s interests first. For example, if a customer wants to add a data entry box to the application, they have to ask the company to do it. The company may be financially unstable to comply, or may have their interests diverted, putting the customer’s needs at the mercy of the company. The company is in charge of the product and the customer is stuck with the product because of the expense associated with hiring a new company. Proprietary licensing also forces the customer to change the software if they change vendors because the company owns the software. These qualities that lock in the vendor make it a high risk choice when faced against the failure rate of software projects5,49 . 18 The limited capacity for interoperability is the third barrier. If interoperability is enforced (which is desired because of the benefits to public health), the small office practitioner will face more costs to adapt their product under proprietary licensing. Could proprietary licensing impede interoperability standards? Bates describes that “most applications do not communicate well, even within organizations, and the costs of interfaces are high”, he continues, “standards for some important types of data are privately held. Privately held standards are standards that are in general use but are licensed by a company or organization”58 . The last barrier to nationwide health IT adoption is data security. Security problems can arise in a proprietary environment because licensing blocks third party verification of vulnerabilities in the computer code. Currently, intellectual property laws make disclosure of application security vulnerabilities illegal56 . The aim of this arrangement is to create ‘security by obscurity’. However, the obscurity that is permitted by proprietary licensing can lead to persistence of ‘back doors’ which are locations in the code that can lead to data exposure 56 . Proprietary licenses are unlikely to grant the right to analyze and verify software security vulnerabilities to third parties. As shown above, a proprietary model for the NHIN infrastructure has difficulties addressing the barriers to adoption of a national health IT program. The research community and the federal government have found that these barriers to health IT diffusion must be surmounted in order for the NHIN to succeed. A proprietary model has many weaknesses impeding the proliferation of nationwide health IT adoption. Mixed model – FOSS/proprietary A mixed FOSS and proprietary arrangement, like that seen in Figure 1, 2, and 3 below, combines the benefits of both models. For example, the FOSS community may not have software that fits the target market and a company may prefer to use proprietary software that is newer, better tested, and enhanced. But, a company may choose to run their proprietary software on a FOSS platform to lower costs, preserve some product adaptability, 19 activate leveraging ability, and expand their market (resulting from brand recognition in the FOSS community). A major draw back however, are the proprietary licensing issues found in a mixed model which may create similar obstacles to implementation success, adaptability, interoperability, and privacy confirmation. If a company decides to use a mixed model, there are three IT arrangements detailed below that were chosen because of their ability to maximize the benefits of proprietary code and open code. The first model describes the ability to run proprietary applications on the Linux kernel (the kernel is the foundation of a computer program or ‘operating system’). The Linux kernel is a popular FOSS program, and with the GPL, the propriety code that runs on the kernel is not required to become public domain unless it modifies the kernel. View the figure below taken from Fink’s book to better understand the first arrangement4. Figure 1: Commercial software running on Linux. The second combination is based on using proprietary software to enhance FOSS. A FOSS application can be combined with proprietary software enhancements that may not be 20 available in the FOSS community. This design makes it ready for commercial release. See the figure below taken from Fink’s book4. Figure 2: Enhancing FOSS with proprietary software. The third mixed arrangement concerns dual licensing. This model requires that some FOSS code be converted to closed source. It parallels traditional licensing operations, including payment of royalties. The major drawback is the cost of managing these new licensing arrangements. However, a company can lower development costs if it leverages the FOSS community and focuses its resources on product enhancement. A benefit to dual licensing is the GPL-mandated quid pro quo that ensures release of a similar product to the community (except for the copyrighted portion) leading to a larger customer base and company recognition. View the figure below taken from Fink’s book4. 21 Figure 3: Commercial software managed with a dual-license. The mixed models detailed above enable a business to maximize the strengths of FOSS and proprietary applications. For the NHIN, the benefits of mixed models give flexibility in its capacity to address the barriers to adoption; however, because of proprietary licensing issues inherent to the mixed IT arrangement, pure FOSS may still be the better choice. While a mixed model is not the optimum infrastructure for the NHIN, this may be the most likely outcome because the ability to use proprietary licensing is attractive to business. Pure FOSS FOSS is the best model for the infrastructure of the NHIN. As argued earlier, a model based purely on FOSS can address many of the barriers to health IT adoption through five benefits: lower cost of development, ability to leverage resources, product adaptability, 22 lack of vendor lock-in, and third party verification of security issues. The table below is a summary of the benefits to FOSS and their capacity to address the barriers to adoption of health IT. Table 1: FOSS benefits and their capacity to address barriers to health IT adoption. Adoption gap IT failure rate Interoperability Security Lower development costs X* X X Leveraging in software development X Adaptability to changing needs X X X X Prevention of vendor lock- in X X Third party verification of privacy X * X denotes positive ability to address barrier The first barrier, adoption gap between the small and the large group health care setting, exists largely due to the expense of health IT a small office setting will face. The FOSS development process and licensing structure relieve expense issues found in the adoption gap three ways: lower IT production costs (found in the FOSS community and licensing that maximizes the number of software engineers working with a program, some largely voluntarily), unrestricted adaptability of code through low-cost product updates (available for free off of the internet), and consumer empowerment to chose a vendor5. These characteristics may appeal to physicians in smaller group settings. The second barrier, high IT failure rate, needs significant attention because failure rates studies found that 29% of projects succeeded, 53% were challenged (late, over budget, and/or less then required features), and 18% failed (cancelled prior to completion)50 . FOSS 23 addresses the high IT failure rate through lower development costs, enhanced leveraging ability for the company, product adaptability, and the lack of vendor lock-in that is enhanced through its licensing. The IT failure rate can be addressed through the lower cost of development found in a FOSS environment. Reduced expense results from the community of FOSS engineers that often work voluntarily and develop software without proprietary licensing restrictions. Because of this arrangement, the FOSS process maximizes the number of programmers; therefore, problems in the code can be found and fixed quickly. The problems are fixed through updates which are distributed for free from the internet by the FOSS community. Secondly, FOSS addresses the high IT failure rate by enabling a company to leverage its resources. Leveraging enables a company to achieve two factors crucial to IT success: a strong competitive presence in a devalued software market and improved value to the customer by focusing resources on the users’ needs. FOSS enables a business to leverage the community of developers and direct resources towards the end of the development cycle (which concerns the users’ needs). Because health IT failure was found to be largely due to the inability of the product to fit users’ needs, the leveraging strength of a FOSS business addresses IT failure by maximizing a company’s resources to support the users’ needs. Focusing resources towards the end of the development cycle is crucial to the success of health IT because it enables a company to concentrate on the unique work demands of a health care environment. Work flow design is particularly important in medicine because neglecting to study work flow may increase mortality15 . The leveraging capability permitted through a FOSS infrastructure allows a company to focus on the needs of the user which include support, training, product updates, and work flow design. Also, FOSS addresses the IT failure rate through its strength of product adaptability. Adaptability is permitted through FOSS licensing which allows a programmer to run, copy, distribute, study, change, and improve the software. FOSS product adaptability addresses the IT failure rate because the needs of the customer are easier to address, especially important in the health care setting which employs a variety of people with diverse responsibilities. 24 Lastly, FOSS licensing addresses the health IT failure rate through its prevention of vendor lock-in for the customer. Because this software is freely available, a consumer is able to change vendors if the supporting company doesn’t fit their needs. For example, if an implementation fails because the vendor could not fix a billing problem, the user can change the vendor company but still retain the software because of FOSS licensing. The vendor can be replaced without having to face an expensive migration to a different software product. FOSS’s strengths allow it to address the many issues behind the failure of IT in the health care setting. The third barrier to nationwide adoption of health IT is the limited capacity for interoperability. The federal government has proposed standards as a solution to interoperability issues; standards for health care electronic data exchange have been under development for more than 10 years52 . Unfortunately, the consumer and the IT vendor will meet formidable costs to migrate or update large numbers of software programs to meet standards. FOSS can address interoperability through two facets: low development costs and product adaptability. Again, these are due to a licensing structure that permits programmers to access, study, modify and distribute code alterations to conform to standards. The ability to access and change the code in FOSS health IT applications (without the obstacles found in proprietary licensing) will have great significance in achieving interoperability in a field where data exchange is burdened by standards, data fragmentation, and market fragmentation. The last barrier to nationwide health IT, data security, is an essential factor to address because of public concern surrounding privacy of sensitive medical information. Data security is less of an issue with FOSS because the licensing permits third party identification of programming vulnerabilities to data exposure. Proprietary companies function in the exact opposite manner. They desire ‘security by obscurity’ which is protected by intellectual property law and prevents disclosure of code vulnerabilities to third parties. Proprietary software creates the ability to have un-detectable backdoors (exposure risks) or unintentional security vulnerabilities in the code. Therefore, the ability of multiple parties to 25 check code through a FOSS arrangement will play a significant role in insuring data security and privacy. Can a pure FOSS model be ideal for the NHIN? Unfortunately, a NHIN based purely on FOSS is unlikely. Lobbying efforts by the proprietary software industry will likely fight a federal government effort to mandate FOSS for the NHIN. The United States is a capitalistic society, if the government mandates only FOSS for the NHIN, there will be vocal political opposition. The casual observer may label a FOSS mandate as anti-free market or anti- American. However, a pure FOSS model can preserve free market practices if businesses are built on installation, servicing, training, and software enhancements. This is similar to the spread of railroads in U.S. history. It was easy to realize that train tracks had to be standardized to maximize the benefits of train transportation and to create an economy around the railroad industry. A pure FOSS business can be modeled on the railroad industry example and preserve the free market by building an industry around the NHIN – an industry which may include services in training, implementation, and other value add-on services. In summary, there are three possible software arrangements for the infrastructure of the NHIN: pure proprietary, mixed (FOSS and proprietary), and pure FOSS. Below is a table that compares and contrasts the three business models with the five factors found to be significant to the barriers to nationwide health IT adoption. The capacity of each model to achieve these qualities is described as high, medium, and low. Table 2: Models compared by their capacity to achieve each of five health IT qualities. Low development costs Leveraging in software development Adaptability to changing needs Prevention of vendor Lock-In Third party verification of privacy Proprietary Low Low Low Low Low Mixed Medium Medium Medium Medium Low FOSS High High High High High 26 The previous pages demonstrated the capacity of each model to address four barriers to adoption of nationwide health IT. The table below summarizes each model according to their capacity to address the barriers with the five health IT qualities discussed. Table 3: Models compared according to their capacity to address barriers to adoption. Proprietary Mixed FOSS Adoption gap High development costs Low adaptability High vendor lock- in Medium development costs Medium adaptability Vendor lock-in possible Low development costs High adaptability Low vendor lock-in IT failure rate High development costs Low ability to leverage Low adaptability High vendor lock- in Medium development costs Medium ability to leverage Medium adaptability and vendor lock-in Low development costs High ability to leverage High adaptability Low vendor lock in Interoperability Low adaptability Medium adaptability High adaptability Privacy/Security Unverifiable Mixed verifiability Verifiable A proprietary model was found to be the least compatible with addressing the barriers to nationwide health IT adoption. Proprietary licensing creates a variety of problems which hinder diffusion of the NHIN. These problems are higher development costs, limited ability for a software development company to leverage resources, restricted adaptability to fit the user’s needs, vendor lock-in issues, and unverifiable data security. A proprietary model is not a good choice for the NHIN. A mixed model combines the benefits of both models; however, proprietary licensing issues found in a mixed model may create similar obstacles to IT implementation, 27 adaptability, interoperability, and privacy confirmation. A FOSS mandate is unlikely; therefore, a mixed model of both proprietary and FOS software, though not the optimum arrangement, has a greater chance of acceptance. The discussion of the IT models above show that FOSS is the best choice for the NHIN. The FOSS community is characterized by a unique process of development and licensing. This combination creates an environment which addresses the barriers to adoption through five strengths: lower cost of development, enhanced ability of a company to leverage its resources, product adaptability, prevention of vendor lock-in, and third party verification of privacy. CONCLUSION A FOSS development model means that the code is not proprietary, and refers to the licensing that safeguards the rights of a programmer to access and tailor the computer programming code. This lowers the cost of development. This can also result in better software quality through development communities that regularly share information to solve problems and build upon improvements. The aim of this paper was to specifically address the following question: Can FOSS be an appropriate model for the IT infrastructure of the NHIN? To answer that question, review of the public health significance of a NHIN, trends in health IT adoption, past and current health IT policy, barriers to adoption of health IT, and development of FOSS was undertaken. Then, a variety of business models utilizing FOSS and proprietary software were demonstrated using a spectrum of possible models for the NHIN infrastructure: pure proprietary, mixed, and pure FOSS. Comparison and contrast of how these models address the barriers to the NHIN revealed the strengths and weaknesses of each. A FOSS system, through the development process and licensing structure, addresses many of the barriers to nationwide health IT diffusion. These barriers have come into play as natural byproducts of the evolution of health IT adoption and policy. Scholarly literature and the federal government agree that these barriers need to be considered prior to any successful 28 implementation of a nationwide health IT infrastructure. The strengths of FOSS with regard to these barriers were found to be lower development costs, enhanced ability for a software development company to leverage resources, product adaptability, removal of vendor lock- in, and third party verification of privacy. The federal government is motivated to implement a NHIN for a variety of reasons. The government is America’s largest health insurance provider and will see the most cost savings through improved quality of health care and reduced administrative paperwork costs. Secondly, increased public awareness of medical errors and research showing health IT can improve the quality of medicine has made implementation of the NHIN a public health issue. Finally, a NHIN framework will enable a more effective response to threats from bioterrorism, emerging diseases, and natural disasters through improved public health surveillance and computerized exchange of information. All of these benefits point to the need of an NHIN. Health IT adoption has been slow and the barriers are significant. A FOSS implementation can address the barriers to the NHIN and is the best solution available. 29 LITERATURE CITED 1. U.S. Department of Health and Human Services. Office of the National Coordinator for Health IT. Health IT strategic framework. Available at: http://www.hhs.gov/healthit/executivesummary.html Accessed 2/23/2006. 2. U.S. Department of Health and Human Services. Office of the National Coordinator of Health IT. Mission statement. Available at: http://www.dhhs.gov/healthit/mission.html. Accessed 2/23/2006. 3. Raymond Eric. The Cathedral and the Bazaar : Musings on Linux and Open Source by an Accidental Revolutionary. Rev. ed. Beijing ; Cambridge, Mass: O'Reilly; 2001. 4. Fink Martin. The Business and Economics of Linux and Open Source. Upper Saddle River, NJ: Prentice Hall PTR; 2003. 5. Kenwood Carolyn. The business case study of open source software. Bedford, MA: The MITRE Corporation; 07/2001. Available at: http://www.mitre.org/work/tech_papers/tech_papers_01/kenwood_software/ Accessed 01/27/2006. 6. U.S. Department of Health and Human Services. Office of the National Coordinator for Health IT. Health IT strategic framework: Glossary of selected terms. Available at: http://www.hhs.gov/healthit/glossary.html Accessed 2/19/2006. 7. Bates DW, Ebell M, Gotlieb E, Zapp J, Mullins HC. A proposal for electronic medical records in U.S. primary care. J Am Med Inform Assoc. 2003;10:1-10. 8. Bush GW. Executive order #13335: Incentives for the use of health information technology and establishing the position of the national health information technology coordinator. Available at: http://www.archives.gov/federal-register/executiveorders/2004.html Accessed 1/23/2006. 9. American Hospital Association. Patients or paperwork? The regulatory burden facing America's hospitals. Available at: http://www.aha.org/aha/resource_center/statistics/statistics.html. Accessed 12/13/2005. 10. O'Carroll PW. Public Health Informatics and Information Systems. New York: Springer; 2003. 11. Institute of Medicine. The Future of Public Health. 1st ed. Washington, D.C.: National Academy Press; 1988. 30 12. Kohn LT,Corrigan JM,Donaldson MS,eds. To Err is Human:Building a Safer Health System. Washington, D.C.: National Academy Press; 2000. 13. Bates DW, Gawande AA. Improving safety with information technology. N Engl J Med. 2003;348:2526-34. 14. Bates DW, Leape LL, Cullen DJ, et al. Effect of computerized physician order entry and a team intervention on prevention of serious medication errors. JAMA. 1998;280:1311-1316. 15. Bates DW, Cohen M, Leape LL, Overhage JM, Shabot MM, Sheridan T. Reducing the frequency of errors in medicine using information technology. J Am Med Inform Assoc. 2001;8:299-308. 16. Evans RS, Pestotnik SL, Classen DC, Bass SB, Burke JP. Prevention of adverse drug events through computerized surveillance. Proc Annu Symp Comput Appl Med Care. 1992;:437-41.:437-441. 17. Evans RS, Pestotnik SL, Classen DC, et al. A computer-assisted management program for antibiotics and other antiinfective agents. N Engl J Med. 1998;338:232-238. 18. Han YY, Carcillo JA, Venkataraman ST, et al. Unexpected increased mortality after implementation of a commercially sold computerized physician order entry system. Pediatrics. 2005;116:1506-1512. 19. Phibbs C, Milstein A, Delbanco S, Bates D. No proven link between CPOE and mortality. American Academy of Pediatrics. Available at: http://pediatrics.aappublications.org/cgi/eletters/116/6/1506#1622 Accessed 3/21/2006. 20. Goldberg DE, Baardsgaard G, Johnson MT, Jolowsky CM, Shepherd M, Peterson CD. Computer-based program for identifying medication orders requiring dosage modification based on renal function. Am J Hosp Pharm. 1991;48:1965-1969. 21. Tierney WM, Miller ME, Overhage JM, McDonald CJ. Physician inpatient order writing on microcomputer workstations. effects on resource utilization. JAMA. 1993;269:379-383. 22. U.S. Department of Health and Human Services. Summary of nationwide health information network: Request for information responses. Available at: http://www.hhs.gov/healthit/rfisummaryreport.pdf Accessed 2/19/2006. 23. The Centers for Disease Control and Prevention. PHIN: Overview. Available at: http://www.cdc.gov/phin/overview.html Accessed 2/19/2006. 31 24. Weitzel R. The introduction of bar coding technology at Kaiser Permanente. Healthc Inform. 1991;8:24, 26. 25. Bradbury A. The computerized medical record: An invitation to dialogue. J Am Med Rec Assoc. 1990;61:32-39. 26. Davis R. The elusive paperless medical record. Kans Med. 1994;95:215-216. 27. Institute of Medicine. Chp 7. using information technology. In: Institute of Medicine, ed. Crossing the Quality Chasm: A New Health System for the 21st Century. 1st ed. Washington, D.C.: National Academy Press; 2001:164-165. 28. Starr P. Smart technology, stunted policy: Developing health information networks. Health Aff (Millwood ). 1997;16:91-105. 29. The Library of Congress. H.R. 5464 Medical and Health Insurance Information Reform Act of 1992. Washington, D.C.: 102d Congress; 1992. 30. The Library of Congress. S. 1757 Health Security Act. Washington, D.C.: 103d Congress; 11/20/1993. Available from: http://frwebgate.access.gpo.gov/cgibin/getdoc.cgi?dbname=103_cong_bills&docid=f:s1757is.txt.pdf. 31. National Performance Review. Department of Defense: Part 1 of 2. Washington, D.C.: Office of the Vice President; 09/30/1993. Available from: http://govinfo.library.unt.edu/npr/library/nprrpt/annrpt/agnrpt93/dod1.html. 32. The Library of Congress. H.R. 1757 National Information Infrastructure Act. Washington, D.C.: 103d Congress; 07/27/1993. Available from: http://frwebgate.access.gpo.gov/cgibin/getdoc.cgi?dbname=103_cong_bills&docid=f:h1757rfs.txt.pdf. 33. Burton LC, Anderson GF, Kues IW. Using electronic health records to help coordinate care. Milbank Q. 2004;82:457-81, table. 34. U.S. Department of Health and Human Services. Administrative simplification in the health care industry: Guidance on compliance with HIPAA transaction. Available at: http://aspe.hhs.gov/admnsimp/ Accessed 2/20/2006. 35. Nulan C. HIPAA--a real world perspective. Radiol Manage. 2001;23:29-37; quiz 38-40. 36. Shortliffe E. Strategic action in health information technology: Why the obvious has taken so long. Health Aff. 2005;24:1222-1233. 37. Institute of Medicine. Crossing the Quality Chasm: A New Health System for the 21st Century. Washington, D.C.: National Academy Press; 2001. 32 38. U.S. Congressional record. Congressional record text search. Available at: http://thomas.loc.gov/cgi-bin/query Accessed: 1/23/2006 39. Bush GW. President Bush delivers State of the Union Address. Available at: http://www.whitehouse.gov/news/releases/2006/01/20060131-10.html Accessed 2/23/2006. 40. Ford EW, Menachemi N, Phillips MT. Predicting the adoption of electronic health records by physicians: When will health care be paperless? J Am Med Inform Assoc. 2005. 41. Gottlieb LK, Stone EM, Stone D, Dunbrack LA, Calladine J. Regulatory and policy barriers to effective clinical data exchange: Lessons learned from MedsInfo-ED. This pilot project can obtain the medication history for a majority of five million covered patients from only six data sources. Health Aff (Millwood). 2005;24:1197-1204. 42. Hersh W. Health care information technology: Progress and barriers. JAMA. 2004;292:2273-2274. 43. Valdes I, Kibbe DC, Tolleson G, Kunik ME, Petersen LA. Barriers to proliferation of electronic medical records. Inform Prim Care. 2004;12:3-9. 44. Ash JS, Bates DW. Factors and forces affecting EHR system adoption: Report of a 2004 ACMI discussion. J Am Med Inform Assoc. 2005;12:8-12. 45. U.S. Department of Health and Human Services. Office of the National Coordinator for Health IT. Barriers to adoption. Available at: http://www.hhs.gov/healthit/barrierAdpt.html. Accessed 01/23/2006. 46. Bates DW. Physicians and ambulatory electronic health records. U.S. physicians are ready to make the transition to EHRs--which is clearly overdue, given the rest of the world's experience. Health Aff (Millwood). 2005;24:1180-1189. 47. Miller RH, West C, Brown TM, Sim I, Ganchoff C. The value of electronic health records in solo or small group practices. Health Aff (Millwood ). 2005;24:1127-1137. 48. Sauter V. Project success and failure: What is succuss, what is failure, and how can you improve your odds for success? Available at: http://www.umsl.edu/~rmfv3g/Index.htm Accessed 2/26/2006. 49. The Standish Group. CHAOS report 1994. Available at: http://www.standishgroup.com/sample_research/chaos_1994_1.php Accessed 2/27/2006. 33 50. The Standish Group. 2004 third quarter research report. Available at: http://www.standishgroup.com/sample_research/PDFpages/q3-spotlight.pdf Accessed 3/29/2006. 51. Zhang J. Human-centered computing in biomedical informatics. Lecture at the University of Texas School of Health Information Sciences. Houston, Tx: Zhang, Jiajie; 3/29/2006. 52. Goedert J, St George J, Deming B, Bunschoten B. The standards movement builds momentum. Health Data Manag. 1994;2:47-49. 53. Hammond WE. Health level 7. A protocol for the interchange of healthcare data. Stud Health Technol Inform. 1993;6:144-8.:144-148. 54. Mandl KD, Szolovits P, Kohane IS, Markwell D, MacDonald R. Public standards and patients' control: How to keep electronic medical records accessible but private commentary: Open approaches to electronic patient records commentary: A patient's viewpoint. BMJ. 2001;322:283-287. 55. Becker C. Technical difficulties. recent health IT security breaches are unlikely to improve the public's perception about the safety of personal data. Mod Healthc. 2006;36:6-7, 16, 1. 56. Cruz D. The fog of software. 2005. Available at: http://www.owasp.org/index.jsp: The OWASP Foundation Accessed 3/14/2006 57. Free Software Foundation. The free software definition. Available at: http://www.gnu.org/philosophy/free-sw.html. Accessed 02/03/2006. 58. Bates DW, Gawande AA. Patient safety: Improving safety with information technology. N Engl J Med. 2003;348:2526-2534. 34 VITA I, Corazon Martin Valdes, was born and raised in Houston, Tx 1973, the daughter of Atty. Beaumont Martin and Nelie Marzan Steficek, RN. My Scotch-Irish/Filipino roots have created a persona that can be described as the ‘Gentle Fighter’. I graduated from Bellaire High School in 1990 with Honors in the top 15% of my class – following was a brief stint at the University of Houston then to Texas A&M. My proudest moment in Aggieland was earning the BICH 401 jersey (which has a schematic of the Kreb’s cycle) for the highest score on a Biochemistry exam (a class so tough, the highest scores were often in the 40-50’s). My least proud moment was being a ‘Two-Percenter’ at Texas A&M. I was so anti-Aggie establishment that I didn’t even know the proper descriptive term and I would call myself a ‘T-sip’ which all Aggies know as a University of Texas student. At A&M, I completed a work-study program in Houston at the Texas Heart Institute which helped me realize my love for medicine. After an occasional visit to the Dean’s List, in 1995, I graduated from Texas A&M with a degree in Biomedical Science. I decided to become a Physician Assistant and matriculated at the University of Texas Southwestern in Dallas. There I met my husband, Ignacio, during orientation at Parkland Hospital. Shortly before graduation we married at the now closed Doctor’s Club of Houston. I worked for two years in Family Practice, then left to make my own family, and get an additional degree towards a Master’s in Public Health. My dream job is a career where I can utilize Biochemistry, clinical skills, and public health practice on a medical mission trip while rowing a kayak and sipping lemonade. This thesis was typed by Corazon M. Valdes. < | AIM: High Rates of Adverse Drug Events in a Highly Computerized Hospital >
|
|
|||||||||||
|
|||||||||||||
|
|
||
| All trademarks and copyrights on this page are ©2000 Journal of Open Source Medical Computing. | ||
