January 2016

Next Steps for the EHR Code of Conduct
By Dan Golder, DDS, MBA
For The Record
Vol. 28 No. 1 P. 30

In June 2013, the HIMSS Electronic Health Record Association (EHRA) released the EHR Developer Code of Conduct, "a set of transparent industry principles that reflect our continued commitment to support safe health care 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 (www.himssehra.org).

In March 2014, the following 17 vendors became the first to officially adopt the code: Allscripts, athenahealth, Cerner, CPSI, Epic, Foothold Technology, GE Healthcare, Greenway, MacPractice, MEDHOST, MEDITECH, Modernizing Medicine, NextGen, Practice Fusion, Siemens, SRSsoft, and Versasuite. They agreed to prioritize and promote the following concepts:

• patient safety, including participating as a patient safety organization (PSO), sharing best practices, notifying customers of patient safety issues, and allowing customers to discuss patient safety issues in appropriate venues;

• interoperability and data portability, including enabling customers to exchange clinical information with other parties and EHRs; using available, recognized, and nationally uniform interface standards; sharing best practices; and facilitating data export if a customer changes EHRs;

• clinical and billing documentation, including supporting accurate documentation of care, providing customers with documentation that supports the products and explains how regulatory guidelines are implemented;

• privacy and security, including ensuring that personal health information is handled securely; and

• patient engagement, whereby business practices must reflect the idea that patients and families are considered to be the beneficiaries of EHR technology.

In general, organizations adopting the code agree that they will adhere to its principles and have practices in place to facilitate adherence to the code's standards.

Weaknesses of the Code Today
One of the current criticisms of the code is that pledging to follow its principles is voluntary—no EHR developer or organization is required to adopt the agreement. However, those that do will be able to feature it in their marketing materials, including an EHRA-designed logo.

Also, some consider the code's details to be quite vague. For example, it advocates the use of "quality management systems" and "user-centered design methodologies" to support the patient safety principle, and the "secure and trusted handling of personal health information" for the privacy and safety principle. All good things to which to aspire, but in reality they're principles that virtually all EHR companies have already embraced.

Given that the code is neither a legal document nor legally binding, its lack of clarity is somewhat understandable. Still, the majority of the principles seem to be more commonsense than groundbreaking in their scope. One is left to wonder whether the language is intentionally vague rather than more prescriptive and structured in order to make the code easier for organizations to adopt and support.

Enhancing the Code 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's missing is a means to "credential" organizations adopting the code. It also may be wise to augment the code with different levels of commitment (perhaps borrowing a tiered concept from the HIMSS EMR Adoption Model).

The following are four specific recommendations to help improve the EHR Developer Code of Conduct:

Create and Maintain a User-Accessible Database of Code Adopters
There needs to be external ownership of "credentialing" for vendors who choose to adopt the code. HIMSS or the 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.

The creation of a transparent database available online to both vendors and purchasers would help the EHRA to validate participants. This could be accompanied by a formal vendor application and standards for proof of compliance. In addition, annual reviews would help ensure accurate and timely updates to any information.

Create Different Adoption Tiers
Similarly to the HIMSS EMR Adoption Model, the code should offer different adoption levels. Such a model could include the following tiers:

• Tier 1: Initial Adoption
Similar to the current system, this may be as basic as a vendor self-reporting its acceptance of the code.

• Tier 2: Certified Adoption
This could entail the EHRA validating compliance by examining vendor-provided records that support the terms of the code. For example, vendors would have to document their participation in a PSO, or make best practices publicly available.

• Tier 3: Validated Adoption
The most difficult tier would entail an EHRA site visit (similar to the HIMSS EMR Adoption Model) in which all aspects of a vendor's business practices are evaluated and assessed. Achieving this level of support for the code would demonstrate full commitment and therefore would hold the most value to both EHR developers and purchasers.

Monitor Compliance
The EHRA must actively keep tabs on whether vendors are compliant with the code. Site visits such as those suggested for Tier 3 adopters could be part of this process. However, vendors who commit to Tier 1 or Tier 2 levels also must be held to standards of practice developed by the community that would validate an organization's annual 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 (ie, compliance would be measurable). This would help ameliorate the current vague language associated with adoption of the code, and also provide a performance baseline for adopting organizations.

Create a Dispute Resolution Methodology
In the event a purchaser believes a company is in violation of the code, there must be a dispute resolution process available to remedy and validate compliance. If this were to be part of the EHRA's charter, it would provide significant value to those considering purchasing EHR 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 realizes the most benefit, especially as more modular EHRs and health care apps are developed.

Recently, Epic announced its data would be made available via application programming interfaces (APIs). Also, stage 3 of meaningful use advocates app/API development as a way to increase innovation.

As the industry extends its EHR and other health care data into the realm of traditional (eg, nonhealth care) software developers, it may find that the EHR Developer Code of Conduct will help frame the expectations for these new-to-health care development firms. Perhaps it is here that the code will realize its full potential. However, for that to become a reality, the code's framework will need to evolve to support more robust, stringently tiered adoption criteria, along with a defined certification process in order to ensure its long-term viability and utility in today's complex EHR market.

— Dan Golder, DDS, MBA, is a principal at Impact Advisors.