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.
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.