Skip to content Skip to navigation

Understanding standards development

March 1, 2008
by George Pashel
| Reprints
Multiple organizations affect the development of standards for behavioral healthcare software

Agreat deal has been published in recent years on the expected value of increased use of information technology (IT) in healthcare. Improvements in quality and reductions in costs, documented in other economic sectors that have implemented IT, typically are cited as evidence of the potential benefits of IT in healthcare. In fact, the Office of the National Coordinator for Health Information Technology cites estimates of a 20% potential reduction in healthcare costs from IT use. Yet until recently the healthcare industry invested only $1,000 in IT per worker annually, compared to $8,000 in other industries.

Initiatives are under way to address this disparity. One of the most important in the long run may be establishing minimum standards for software used by various healthcare sectors—including behavioral healthcare. To that end, in 2005 the federal government awarded the Certification Commission for Healthcare Information Technology (CCHIT) a contract to advance the standards- development process and create a system to certify software products as complying with these standards.

CCHIT, a private nonprofit organization, already has published standards for hospital software and doctors' office software, and CCHIT certification is available for these products. It's hoped that certification will facilitate evaluation and comparison of software products by establishing a “baseline” so that buyers are assured that certified products will perform at a certain level. By reducing uncertainty around software functions, the risk of such purchases is reduced, thereby facilitating broader use of IT.

When it published ambulatory care certification standards in 2006, CCHIT stated on its Web site:

CCHIT acknowledges that these Criteria may not be suitable for settings such as behavioral health, emergency departments, or specialty practices and our current certification makes no representation for these. Purchasers should not interpret a lack of CCHIT Certification as being of significance for specialties and domains not yet addressed by CCHIT Criteria.

CCHIT has developed a road map that addresses the potential standards development for “populations,” “care settings,” and “professional specialties” not yet addressed. CCHIT categorizes child health and behavioral healthcare as “populations.” Child health certification standards, having been given higher priority, are expected to be ready in May, and behavioral healthcare standards may be available in 2009. Two “care settings” also of potential interest to the behavioral healthcare community are long-term care and home care.

A critical component of CCHIT's development of certification standards is the work carried out by Health Level 7 (HL7) under the umbrella of the American National Standards Institute. ANSI is a nonprofit private organization that has coordinated voluntary standards development in the United States since 1918. HL7, an ANSI-accredited organization, develops standards around electronic health information. The certification standards CCHIT is developing rely to a significant degree on the general standards being developed by HL7.

Through a process involving significant public input, HL7 is actively developing standards for behavioral healthcare IT. This process began in May 2006 and through a series of meetings and votes, a behavioral healthcare “functional profile” has been developed. The profile is organized around three areas: direct care functions, related to the provision of care to individuals or groups; supportive functions, which fulfill administrative and financial requirements; and information infrastructure functions, related to reliability, security, and interoperability.

The profile recently passed its initial HL7 committee ballot but with a number of comments that need to be reconciled before final adoption.

A broad array of behavioral healthcare providers and software products will be affected by standards development, a complicated consensus-building process. To illustrate this complexity, consider the following examples:

  • Information essential to a substance abuse treatment setting, and clearly required of software used in this setting, may be completely irrelevant in a treatment foster care setting. Thus, requiring treatment foster care software to conform to requirements for substance abuse treatment software would unnecessarily add to the software's cost or preclude the benefits of certification.

  • Best practices are evolving at different rates and in different directions within various areas of behavioral healthcare. Requiring software to support best practices in one area may be entirely appropriate, but make no sense for software used in a different behavioral healthcare sector.

  • Consider if a standard required software to limit disclosure of client information without consent. This sounds reasonable. However, without national standards about the definition of consent, as well as how it should be obtained and documented across all service categories and accreditation groups, it could be very difficult for a software product to meet this requirement.

Pages

Topics