Software design is serious business: creating your own EHR system entails significant time, resources, and risk.

The behavioral healthcare field is one of quickly changing regulations, unique organizational missions, and complex local reporting requirements. With every new mandate, an electronic health record (EHR) software solution becomes more attractive to a busy agency struggling to keep up.

Since there is no one-size-fits-all EHR solution, it can be tempting for providers to consider creating their own software. In fact, that's how Anasazi Software got its start. In 1989, a behavioral health provider asked my company to develop a custom EHR application. At the time we were local consultants, but we quickly realized the pressing need for customized software throughout the behavioral healthcare community.

With my 30-year background in custom and commercial software development, I understand that a provider's operations might seem sufficiently unique to require a customized solution. If you are committed to that option, below are some suggestions to avoid common pitfalls.

Plan for the long haul. If your operations are exceptional enough to require completely custom software, they most likely will remain unique in the years to come. Therefore, you should plan for two to five generations of technologic, regulatory, and treatment evolution over the 10 to 20 years that this product will be in use.

[ILLUSTRATION OMITTED]

Create development standards. When initial development is performed in-house, all enhancements will have to be performed in-house. And, as everyone in behavioral healthcare knows, your requirements will continue to evolve. Since enhancements often will be performed by someone other than the original programmers, development standards are necessary for consistent, rapid, and bug-free modifications. Development standards also will help you create effective interfaces, training programs, quality assurance, documentation, and support.

Schedule sufficient time in your project plan both to create your development standards and to test them with a prototype application. Anasazi generally devotes a year or more to creating development standards when adopting a new technology.

Ensure HIPAA compliance. Since the development standards must fundamentally support HIPAA privacy and security regulations, seriously consider contracting with a recognized HIPAA security expert and a recognized HIPAA privacy expert. Their detailed assistance in creating strong standards support and with prototype testing will help you ensure compliance with these mandates.

Since CCHIT Behavioral Healthcare Certification will have a major impact when released, you also should consider contracting with experts in the CCHIT certification process, HL7 EHR Functionality standards, and interoperability standards. This will help your initial development standards reflect the emerging industry requirements.

Involve executive management. Every magazine article on large software efforts stresses the importance of executive management's support. When a development effort doesn't have that support--from start to finish--it is doomed to failure. To maintain the critical buy-in of the executive team, assign a full-time executive manager to your project. The executive director also should expect to devote significant time to the effort.

Devote resources to design and documentation. Consider establishing a core design team of four to six operations experts to work full time on the design for one to two years. For maximum efficiency this team could devote the first six months or so to developing the preliminary design, and then meet with representatives from each department to refine and extend the design requirements specific to their needs. This series of meetings held over one to two months for each department will help the design team fully address the requirements of your entire organization. Later in the development process, this group can serve as your quality assurance team.

Over the decade-plus lifecycle of your software thorough technical documentation will be essential to creating the numerous enhancements that will be required. Since it is equally important to update the technical and end-user documentation for each enhancement, a technical writer should be a permanent position. This person should attend all design team meetings to accurately document both the technical and end-user designs. Once the technical design has been approved, he can turn his attention to writing the end-user documentation.

Prepare early for implementation and support. The primary reason new software fails is poor implementation. I strongly recommend having an experienced implementation specialist as a founding member of the design team. This will allow the absorption of the detailed knowledge necessary for development of a successful implementation methodology. After implementation this individual is an excellent candidate to manage the support department.

Plan for change. Technology and regulatory requirements keep advancing exponentially. A good way to stay current is to keep a group of technical advisors on retainer. They should include experts in security, databases, operating systems, communications, and behavioral healthcare IT standards. You also likely will need technical generalists to consult on emerging technologies you'll need to adopt over time. In the past several years software developers have had to respond to such advancements as voice recognition, handwriting recognition, document imaging, wireless access, PDA support, evolving operating systems, and increased security threats, not to mention the advent of both e-mail and the Web. Who knows what new technologies will arise over the next 10 to 20 years.

Any multiyear project will be impacted by staff turnover. The loss of a key team member during the design, development, or implementation phases could be very damaging to your project and your agency. Thoroughly evaluate your retention policies and incentives to protect your organization's bottom line in both the near and long terms.

Prepare for risk. As outlined in The Standish Group's annual CHAOS Report, the failure rate of governmental and private (nonvendor) software development efforts is hovering at about 65%. This stark figure shows that proper risk assessment is critical before you launch any large development effort. From the outset be sure to have an adequate buffer in budgeted money and time to allow for potentially extensive cost overruns or significant schedule slippage.

As you can see from the guidelines above, a project of this magnitude requires a great deal of foresight. By considering these factors ahead of time, you will significantly improve your ability to develop an EHR software solution that reflects the unique needs of your behavioral healthcare organization. If the cost/benefit/risk equation of developing custom behavioral health EHR software is unattractive, you might consider purchasing EHR software with the flexibility to address the majority of your unique needs from a reputable vendor with demonstrated expertise in each of these areas.

Acknowledgment

I'd like to thank Jon Gabriel, Anasazi's Marketing Director, for his assistance with this article.

Mike Morris can be reached at mmorris@anasazisoftware.com. His views do not necessarily represent those of SATVA or its members.

ABOUT THE AUTHOR

Mike Morris is President of Anasazi Software, Inc., which he co-founded in 1989. He is also the Chair of the Software and Technology Vendors' Association.

[ILLUSTRATION OMITTED]