Oceania® designs healthcare software to help clinicians improve patient care delivery. Oceania’s products include the WAVE® Electronic Health Record and the embeddable Oceania Notes component, both featuring the most extensive clinical knowledge base available in the industry. Oceania's systems let clinicians directly acquire, use, and analyze information vital to patient care at the point of care.
My interpretation of the Congressional instruction is that there is a desire to attempt to adopt “uniform data standards for patient medical record information and the electronic exchange of such information” and to return with recommendations and legislative proposals for such standards and exchange. That part of the instruction is clear. What types of data and which parts of the “patient medical record information” that need to be automated are not as clear. The boundaries between administrative data and code sets with clinical data and code sets has been blurred over the last 5 years, as systems and code sets designed to solve different problems evolve towards each other.
Under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), a “code set” is any set of codes used for encoding data elements, such as tables of terms, medical concepts, medical diagnosis codes, or medical procedure codes. Medical data code sets that are used in the health care industry include coding systems for: diseases, injuries, impairments, other health related problems, and their manifestations; causes of injury, disease, impairment, or other health-related problems; actions taken to prevent, diagnose, treat, or manage diseases, injuries, and impairments and any substances, equipment, supplies, or other items used to perform these actions. Code sets for medical data are required for data elements in administrative and financial health care transaction standards adopted under HIPAA for diagnoses, procedures, and drugs.
The code sets being proposed as initial HIPAA standards are all “standards” already in use by most health plans, health care clearinghouses, and health care providers. However, they have little to no support among clinicians, except as necessary evils that must be accommodated in order to get reimbursed for the practice of medicine (for ICD and CPT). The codes currently proposed are:
ICD-9-CM: The International Classification of Diseases, Ninth Revision, Clinical Modification (ICD-9-CM), classifies both diagnoses (Volumes 1 & 2) and procedures (Volume 3).
CPT-4: Physician Current Procedural Terminology (CPT) is used by all physicians to code their services for administrative transactions. CPT-4 is level one of the Health Care Financing Administration Procedure Coding System (HCPCS).
Alpha-numeric HCPCS: Alpha-numeric Health Care Financing Administration Procedure Coding System (HCPCS) contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT-4.
CDT-2: Current Dental Terminology (CDT) is used for reporting dental services.
NDC: National Drug Codes (NDC) are used for reporting prescription drugs in pharmacy transactions and some claims by health claim professionals.
Further discussion of the merits or lack thereof for each of the proposed “standards” will be discussed in questions 2 and 3.
Central to the perspective and the issues that Oceania, Inc. faces and deals with is the reality that we believe, for clinical systems development, that you must push the point of capture to the source of data creation, and the use of data from systems to the point of output.
This revolution in automation has hit many other industries:
Are we starting to see this in healthcare? Physician order entry has begun to be touted and may be the first somewhat widespread implementation in our vertical market. Movement in this direction is because of the efficiencies that it brings, reduced cost, and lower rate of complications and morbidity for the patient.
The key to the success of this axiom is that the end user does (and wants to do) what previously was done for them. Many organizations testifying to the NCVHS yesterday and today are actually trying to do just this- build software products that allow for the data capture to begin to be moved to the source, and moving the output of the data to the users who are involved in decision making. Imagine the above scenarios, such as the ATM machine or using the credit card at the gas pump. We do not expect the end users of those systems to understand the back office automation that is needed in order to route the money to the correct bank; similarly, one would not be expected to need to know the details of the NDC drug packaging, count, or pharmaceutical packaging if you were creating a medication order for a patient, as it is levels of details and process that are irrelevant for the task at hand. There are many such examples in the automation of the physician practice, and choosing the wrong focus for the coding sets or for the data standards (either in the details or in the surfacing of their use) can have a significant negative effect on the migration to en electronic infrastructure and medical record. Many of the code sets and the standards that are being evaluated and proposed have been designed focused on the “capture to process, process to store, store to output axes” and very little on the “source to capture or the output to use axes”. Much of the frustration that clinicians have with coding schemas and the data standards that are selected reflects the different focus or business objectives that the coding schemas have. I strongly encourage the Committee to look at this very carefully, and to make absolutely certain that the data standards and code sets that are chosen make sense for the clinical practices that they will undoubtedly influence, and to assign each coding system or standard its boundaries.
There are 3 different types of issues that delay or prevent the development and widespread implementation of uniform standards for patient medical record information: 1) Agreement on the uniform standards for patient medical record information means that we have to agree on the content of the medical record at some level. 2) In addition to content standards for the electronic transmission of patient medical record information requires messaging, format, and system understanding and agreements as well. 3) Taking #1 and #2 into account, the third issue that need to be clearly articulated is who is the target user/customer of the data standard? These really are separate but related issues, and in many instances help explain the delays that we have seen in the implementation of standards in clinical practice and in clinical systems. In the last 5 years we have seen a technology explosion that has made the potential ability to have the electronic patient record a reality, at least from a technology perspective. Processing power, memory capabilities, and the evolution of the PC has begun to put the technical issues of the creation of systems a bit more at rest. The challenge that faces us now is more insidious- what content do we model or create in the electronic system? Issue #1 is extremely challenging, in that we have historically not needed to look at the business process of medicine and closely examine the content of what is communicated between providers, between caregivers, and between systems. Since much of the automation grew up away from the direct point of care (the resource utilization systems, the executive administration systems, the billing systems, the accounting systems, the registration systems, the scheduling systems, laboratory information systems, the transcription systems), the standards that were needed/are needed evolved to meet the content needs of the systems that were in play, the messaging needs of the systems in play, and the target customers of those systems (other systems). Organizations such as ASTM, ANSI, HL7, and others grew into organizations that began to help define the content and the messages that were exchanged or could be exchanged between systems. Rarely in this scenario did a practicing MD really care about the content of these systems or the message format of these systems, since the target customer or user of such output was another system vendor.
Recently, however, the billing and some of the accounting systems are starting to push into the clinical domain, pushing either for justification of billing and charge capture validation by the provider. Now, the content of the systems and the message format of the systems, designed to meet different needs, are being pushed into the clinical domain. Coding sets and “standards” that evolved to describe how an electronic message is passed between a registration and a scheduling system are now trying to tackle the issue of “What is a patient medical record”? How do you model (i.e. What is the content of an encounter and the process of creating) an encounter? What was the content of the encounter that physician X just created? For many of the coding sets that are proposed or implemented today (growing out of the administrative realm), the goal is not improved patient care but the financial justification to monitor care, and modify payment schedules or amounts. Administrative and bureaucratic pressure from the payers, the coding sets and the standards that they use are not the same words and expressions that clinicians would (or do) use in practice. We see some of this tension in the ICD and CPT evolution- codes that are focused on administrative and billing activities, less on the clinical capture of the encounter at the point of care. As the administrative codes push into practice, the focus is shifted from clinical patient care to dealing with the administrative codes, a distraction for the providers.
The ability to create coding schemas and electronic standardization has exceeded the pace of practice to incorporate those very codes and standards. Now, who is leading whom? Does the coding and the standardization activity lead the content of practice? Does the content and process of the practice lead the standards development activity? There is a bit of an uncomfortable pull and push, as both are evolving together and at the same time somewhat independently at this time.
There is disagreement on basic granularity of the medical record. Today, in the paper based world, I can create almost anything and call it the chart (pieces of paper, legible or not, typed or dictated, coded or not). Those degrees of freedom can not be easily be modeled in systems, and they are the degrees of freedom the practicing clinicians have today. The systems that need the data standardization should not be driving the practice of medicine, but should reflect the practice as it evolves.
The electronic transmission of data requires that somewhere, someone puts the data into the system in an electronic format- the clinician, the assistant, a scanning system, a transcriptionist, optical character recognition, etc. That data that is put into the system can be either human readable (so that clinicians can communicate between each other), machine-readable (so that system 1 can pass the message to system 2), or both. The challenge that information systems developers have is that the gold standard to replicate from the perspective of the clinician is the paper-based world, where the human readable passing of information is done. In order to do that in a computerized world, there needs to be machine-readable data, and the interface between those two systems in a treacherous place to be. Many systems developers no longer exist in the market because they did not walk this fine line, between the needs to “intrude” in the clinical world enough to get the machine-readable world requirements met. Clinicians do not think like computer processors. This challenge is even more pronounced when the end consumers of the machine-readable information (to date) have not been the creators of the information- where is the benefit equation for those putting the data into the system, the source of the information?
Where coding standards exist, they rarely have been created by domain experts with knowledge of the business process that they represent, the clinical process that they represent, and the technical and administrative knowledge of the domains that they involve. They usually end up being a compromise, redundant, complicated (such as ICD-10-PCS) and nobody is left happy with the outcome. One size clearly does not fit all, as we can see if we take the example of NDC below as a drug “standard”.
Problems with NDC:
1) There is no central "authority" for the creation and maintenance of NDCs. Although the Food and Drug Administration is responsible for this system, the FDA has shifted important responsibilities for the maintenance of the system to manufacturers and repackagers of drug products who assign their own codes. The manufacturers often reuse existing codes, make mistakes, and are slow in returning assignments to the FDA.
2) NDCs are not “standard” from one organization to another.
3) The variable number of digits in NDCs makes use and archival of NDCs very difficult.
4) NDCs are assigned to non-drug items in addition to drugs.
5) A Large numbers of drug products (especially over-the-counter generic products) do not have NDCs.
6) There is no public or open process for assignment of NDCs that involves the key stakeholders in the process.
7) The NDC system was designed for healthcare providers who manufacture drug products or pay for drug therapy. The design of the NDC system is completely inappropriate for the needs of most healthcare providers, especially; those providers (like physicians, nurses, physician assistants, and even pharmacists) who prescribe drug therapies, dispense drug products, or administer medications to patients. NDC identifies drug products at a level of detail (the package) that is much too granular to be of any practical use for most healthcare providers.
8) NDC is also inappropriate for administrative functions that involve data aggregation and analysis queries.
9) Many NDC listings (including the reference FDA listing) are updated infrequently and irregularly, when they are updated at all.
The “problems” with NDC are not unique to that standard, as it evolved in one arena and has now been pushed/pulled into another. We see some of the same types of problems with CPT codes, HCPCS codes, and ICD codes. In question 3 below, I will outline some of the characteristics that a standard should follow, and where some of the candidate coding systems could change and be optimized.
Private sector is in a time of transition, but is changing to meet the needs of the market. Coding and standards used to be the domain of academics, special interests, and business processes and clinician standards were rarely involved to a significant degree. I believe that this is changing, albeit slowly. HL7 as an example has been slow to evolve, occasionally considered exclusionary, and has been faulted for a creationist design for the extensions of the model that they propose. Those things are starting to change, as more systems developers participate and the constituents increase from the traditional lab and registration/scheduling vendors. It is very hard to take a strong creationist approach to any of the coding schemas today, in that the cognitive scalability of such a task is daunting and fraught with errors. Imagine if in the genesis of the Internet (the World Wide Web), they said from the beginning that the following IP addresses 1001-100,000 are for the domains of chemistry, 100,001-200,000 are for biological sciences, etc and had tried to dictate how the messaging and traffic content were to travel. The model changes and expands with growth and more knowledge, much like what we need to do with coding sets.
Government should insist on and help drive conformance with the process of standardization (along with industry), or the steps that must be taken in standardization, but not the content of the standards discussions themselves, other than as another equal participant at the table.
I believe that there are basics for standards and code set creation that are not followed today but that if they were would make the resulting coding systems that emerge much more valuable for information systems developers to use:
1. The code set must be maintained by a central code-assigning authority. They can not evolve independently, and in competing ways. While there will be times and many instances where local versions of the codes may be necessary, there should be a change set or ability to reconcile local with central coding schemas that allow for regional variation in practice.
2. The code set must be available in the public domain at no cost or at a nominal cost. If there is a charge for the system, the cost should reflect the cost of maintenance and upkeep only, not to fund other projects or portions of the organization that has been charged with the creation of the code set. The AMA with the CPT codes is a prime example of violating this principle.
3. The code assignment process must open for review, comment, and participation by the public constituents that are stakeholders in that coding set creation. NDC, HCPCS, and CPT are all examples where this is not always true, and the resulting sets do not reflect the input necessary for the uses of the standards. Payers and financial organizations can not be the only drivers of codes and standards that have application across a much broader continuum.
4. The code set must be frequently/continuously updated as new knowledge or development occurs (whether drugs, patient problems, procedures, orderable items). The ability to have these updates must be able to live with the previous versions of the codes and standard as well.
5. The coding schemas should ideally support lexical (how the words relate), semantic (the meaning of the codes or the captions), and logical (formal mathematical modeling) classification, with multiple levels of abstraction, where appropriate. Many of the coding schemas that are needed for analysis and reporting against clinical data are significantly lacking in this formalism. ICD and CPT are examples where this is not done, leading other systems to step in and create these types of relationships in a much better way.
6. When there are classifications in the coding system, there should be non-ambiguous, non-redundant classification. Having many duplicates, redundant, or overlapping codes makes for confusion on the part of the systems developers and for the end users
7. The coding systems that are selected should support precoordinated phrases and the ability to equate compositional phrase development. This means that the coding system must support, allow, or enable the ability to say that “Ear pain” (precoordination of the words “ear” and “pain”) and “Pain located in ear” are equivalent phrases
8. The coding schemas must support defining synonymy, which may imply that there is a concept model or that concepts are created. The example would be the equivalence of the symptom “Shortness of breath” with “Dyspnea” in coding schemas where symptoms are expressed.
9. Meaningless unique identifiers should be used in the creation of the codes themselves. It is neither appropriate nor useful for the IDs that are used in the codes to carry any meaning, classification, or hierarchy. The classification of the term or the element that is being represented in the code may change over time, making any hierarchy in the code irrelevant or obsolete.
10. Meaningless unique IDs must not change. Once a code is used, it must never be removed from the code set. If the concept that the code represents becomes obsolete or needs to be deleted, the code should be simply marked as obsolete, not removed; certainly it should not be reassigned to another concept. This is essential for backwards compatibility of codes and systems, and to begin to insure that codes that are analyzed at different times in the history of the coding schema are able to be compared. CPT, ICD, NDC are all guilty of this.
11. Any coding schemas and code sets that are created should be able to be handled in a machine-readable (not just human readable) format. This machine-readable format should be application and platform independent, so that the use of the coding schema is not tied to any particular computer system or vendor.
12. Updates to the code set must be made available to the public on a weekly or even daily basis. Web-based distribution of updates should be supported for more rapid distribution. None of the candidate codes that have been proposed to date satisfy these criteria.
13. Mechanisms to generate local changes (enhancements) to the code set or to the standard must be in place. This is not meant to support the concept of divergent development (local versus global), but to support the concept of an evolution of the code set that has contribution from many geographic and distributed developers that all have a stake in the evolution towards consensus. This functionality requires agreements on the tenets of the models that are being developed.
14. There must be mechanisms to collect local changes and identify “conflicts” between local changes, and between local changes with global changes. Conflicts can arise at the definition, classification, relationship, or context levels, all of which may be valid, as the code set or the standard evolves.
15. There must be a process for evaluating and resolving “conflicts” that are created on a local or a global level, and reconciling those conflicts.
16. Mechanisms to disseminate local changes as global updates must be in place so that the process of change can be replicated to the invested constituents.
17. The code set should be "backwards compatible" with the previous versions of the codes. This requirement substantially reduces the economic burden of implementing a new code set for existing systems while providing much-needed flexibility for new systems. NDC, CPT, ICD fail on this criteria.
18. The code set should deal exclusively with the domain for which it is created (Problems for problems, drugs for drugs, supplies or medical resources by a unique coding schema for that domain, etc).
Government can help play in role in the management of the process adhering to these guidelines for standards development, and in helping to overcome some of the following barriers that exist. Coordinated development (not dictated development) with a shared process for design and requirements could help alleviate the major problems that are occurring with standards bodies and their development today:
1) Many groups are proceeding independently, knowingly in conflict with others, either because of poor coordination, different models of how the problems should be solved, or out of ignorance for the other standards bodies.
2) Different data models, information models, and vocabulary models would need to begin to be reconciled.
3) Difficulty developing collaborations (geographic, across institutions, political space)
4) Easier to control development locally
5) Significant time and or financial constraints limit the amount of effort or personnel that any one organization can contribute to the cause.
6) Personal/group identification is important for many of the people that have been involved in the development process. Egos and biases definitely are factors in standards and code set development today.
7) Difficulty dividing up tasks while maintaining compatibility suggests an infrastructure and process disconnect.
A model that I would ask the Committee and the Secretary to consider for the development of healthcare standards is the human genome model of government/industry/academia collaboration. This model does not assume that the government will create all of the work for the development of the genome mapping. Indeed, centers of excellence, in both academia and in industry, are collaborators, each of whom are making contributions that are fed into a ever-growing common architecture of the genome. Government provides some of the infrastructure and the financial support to enable areas to work in collaboration, and the fruits of that development are not “owned” by any one group or individual.
1) Patient problem descriptors that have more formal modeling (if they are to be used by clinicians). ICD-9-CM is fine to use as long as the domain in which it is invoked as a standard is for the communication between administrative and billing systems. For clinical systems, used at the point of care, it is not adequate. SNOMED appears to be a much better standard for clinicians at the point of care, for its formal modeling and for the range of expression.
2) Patient procedure descriptors. CPT, while widely accepted for billing and administrative coding of procedures, is not very good at the capture of the content and the details of a procedure in words or expressions that clinicians would use.
3) Medications and drugs. Discontinue using NDC over time and begin to use the results of the HL7 Vocabulary Special Interest Group Drug Model and Listing committee. This code set is currently in the early planning stages of its development. This code set is based on collaborative work between a variety of organizations, including Multum Information Services, Inc., First DataBank, Micromedex, Medi-Span, and the National Library of Medicine, and has the potential to be the most clinically useful coding schema when it is finished.
4) Allergies and adverse events. A similar structure to adverse events could be used, if the analysis of the MEDRA data set is found to have enough overlap with the clinical data set. Allergies, medications (with immunizations), blood type, and patient problems are 3 key pieces of data that need better standards and definition, since they are so vital in the development of any clinical information system.
5) The patient chart (its content and structure). This standard development activity is in its infancy, but holds great promise for the development of clinical systems. The most promising standards that is evolving for this is the HL7 Patient Record Architecture.
6) Laboratory information. LOINC codes are among the most expressive for the return of clinical laboratory data, but are not valuable for the generation of outbound laboratory requests (since in many cases the generating system or clinician does not know the specific method of analysis of the compound). For example, some of the thyroid hormone assessment methods have very different codes depending on how the hormone was measured.
7) Immunization and vaccination codes. Administrators of vaccines are required to record the date of vaccination, manufacturer and identity of vaccine, lot number, and name, address, and title of the person administering the vaccine in the patient's record. Can not be done with NDC.
8) Nursing care codes will need to be integrated into the standard data sets. It seems that there are as many nursing data sets and standards competing for recognition and expressivity. The Committee and the Secretary should work with the nursing organizations to get consensus on these data sets.
9) Patient orders and orderable items. The lack of standardization of items across institutions is a significant barrier to the interoperability between systems and between organizations. Each organization continues to evolve, driven largely by the need for charge capture.
Code sets and the transmission of clinical data about a patient, not the administrative data, is most important for my company. We are in the business of creating solutions for the clinician at the point of care. The best example that we are seeing on the market today of a code set or standard generating body is the College of American Pathologists SNOMED. This organization comes the closest to meeting the ideals outlined above for standards development. HL7 has made some promising progress in the area of messaging, and their adoption of XML (the Patient Record Architecture) as they start to get into the content of messages and of the patient chart, holds promise. If you look at SNOMED versus almost every other coding schema, there are significant differences in terms of expressivity. For example, systems that want to capture and convey information about chest pain can use SNOMED or ICD:
| SNOMED | VS | ICD9 |
|
Chest Pain |
Chest Pain (786.5) |
Generalizing the coded data to the level of ICD causes much of the significant details and data about the patient to be lost. Once a user, system, or developer has generalized to ICD (and has stored or sent the ICD containing message), it is not possible to recreate the chart data in granular detail, such as the location of the chest pain, which may be important for outcomes measurement, decision support, therapeutics decision making, or analysis.
The business case for rapid standards development and implementation, as long as the standards development follows good development practices such as those outlined above, will be a tremendous win for the industry. We spend a tremendous amount of time talking about, designing, implementing, and testing interfaces to many different systems. Just the systems integration work saved would be a huge cost savings to the organizations that so desperately need integration.
Our belief, however, is the barrier to clinicians using systems directly (when they are designed appropriately, focused on the correct business process, and targeting the correct source of data) is what will need to be overcome in order to see the ultimate cost, quality, and access issues addressed in healthcare. If companies that are focused on these areas could devote more time to the development of systems that advance this agenda, and less time on the custom integration and interfaces that a lack of standards creates, it would be very valuable for Oceania.
In general, yes. A missing element that needs to be addressed is the context in which the various code sets are developed and used, not just the data elements themselves. See the image on page 2. If the Committee and the Secretary focus just on the code sets themselves, and not on the context (the source, the business process, the environment) in which they are used, the results of the Act will be more deleterious than the current situation where we have no consistent standards. The domains modeled (as well as the applicability of those domains) needs careful consideration.
Thank you for the opportunity to share some observations and comments on this most pressing and timely topic.