Health care decision-support systems needed now. (Informatics).
Based on this information, actions may be taken, new practices developed, insurance coverage and payments determined and policies produced. Later, data may be recollected, information regenerated and the process repeated.
But regrettably, in no other industry has the promise of information technology to supply this essential information been less broadly realized than in health care.
Health information management systems do not meet current health care information exigencies. This is because they cannot group the tangible features of the participants and their related clinical processes, delivery and outcomes into reliable decision-support information.
These inabilities result from incompletely collecting the vital data elements into decision-support databases. Consequently, health information management systems remain data systems or, at best, incomplete decision-support systems.
Previously, health information management suffered from a lack of the bitways, middleware, applications and hardware necessary to make the decision-support databases feasible and affordable. This is no longer true.
Currently lacking is a clear concept of the decision-support databases needed and a description of the health care industry's collaborations needed to produce them.
Let's consider the concepts involved in creating databases and the various aspects of information management and health care industry collaborations that must be successfully assembled in order to make comprehensive decision-support databases possible.
Differentiating data from information
Data is distinct from information in that information is data that has meaning to its end user.
For example, the number "10 is essentially meaningless. To give meaning to '10", the "what" needs to be denoted. Ten dollars, 10 fingers, 10 injections, 10 anything conveys information provided the end user has the knowledge to evaluate it in its context.
Ten rubles, a hemogoblin of 10, 10 penny nails are examples where the end user's knowledge and the data's context are needed to realize meaning or generate information.
The data's context is very consequential to information generation and should not be overlooked. For example, $10 in New York City may have a different meaning (and be different information) than $10 in a third-world country.
Without knowledge and context, the "10 what" may simply remain data. Incomplete data and/or context, which lead to incomplete information, are the current state of affairs in health care information.
Data's meaning--and its transformation to information--is contingent on its context and on the end user's knowledge. Since machines do not yet have more than rudimentary knowledge, people remain an integral part of information generation.
Identifying the end users' knowledge level is key to preparing data and generating information. If the end users are experts, little to no data preparation may be needed. These experts will generate their own information.
If the end users do not have the knowledge necessary to generate information from the data presented, then intermediate steps by knowledgeable experts to do these data conversions are required. Finally, the data and/or information must be presented in a way that is usable by the end users.
Ultimately, information is valuable only if a decision may be made with it. Without the possibility of a decision, the benefits of collecting data and generating information must be questioned.
It is the decision-making value of information that makes information the bedrock of health care and there is a critical need for health care decision-support databases.
End user groups
In health care, there are four major information end users:
* Clinicians who need the information for clinical evaluation and management of patients
* Financial personnel who need the information for evaluating and managing the economics of health care
* Researchers who need the information to discover, integrate and/or apply new knowledge and propose new practices and policies
* Educators who need the information to school new knowledge experts/participants
Each of these major end users requires different decision-support databases to fulfill their needs. Yet, there is considerable duplication between each end user's data elements.
At the same time, there are data elements exclusive to only one end user's database. This combination of duplication and exclusivity makes cooperation between end users to share data elements an imperative.
The sharing of data elements will markedly reduce the costs of redundancy and collection of exclusive data elements making the decision-support databases affordable and, more importantly, complete.
Note, however, that privacy, trade and competition considerations will restrict the sharing of some exclusive data elements.
For example, it would be highly unusual for educators to need data that identifies participants. They could use all the data except participant identities for their schooling.
Researchers need participant information only for those participants who have consented or are approved to be in their studies.
Financial personnel need to see participant data and the services provided but not the clinical data (except for their clinical personnel who may need access to clinical data to make benefits and payment decisions).
Finally, clinicians need access to the clinical data elements for their evaluations and management. Access to non-clinical and sensitive clinical data such as psychiatric history would be on a "need-to-know" basis.
Data elements to be collected
There are three basic sets of data elements to be collected. It is not reasonable to expect that all data elements will be located in a single repository. Hierarchical indexes of data sets would be available to those who need the data. How data transfer and transactions are structured remains to be defined.
1. The first set of data elements is the participants' identifying elements that include individuals, payers (employers and insurers) and providers. These identifying data elements must have maximum security. Segregating these data elements from the next two groups should significantly improve their security.
2. The second set is the clinical data elements. These include medical histories, physical examinations, imaging studies and laboratory elements and the subsequent diagnoses and assessments and services delivered for every patient encounter. The capability for participants to add relevant non-encounter clinical data elements should be provided.
Included in clinical data elements are non-identifying demographics such as age, race, ethnicity, zip code, marital status and education level. The availability of these non-identifying demographics may be restricted if they could lead to participant identification. As an alternative, confidentially or nondisclosure agreements may be arranged.
The clinical data elements needed go beyond what is generally included in paper medical records. Luckily, the vast majority of these data elements can be automatically collected from the electronic clinical equipment used to generate them or from alternative processes already used such as transcription services.
3. The third set is the financial data elements that should be integrated with scheduling, appointment and service delivery systems. This integration is needed to accurately determine the sequence, duration and number of events. Financial data elements must not misconstrue charges as costs since the latter is generally unknown.
Also, critical to generating clinical information is the collection of type and number of services being delivered. Historically, only charge or reimbursement data for services have been collected. Charge or reimbursement data are inadequate for comparison between participants and over time, since charges and reimbursements are unique to each participant and they change over time. The type and number of services provided are not unique to participants so differences between participants and over time can be assessed.
There are plenty of participant professional associations and societies that would collaborate in identifying the data elements in each major data element group. Since these associations and societies are comprised of participants who will be the databases' end users, their inclusion in identifying the data elements is expedient.
Data elements standards
Health care data element standards already exist and are widely utilized. Examples include:
* International Classification of Disease, 9th Revision, Clinical Management ICD-9-CM (ICD-10-CM is available) based on the World Health Organization's work;
* Current Procedural Terminology (CPT) from the American Medical Association;
* UB-92 HCFA 1500, HCPCS, and Relative Values for Physicians from the Center for Medicare and Medicaid Services
* National Drug Codes from the U.S. Food and Drug Administration.
Other data element standards are being developed or available.
* The Council for Affordable Quality Healthcare (CAQH) is spearheading a national physician credentialling process defining these participants' set of data elements.
* Regulatory and accrediting bodies have data elements pertaining to participants that they could share.
* And, there are countless medical guidelines from which medical protocols can be developed and data elements identified.
Organizations that need to be involved in generating data element standards include:
* National Institutes of Health (NIH)
* National Institute of Standards and Technology (NIST)
* National Laboratories, Object Management Group (OMG)
* World Wide Web Consortium (W3C) with its Web Services Activity
* Institute of Electrical and Electronic Engineers (IEEE) and its working groups
Vendors and other organizations will also get involved. The Lister Hill National Center for Biomedical Communications of the National Library of Medicine is worth noting. It conducts R & D for the broad purpose of improving health care information dissemination and use. Their work is useful in defining and communicating data elements and generating information.
Information technologies requirements
The bitways, middleware, applications and hardware necessary for decision-support databases for each end user exist and are being used in local and enterprise applications. Data warehousing and data mining are well-established methods.
The problems involving widespread data element sharing lie in proprietary system incompatibilities, in the electronic exchange of data and in security issues. In spite of years of concerted efforts by standards organizations, proprietary systems are the major impediments to electronic data sharing. Even within compatible systems, security and the electronic exchange of data are problematic.
Consequently, security and electronic exchange of data needs led to the development of proprietary maintaining processes like wide area networks (WAN) and virtual private networks (VPN) and to system fossilization.
Recent developments appear to be overcoming these impediments. They enable communication between incompatible systems, laying the foundation for widespread collaboration.
The first development is the World Wide Web and its HTTP language. The other is Extensible Markup Language (XML). Included in XML are XML messaging, XML remote procedure calls (RPC) and the evolving XML Protocols (XMLP) and Extensible HyperText Markup Language (XHTML). These standards are leading to semantic Web services that essentially neutralize the incompatibilities and the problems noted above.
The Simple Object Access Protocol version 1.1 (SOAP 1.1) is a type of XMLP that offers the passing of complex messaging and RPCs using XML. SOAP 1.2 promises to significantly extend these capabilities.
Alternative technologies such as Web services definition language (WSDL), object request brokers (ORBs) and other existing technologies may still develop important roles. Finally, other technologies such as message oriented middleware (MOM) and XML metadata object persistence (XMOP) may develop consequential roles in the future.
Regardless of the technologies used, it appears that the final pieces of information technology needed to make comprehensive decision-support databases are (or soon will be) at hand. The limiting issue then becomes collaboration.
Collaboration based on "co-opetition"
"Co-opetition" is the term given to the inescapable cooperation required between competitors so that, paradoxically, they can better compete. Setting industry standards and compliance are the best examples of cooperation between competitors.
MedUnite, a health care insurance co-opetition venture, is an example of competitors joining forces to accomplish tasks that each planned to do individually. By cooperating, operational efficiencies, services, innovation and acceptance are greatly increased.
Several levels of co-opetition will be required in the effort to create health care decision-support databases.
* First, is the cooperation between bitways, middleware and applications vendors. This seems to be evolving. Yet, this cooperation is tenuous and a major participator can derail these efforts.
* The second level is cooperation among those in the health industry field. This is difficult and subject to privacy and trade regulations. Regulatory agency buy-ins will be required. An exact description of what can and cannot be shared is required and procedures for assuring that irregularities do not incur must be put in place.
* The next level of co-opetition is among providers. They will have to be assured of security issues and the unfair use of data. Whether this can happen remains to be seen. It would probably take payers (employers) to mandate participation (like the HEDIS and LeapFrog Group efforts). Accrediting organizations such as the Joint Commission on Accreditation of Healthcare Organizations and the National Committee for Quality Assurance will also have vital roles. Finally, the participant associations and societies, such medical specialty societies and hospital associations, need to contribute.
* At the end, individuals will have to participate. HIPAA privacy requirements must be met. By segregating identifying data from clinical and financial data, participation can be limited to situations where individual identification is required. Individual participants will then have options about how their identifying data elements may be shared ("released").
"Pie in the sky" or possible?
The efforts needed to generate the health care decision-support databases have precedence in the Internet. In fact, these database efforts will leverage the Web and its successors.
The issue is not one of feasibility but of the will to build a "Health Care Web" that can support the needed health care decision-support databases. In a capitalist society, this will is frequently described in terms like return on investment.
The ROI realized from a Health Care Web should be more than enough to justify its undertaking. These returns will be from the operational efficiencies, innovations and services attained in creating the Web and using the decision-support databases.
With the Health Care Web leading to decision-support databases, the promise of modern clinical medicine will finally be feasible. With these databases, authentic evidence-based decisions will become the norm.
More importantly, individuals will have evidence for their condition(s) and their management in a group like them in age, gender, race, ethnicity, habits, etc. Research and education will be greatly improved at lower costs, as will benefits management and financial transactions.
The time to meet the promise of information technology in health care is past due. The personal health of everyone and the economic health of many organizations depend on it.
Fidel Davila, MD, MMM, is associate medical director for CIGNA HealthCare at Intracorp's Dallas Care Center in Carrollton, Texas. He can be reached by phone at (972) 307-2700 x74550 or by e-mail email@example.com
|Printer friendly Cite/link Email Feedback|
|Date:||Jul 1, 2003|
|Previous Article:||Scared silent: the clash between malpractice lawsuits & expert testimony. (Health Law).|
|Next Article:||Are human research subjects safe enough? (Ethical Aspects).|