The EHR Developer Code of Conduct – Next Steps in its Evolution

Recently, the HIMSS Electronic Health Record Association (EHRA) released its “EHR Developer Code of Conduct.” This code of conduct was developed to promote “a set of transparent industry principles that reflect our continued commitment to support safe healthcare delivery, recognize the value and impact that EHRs have for patients and families, foster continued innovation and operate with high integrity in the market.” A PDF copy of the code along with five pages of questions and answers is available on the EHRA’s website.

Since its release there have been many comments on the Code and whether it is achieving its desired impact on the industry, or whether it’s simply a document that sounds good and might be a step in the right direction, but one that has little teeth, and is without significant benefit. In this blog post we’ll review the code, examine its provisions and offer an opinion and insight to its effectiveness and future.

Background

Introduced in June 2013, the code was adopted by 17 initial signers on March 3, 2014. One of the criticisms of the code is that it is voluntary–no EHR developer or organization is required to adopt and sign the code. However, those that do will be able to feature it in their marketing materials along with an EHRA-designed logo.

The Code of Conduct

The code of conduct itself focuses on the following topics:

• Patient Safety
  • Support of patient safety
  • Participate in Patient Safety Organizations (PSOs)
  • Share best practices
  • Notify customers if patient safety issues arise
  • No limitation to customers discussing patient safety issues in appropriate venues

• Interoperability and Data Portability
  • Enable customers to exchange clinical information with other parties and EHRs
  • Use available, recognized and nationally uniform standards for interfaces
  • Share best practices
  • Facilitate export of data if customer switches EHRs

• Clinical and Billing Documentation
  • Support accurate documentation of care
  • Provide documentation of supporting products and how regulatory guidelines are implemented

• Privacy and Security
  • Patient privacy will be protected through the secure and trusted handling of personal health information

• Patient Engagement
  • Patients and families will be considered beneficiaries / users of EHR technology, and this will be reflected in business practices.

Organizations adopting the code agree that they will adhere to all the principles of the code and will have practices in place to apply the code’s principles.

Discussion

The first thing that strikes the reader is that the details of the code are quite vague. For example, the code advocates use of “quality management systems” and “user-centered design methodologies” to support the patient safety principle, or the “secure and trusted handling of personal health information” for the privacy and safety principle. All good things to aspire to, yet principles that virtually all EHR companies already have embraced.

Given that the code is not a legal document, nor legally binding, the vague nature of the code is somewhat understandable. Yet the majority of the principles seem to be more “common sense” than groundbreaking in their scope. One is left to wonder whether the language was intentionally vague in order to make the code easier for organizations to support, rather than more prescriptive and structured, and as a way to speed industry support and adoption.

Interestingly the code is only four pages long, but it is supported by five pages of “Frequently Asked Questions.” The FAQ document addresses some of the “why” behind the rule. It also addresses the future of where the EHRA feels the code may ultimately go, yet unfortunately provides minimal additional clarity surrounding the code.

Enforcement

The glaring weakness with the code is that its adoption and documentation is voluntary and is not actively monitored by the EHRA. Compliance and monitoring with the code is entirely self-regulated by each EHR developer organization.

A method to enforce compliance is lacking. While the EHRA has taken the first step by developing the code, they have not chosen to enforce the codes’ adoption in any way. Even a minimal standard such as maintaining a list of EHR developers that have adopted the code is not available.

Suggestions for the Future

Most would agree that the EHR Developer Code of Conduct is a step in the right direction. Yet for it to realize its full potential, it will need additional oversight from the EHRA and/or HIMSS. What is missing is a way to “credential” organizations adopting the code, and perhaps even to augment the code with different levels of commitment (perhaps borrowing a tiered concept from the HIMSS EMRAM model).

Following are my four specific recommendations to help improve the EHR Developer Code of Conduct:

1. Create and maintain a user-accessible database of Code adopters

There needs to be external ownership of “credentialing” for vendors who are choosing to adopt the Code. HIMSS or EHRA (or even a third-party) could administer this database, but it seems that having vendors “self-report” and “self-certify” limits the potential benefits of the code for both vendors and purchasers.

Creation of a vendor database that is transparent and accessible online by both vendors and purchasers would be a way for EHRA to validate participants. This would need to be accompanied by a formal application by a vendor, and standards for “proof of compliance” with the code. In addition, annual review would help ensure accurate and timely updates to any information.

2. Create different “tiers” of adoption

Similar to the HIMSS EMRAM model, the code should offer different levels of adoption. Here are three suggested tiers:

Tier 1: Initial Adoption – similar to the current system, this could simply be an EHR vendor’s self-reported acceptance of the code.

Tier 2: Certified Adoption – this could entail EHRA validating compliance of a vendor by examining records provided by the vendor supporting the terms of the code (For example, a vendor would have to document it’s participation in a PSO, or make best practices publicly available).

Tier 3: Validated Adoption – this would entail an EHRA site visit (similar to the HIMSS EMRAM model) where all aspects of an EHR vendor’s business practices are evaluated and assessed. This would be the highest level of support of the Code, and would be the most valuable and trusted adoption level available (and therefore would hold the most value to both EHR developers and purchasers).

3. Monitor compliance with the Code

The EHRA will need to actively monitor compliance with the Code of Conduct. This would entail site visits for Tier 3 adopters. There will also need to be standards of practice developed by the community for Tier 1 and Tier 2 adopters that would validate (annually) an organization’s ability to comply with the Code.

A secondary benefit of monitoring would be that specific standards would need to be developed in order to fully document organizational compliance with the Code (i.e. compliance would need to be measurable). This would help ameliorate the current vague language associated with adoption of the code, and would help provide a baseline of performance for adopting organizations.

4. Create a dispute resolution methodology

In the event that a purchaser feels that a company is in violation of the code, there will need to be a dispute resolution process that is available to remedy and validate compliance with the Code. This should be part of the EHRA’s charter, and would provide significant value for purchasers of healthcare software.

APIs and the Future of the Code of Conduct

While the code is designed specifically for full-EHR vendors (“the Code of Conduct generally applies to complete EHRs or similar products”), it does support partial (modular) certification vendors as well. In fact, this may be where the code may realize the most benefit, especially as more modular and healthcare “apps” are developed. Recently Epic announced availability to its data via API (Application Programming Interfaces) and the Meaningful Use Stage 3 Proposed Rule advocating app / API development as a way to increase innovation. As we extend our EHR and healthcare data into the realms of traditional (e.g. non-Healthcare) software developers, we may find that the EHR Developer Code of Conduct will help frame the expectations of the Healthcare community for these new-to-healthcare development firms. Perhaps it is here that the code can realize its full potential.