Ambulatory EHR Functionality: A Comparison of Functionality Lists

Transcription

1 Ambulatory EHR Functionality: A Comparison of Functionality Lists Barbara M. Drury, BA, HIMSS Senior A B S T R A C T There is a proliferation of lists intended to define and clarify the functionality of an ambulatory electronic health record system. These lists come from both private and public entities and vary in terminology, granularity, usability, and comprehensiveness. For example, functionality regarding a problem list includes the following possible definitions: Create and maintain patient-specific problem lists, from the HL7 Electronic Health Record Draft Standard for Trial Use. Provide a flexible mechanism for retrieval of encounter information that can be organized by diagnosis, problem, problem type, from the Bureau of Primary Health Care. The system shall associate encounters, orders, medications and notes with one or more problems, from the Certification Commission on Health Information Technology. Displays dates of problems on problem list, from COPIC Insurance Co. Shall automatically close acute problems using an automated algorithm, from the Physicians Foundations HIT Subcommittee. This article will compare the attributes of these five electronic health record functionality lists and their usefulness to different audiences clinicians, application developers and payers. K E Y W O R D S Ambulatory Electronic health record functionality Electronic health record requirements Office-based electronic health record Electronic medical record In 1991, the Institute of Medicine s Committee on Improving the Patient Record released one of the sentinel documents describing attributes of the computer-based patient record. 1 In that sense, all other documents describing the computer-based patient record, currently called the electronic health record, or EHR, are derivative documents. During the past five years, there has been a proliferation of documents listing attributes of electronic medical record systems. With the visible interest of the federal government, there is much new activity around the electronic health record system, as evidenced by the expansion of both the number of EHR lists and the number of elements present in EHR lists. Journal of Healthcare Information Management Vol. 20, No. 1 61

2 The entities that have written each of these lists have identified a purpose and mission, and the EHR elements they have selected to appear in each electronic medical record functionality list reflect that purpose. This article looks at five such lists from varied sources. It will describe each list s applicability to the ambulatory care setting, whether intended exclusively for the ambulatory care setting or intended for any care setting. This is not an exhaustive collection of EHR functionality lists and others exist; rather, these lists are readily available and in active use or on-going enhancement by a variety of entities. Evolution of Functionality Lists The oldest of these lists comes from the Bureau of Primary Health Care, a federal agency for publicly funded not-for-profit community health centers throughout the United States. The Bureau of Primary Health Care is a division of The Health Resources and Services Administration of the Department of Health and Human Services. The functional specification, written in RFP format, is made available to interested vendors which answer each functional statement as if they were responding to a formal request for proposal. During the past five years, there has been a proliferation of documents listing attributes of electronic medical record systems. This self-certification process then can be used to determine the depth and breadth of the responding vendors systems; the results are posted in the BPHC Web page as an evaluation tool that can be used to prepare request for proposals or request for quotes. 2 This EHR functionality list is available electronically in Microsoft Word format and is entitled Electronic Medical Record (EMR) Functional Requirements Version 5.2. The document does not bear a copyright or a date but is associated with an electronic medical record project that took place in 2000 to In January 2001, COPIC Insurance Co., a private forprofit insurance company, published a notebook titled Benchmarks for Electronic Medical Record Systems. COPIC business units provide medical professional liability insurance, insurance brokerage and financial services, office site visits and medical record reviews, and data abstraction for research projects. The company says it seeks to enable the healthcare community to devote the greatest possible proportion of its resources to patient care. COPIC published Benchmarks for Electronic Medical Record Systems: A Decision Tool and Resource in January The document represents a COPIC-led working group s recommendations on the features that will be most important to physicians from the perspective of risk management and reduction of potential liability. 3 The risk management department of COPIC researched existing electronic medical record functionality lists during 1999 and 2000 and selected functional statements for inclusion based on the function s ability to reduce risk and potential liability. Since 2001, the benchmarks notebook has been distributed to every COPIC-insured physician, or about 6,000 individuals in Colorado. It provides physician education about EHR functions, aids informal and formal selection processes and sets the basis for eligibility for a premium discount for appropriate use of an EHR. The functional requirements list is available electronically in Adobe PDF format and as one part of the hardcopy notebook, Benchmarks for Electronic Health Record Systems. 4 The Electronic Health Record System Functional Model is a product of Health Level Seven, an international member organization and one of several American National Standards Institute-accredited standards developing organizations in the healthcare arena. HL7 s mission is to provide standards for the exchange, management, and integration of data that support clinical patient care and the management, delivery, and evaluation of healthcare services. Specifically, it seeks to create flexible, cost-effective approaches, standards, guidelines, methodologies and related services for interoperability between healthcare information systems. 5 The functional model is a product of the HL7 electronic health record technical committee. Through a wellestablished process that incorporates and resolves all member comments, the functional model is currently a draft standard for trial use (March 2004). The EHR technical committee has made revisions, which, when this article was being written, were available for public comment. That revised EHR functionality list is known as the Enhanced Draft EHR System (EHR-S) Functional Model. The current draft standard for trial use has a 2004 copyright by HL7. 6 The Criteria for Ambulatory Care Products is actually three lists that come from the Certification Commission for Healthcare Information Technology, or CCHIT. The commission seeks to create an efficient, credible, sustainable mechanism for the certification of healthcare information technology products. Such certification seeks to reduce the risk of HIT investment, to ensure interoperability of HIT products with emerging local and national health information infrastructures, to enhance the availability of HIT incentives from public and private purchasers/payers, and to accelerate the adoption of robust, interoperable healthcare IT. 7 CCHIT is a private not-for-profit organization composed of appointed volunteer commissioners largely from within the health information technology industry. Three CCHIT 62 Journal of Healthcare Information Management Vol. 20, No. 1

3 work groups have been charged with developing electronic health record elements for the ambulatory care setting. These work groups are studying functionality, interoperability, and security and reliability. In 2005, these work groups have released two work products and, at the time this article was being written, the Phase II Work Product is out for public comment. 8 The Physicians Foundations Questionnaire is a working document of the health information technology subcommittee of the Physicians Foundation for Health Systems Innovation. The Physicians Foundations were established as the result of a settlement between class representatives and certain medical societies with Aetna and CIGNA after managed care litigation. 9 This private not-for-profit foundation is actually two foundations with overlapping board members composed of members from organizations represented in a class action. Based on conversations with members of The Physicians Foundations and the HIT subcommittee, the questionnaire is being used to request information from companies with electronic health record systems that may be suitable for solo and small physician offices. It is not a published EHR functionality list but an internal working document for the Physicians Foundations HIT subcommittee. 10 Functionality List Organization All five EHR functionality lists were converted to and manipulated by using an electronic spreadsheet. The COPIC list is generally only available as a notebook. BPHC has 266 elements; COPIC has 222 elements; HL7 has 138 numbered elements, excluding headers; CCHIT has 315 elements; and the PF list has 252 numbered elements. Except for the COPIC EHR functionality list, the others have merged spreadsheet cells in different columns throughout the document, making the row number in each contiguous column different. All except the HL7 functionality list use single sentence elements; the HL7 list tends to use paragraphs with multiple explanations. The EHR functionality lists organize these elements into subcategories that vary both in structure and language. Neither the BPHC list nor the COPIC list uses higher-level major category headings. The HL7, CCHIT and PF EHR functionality lists each have three major categories. HL7 s three major categories are direct care, supportive and information infrastructure; CCHIT uses functionality, interoperability, and security and reliability; and PF has features and functions, interoperability, and security and reliability. The subcategories used in each list may be few (13 for both the COPIC and HL7 lists) or lengthy (47 for PF and 56 for CCHIT). Table 1 shows the subcategories for each list in the order presented in each list. This also illustrates the topic areas that each authoring entity considered important enough to receive a category designation. The CCHIT EHR functionality list uses row numbers for reference in the spreadsheet. The other four lists have numbering but use a unique presentation in each list. In addition, the HL7, CCHIT and PF lists are actually a combination of lists from three work groups. The PF column headings vary among the three major categories. Although the column headers are the same in the HL7 EHR functionality list, its three work groups chose slightly different variations of how to treat the internal subcategory column headers. In the list from the direct care HL7 work group, the column with ID as the header is a whole number without decimals. A header row has an ID number and name, but there is no statement and no description. However, in the supportive section of the HL7 EHR functionality list, some IDs that contain as many as three decimals have a name and the description is blank statement. And in the HL7 information infrastructure section, all the whole number IDs and names also include statements and descriptions, including subcategory headers, which appear as whole numbers in the HL7 functionality section. These variations within the document make for confusion as to which part of the element name, statement or description is the element to be measured and which is simply an informational subcategory header. The EHR functionality lists organize these elements into subcategories that vary both in structure and language. The functionality lists from HL7 and PF have no indication of priority or requirement of each specific element. HL7 is currently working on conformance statements numbered, single sentence statements that will indicate a priority by the use of shall, which implies now, and the use of should, which implies some future date. The COPIC, BPHC and CCHIT lists have slightly different forms of prioritization for each specific element. The COPIC EHR functionality list has three priority tiers high, strongly suggested, and desireable within each subcategory. The BPHC EHR functionality list also has three sets of prioritization minimum, optional, and neither-blank. CCHIT s implied priority is taken from the recommendation columns certify in 2005; roadmap for 2006; and roadmap for Terminology and Scope In a review of the content and scope of the elements in each of the five EHR functionality lists, a sampler set of 60 elements was developed. Each sampler set element was sought in each of the five lists. In addition, where the sampler set element was mentioned in multiple elements in Journal of Healthcare Information Management Vol. 20, No. 1 63

4 Table 1. All EHR functionality list subcategories. the subject EHR functionality list, the association was also noted. BPHC has 35 of the 60, associated with 49 elements. COPIC has 50 of the 60, associated with 54 elements. HL7 has 39 of the 60, associated with 58 elements. CCHIT has 58 of the 60, associated with 85 elements. PF has 51 of the 60, associated with 59 elements. When an element from the sampler set was associated with more than one element in a particular EHR function- 64 Journal of Healthcare Information Management Vol. 20, No. 1

5 Table 1. All EHR functionality list subcategories. ality list, it indicated that language within the list could reasonably be interpreted as being the same or very similar to the sampler set element. There are both vagaries and specific nuances that result in one element being addressed in multiple statements or descriptions. This makes it difficult to use any of the EHR functionality lists as an absolute measure of functionality without considering the implications of duplication or omission of elements found in the other lists. Several examples are noted in Table 2. In addition, there are elements that appear in one of the EHR Journal of Healthcare Information Management Vol. 20, No. 1 65

6 functionality lists but not in any of the other four. Some examples are: CCHIT: The system shall support revocation of the access privileges of a user without requiring deletion of the user, according to Security and Reliability No. 4. BPHC: The system includes plotter support capability. 4. Current Health Data, Encounters, Health Risk Appraisal. F. COPIC: Supports the separation of non-clinical data within the electronic record. 03-SS-10. HL7: An EHR-S uses the entity registries to determine the security, addressing and reliability functionality between partners. An EHR-S uses this information to define how data will be exchanged between the sender and the receiver. I.5.3. PF: The system shall automatically close acute problems using an automated algorithm unless physician specifies otherwise. Setting defaults by diagnosis is preferred. Features and Functions No While reviewing each EHR functionality list for the elements from the sampler set, the result of a word search was not a reliable indicator of the presence or absence of a particular function. It is essential that the elements be read and interpreted for conceptual content rather than specific key words. For example, language such as including herbals, vitamins and other non-prescription supplements appears as OTC (COPIC), non-prescription medications (PF and CCHIT), and alternative supplements and herbal medications (HL7). The BPHC makes no reference to non-prescription supplements. In terms of the comprehensiveness of each EHR functionality list, all address functionality associated with the delivery of care (features, functionality, supportive) and all address more technical elements (security, access, equipment, interoperability, information infrastructure, reliability, technical). As a percentage, the portion of functional elements used in delivery of care ranged from a high of 88 percent with BPHC to a low of 73 percent with COPIC. 66 Journal of Healthcare Information Management Vol. 20, No. 1

7 Conversely, the COPIC EHR functionality list has the highest portion of technical elements, and the BPHC functionality list has the lowest portion of technical elements. In actual number of elements, the CCHIT list has the largest number of delivery of care functional elements (238) as well as the largest number of technical elements (77) (See Table 3). Usefulness Before describing the usefulness of each EHR functionality list, it is necessary to revisit the evolution of each list and the intended audience for the information. The BPHC list appears to be, based on its authorship and the document name, intended for physicians in primary care offices in the United States. Any applicability to other settings, such as hospitals, nursing homes, laboratories, insurance plans and others, would be inadvertent. In that regard, the BPHC list is most appropriate for use by officebased primary care physicians and those that work with office-based primary care physicians. The BPHC list has a brief description of its purpose and contains details of the pilot projects in which the list was used. There is no glossary, reference citations or reader s guide. Secondary users of the BPHC list include other EHR functionality list authors, such as COPIC, other office-based physicians as well as software vendors targeting the community health center market. Knowing the expected functionality that may be required by organizations that provide funding to community health centers helps developers who specialize in software for the CHC market. Of the five functionality lists, BPHC s has the heaviest emphasis on clinical practice guidelines, preventive care, care plans, disease management, registries and decision support. Approximately 20 percent of all elements in the BPHC list fall into the area of clinical protocols. COPIC s EHR functionality list was developed for officebased physicians of all specialties in Colorado. While COPIC provides professional liability for other medical entities, such as hospitals and dialysis centers, the publication is directed at office-based physicians of all specialties. The notebook comes with a glossary of terms and several Web citations for additional reading. Secondary users of the COPIC list include other Physicians Insurance Association of America malpractice carriers and software vendors targeting the EHR market for office-based physicians in Colorado. Additionally, other authors of EHR functionality lists, such as The Physicians Foundations, refer to the COPIC list. The COPIC list is available as a notebook that permits tracking whether an EHR product has demonstrated each element. The notebook also has blank spaces enabling the office-based physician to record elements in addition to the Journal of Healthcare Information Management Vol. 20, No. 1 67

8 COPIC list. Physicians typically use this feature during the EHR acquisition phase. The EHR functionality list is also the primary tool that physicians use to confirm the EHR functionality used in their offices. If 80 percent of the high priority elements and 60 percent of the strongly suggested elements are used in 90 percent or more of office-based encounters, COPIC awards two points toward the preferred status premium discount. A total of six points per physician is required every two years to qualify for the 10 percent preferred status premium discount. There are a variety of ways to earn the six points, in addition to using an EHR. The COPIC list is the only one used in the evaluation of the physician s use of an EHR in the delivery of care. The HL7 EHR functionality list was developed for any and all healthcare settings in any country. HL7 used minimum function set work groups to tailor the broad HL7 elements to specific care settings, such as small ambulatory, large ambulatory, small acute and long-term care. At the time this article was being written, these conformance elements have been released for public comment and will likely become an integral part of the HL7 EHR Functional Model. The HL7 EHR functionality list was developed for any and all healthcare settings in any country. The HL7 EHR DSTU spreadsheet has three additional columns labeled See Also, Rationale and Citations. The See Also column directs readers to other similar or supporting elements elsewhere in the DSTU. The Rationale column, when used, indicates the broad rationale for the elements. The Citations column directs readers to other external documents that encourage, require or help define the elements. With HL7 s broad approach towards EHR functionality, and without the conformance elements specific to care settings, the primary target for the HL7 EHR functionality list would seem to be developers of EHR software for any care setting, developers of infrastructure and evaluators of EHRs. A secondary market for the HL7 list includes primarily purchasers and payers of health care services government, employers and insurance plans and other authors of functionality lists, such as CCHIT. The CCHIT ambulatory care EHR functionality list was developed as a tool to measure functionality of ambulatory EHR software products. The initial focus for this first objective for the CCHIT is software vendors targeting the smalland medium-sized office-based physicians who do not yet have an EHR. The Phase I material offered by CCHIT indicates that an EHR product that has been CCHIT Certified will increase physician confidence and encourage adoption in the ambulatory office-based setting. CCHIT Certification ensures the potential buyer or user that a minimum threshold of appropriate functionality has been met. Phase I CCHIT material indicates that a pass-fail approach for the EHR product is currently favored. The process that CCHIT will require of vendors before their EHR products are certified is under development. It is not clear whether every element or just a certain portion of the elements on the CCHIT list will be required (certify in 2005, roadmap for 2006, roadmap for 2007 breakouts) for the EHR product to be certified. The secondary users of the CCHIT list are much the same as the other EHR functionality lists: software developers, EHR evaluators and other EHR functionality list authors. The PF Questionnaire is an internal document assembled from other EHR functionality lists in an effort to enable Physicians Foundations member medical societies to be able to measure products that might be appropriate for use by small office-based physician practices. The PF list notes other sources that have been incorporated, such as the CCHIT and COPIC lists. However, there are more than 60 additional elements not found in the other lists that the Physicians Foundations included in its list, indicating an expansion of EHR functionality for small ambulatory settings. Because circulation of the PF list is limited to board members, other named parties to the settlement and friends of the working group, there is currently no secondary market for the PF list at this time. Audiences For the physician, the lists are most likely to be used before an EHR is acquired. Physicians using this list typically assume the details of the list are appropriate functionality for a physician office, and they typically assume that products claiming to reflect or successfully deliver the functionality on the list are the same. They also assume that the functionality described will automatically improve and adapt to physician office workflow, that use of a product that delivers functionality on the list means a guaranteed return on investment, that similar functionality reflects similar cost, that all functionality on the list will be utilized in this setting, and lastly, that the functionality list entity (COPIC or CCHIT) endorses the utilization of a product on the product list. In addition, physicians may use the criteria on the EHR functionality list to influence choice or to defend the selection of a particular EHR. Physicians who adopted software before the release of these lists may review them to solidify an earlier choice of an EHR. When reviewing these lists, and the secondary product lists from COPIC and CCHIT, physicians may be faced with a difficult decision whether to keep using an EHR that appropriately supports the functionality needed in the office 68 Journal of Healthcare Information Management Vol. 20, No. 1

9 but does not appear on the COPIC or CCHIT product lists, or weigh the pros and cons of converting clinical data from the existing EHR to a product that appears on the EHR product lists. Recommended lists: COPIC or BPHC List to watch: CCHIT For EHR software developers and their sales forces, the presence of functional criteria on the list will enable planned software enhancements. However, EHR software developers are not likely to place an EHR function on these lists ahead of EHR functionality being requested by physician users of the EHR. If an EHR software company chooses, it may capitalize on or perceive a competitive edge by being able to declare conformance to any of the lists. However, EHR software developers doubt that physician buyers are aware of the functionality lists or understand the details described on them. And lastly, list creators are likely to underestimate the ongoing efforts required from EHR software developers to keep EHR software version changes synchronized with responses to functionality list requirements. EHR software developers currently believe that there is a competitive advantage to being listed on the COPIC product list, a byproduct of the EHR functionality list, and will likely perceive a competitive advantage to being on the CCHIT product list. Recommended list: CCHIT List to watch: HL7 EHR evaluators fall into two broad subcategories: those offering incentives, specifically payers and purchasers, and quality improvement initiatives by Quality Improvement Organizations, or QIOs. EHR evaluators will likely make some dangerous assumptions as well. They are likely to assume that the technical criteria on the list will actually maximize data exchange; that physicians will appropriately use the functionality described on the list or use all the functionality on the list; that functionality described on the list will be sufficient to deliver consistently structured data; and that utilization of an EHR with the functionality on the list will be able to deliver data sooner than later. In addition, when an EHR functionality list results in a byproduct list of EHR products and vendor contact information, evaluators may embrace the appropriateness or desirability of the EHR based on a trusted expert s work, such as COPIC or CCHIT, and assume that using an EHR product from a list is a good thing without evaluating the utilization of the product in a particular physician office. Recommended list: CCHIT List to watch: HL7 Creators of these five EHR functionality lists as well as creators of future ambulatory care EHR functionality lists will need to address the assumptions that they may make. For example, they may assume that the EHR functionality list and all supporting detail is read by the intended audiences; that the EHR functionality list is understood; that most of the intended audience is made up of physicians without an EHR who are in the pre-acquisition stage; that developing standards will be synchronized to subsequent versions of the EHR functionality list; and that EHR software developers will be able and willing to devote effort to keeping EHR product versions synchronized with the lists. Creators of these five lists, as well as creators of future lists will be unlikely to avoid the unintended secondary uses of the lists, even with the presence of detailed disclaimers. Recommended list: CCHIT list List to watch: HL7 Summary In this review, four of the five EHR functionality lists, excluding the HL7 EHR draft standard, describe EHR functionality specifically for the ambulatory care setting. With the addition of the pending conformance elements for ambulatory care to the HL7 EHR functionality list, all five will describe EHR functionality for the ambulatory care setting. While all five lists describe elements of an electronic health record, each EHR functionality list is lengthy and The HL7 EHR functionality list was developed for any and all healthcare settings in any country. may appear somewhat technical to many readers. The lists have duplicate or very similar functionalities as well as very specific and unique functionalities. These differences may appear as conflicts to physicians, EHR software developers and EHR evaluators. The lists differ in the mention and specificity of how an EHR may share data, which is a key consideration for EHR evaluators, particularly payers and purchasers, and quality improvement organizations. All five functionality lists may be used to screen or prequalify EHR products before acquisition and implementation. Two of the five EHR functionality lists have or will have an associated EHR product list. Only the COPIC list is being used in the evaluation of a physician s use of an EHR in office-based care. It is likely that, over time, EHR evaluators will use one or more of the other four EHR functionality lists and any associated EHR product list as one component in evaluating a physician s use of an EHR in the ambulatory care setting. Whether these lists have necessary specificity and appropriate functionality for evaluating the use of an EHR remains to be seen. As a tool for assessing EHR functionality before acquisition, the BPHC and the COPIC EHR lists are the most physician-friendly, while the HL7, CCHIT and PF lists are perhaps better suited for EHR software developers and EHR software evaluators. Journal of Healthcare Information Management Vol. 20, No. 1 69

10 All five EHR functionality lists have contributed to the evolving description of an ambulatory electronic health record initially described in 1991 by the Institute of Medicine. List creators as well as readers of any list should be familiar with the use and audience for each list and be aware of the potential for association of other attributes beyond what the list creators intended. Lastly, any EHR functionality list should be considered dynamic, as additions and deletions will require continuous revision and reassessment. About the Author Barbara Drury, BA, HIMSS Senior, is president of Pricare Inc. and provides technology consulting services primarily for physicians. She is active in HIMSS, the HL7 EHR Minimum Function Set Work Group and a consultant to COPIC. References 1. Dick RS, Steen EB, Detmer DE, eds. The Computer-based Patient Record An Essential Technology for Health Care. Washington, DC: National Academy Press; Bureau of Primary Health Care. BPHC Electronic Medical Record Resources page. Available at: Accessed August 17, COPIC Insurance Co. Benchmarks for Electronic Medical Record Systems page. Available at: Accessed September 15, Risk Management Department. BENCHMARKS For Electronic Medical Record Systems A Decision Tool and Resource. Denver, CO: COPIC Insurance Co.; Health Level Seven. What is HL7? Available at: Accessed August 17, Health Level Seven. Download HL7 EHR-S Functional Model and Standard July 2004 DSTU Package page. Available at: Accessed September 7, The Certification Commission for Healthcare Information Technology. About CCHIT page. Available at: Accessed August 17, The Certification Commission for Healthcare Information Technology. Public Comment on Phase II page. Available at: Accessed August 17, The Physicians Foundations. Welcome to the Web site page. Available at: Accessed August 17, Verbeten, N. Vice President, Center for Economic Services, California Medical Association. Conference call. September 2, Journal of Healthcare Information Management Vol. 20, No. 1