Documentation that the Doctor ordered
Peggy Spencer explains how athenahealth uses MadCap Software to meet online help demands for its cloud-based physician services
At athenahealth in the USA, we believe that liberating doctors and patients from the administrative expense and stress of the health care system is not just a job; it’s a passion. Today, more than 29,000 medical providers nationwide take advantage of our cloud-based practice management, electronic health record (EHR), and patient communication services.
To help our customers get the most out of our services, we deliver a combination of online help and documentation.
This is no small task. Each month, a new release of our software is pushed out instantly to the entire network. In the past, we averaged 15 topics per release, but as our cloud-based services have grown, that has tripled to an average of 45 topics with each release.
The keys to meeting these demands are a streamlined process for adding content from our knowledge experts and single-sourcing to eliminate the unnecessary duplication of efforts.
Today we use products from MadCap’s technical communications suite to support these processes: MadCap Contributor and MadCap Flare. Additionally, we use the hosted MadCap Feedback Service for insights into how we can enhance the user’s experience.
Corralling the contributors
For many years, the subject matter experts (SMEs) in our company submitted information via Microsoft Word documents, emails, and even sheets of paper. The SMEs appreciated that we made it easy for them. However, it meant that all of our technical writers had to manually incorporate the content into our documentation and online help.
Manual entry was doable with 15 topics per service release, not so much with 45 topics.
We knew that any solution we came up with would have to be easy to use if we expected our SMEs to embrace it. At the same time, we were long-time users of MadCap Flare, which is a powerful tool but requires more expertise than you can expect from a casual user. That is why, when MadCap Contributor and Flare 7.0 came out in early 2011, we jumped at the chance to upgrade.
Figure 1. MadCap Contributor screenshot*
Contributor lets our SMEs enter their content into a pre-formatted template that we have created for them. It also enables them to add comments or edits to text developed by our technical writers.
With ease-of-use a top priority, we conducted a training session to help our SMEs get started. Nearly all of our 45 SMEs attended the training. However, even those that didn’t said they found the software easy to use. Within a couple months, everyone was using Contributor.
Ease of use extends to those of us on the technical writing team. Providing the templates in Contributor is simply a matter of importing our existing templates from Flare. Moreover, adding the new or edited content into the Flare-based documentation is simply a matter of clicking the ‘accept’ button. We no longer need to manually enter the text, or cut and paste it.
Overall, Contributor is allowing us to complete roughly twice the amount of work with the same number of technical writers. We couldn’t have kept pace with the increased workflow without it.
Maximising content re-use
The use of MadCap Contributor builds on the efficiencies we have already gained by using MadCap Flare to create and publish both our print documentation and online help. Central to these efficiencies are the use of single-sourcing and conditional build tags to produce multiple outputs of our content from a single, central Flare project.
We basically have a three-week cycle for each monthly software release in which we need to create and publish six print and online versions of our documentation.
In each of our release cycles, we first publish a PDF of the beta release notes internally for our own employees. Then we use conditional build tags in Flare to generate a subset of that information as a PDF for our beta customers.
Next, we update the release notes for the production version and create PDF documents for both our internal team and customers. These are delivered two weeks in advance of the new cloud-based release, so that both our employees and customers know what to expect.
Last, when the new release is available, we then publish updated internal and customer versions of our online help based on the approved release notes content.
Each time, conditional tags allow us to simply choose which pieces of content will be published in the different formats, and then Flare automatically publishes it in the designated outputs. Without this functionality, it is hard to imagine how we could meet this schedule and ensure consistency across our content.
Figure 2. MadCap Flare screenshot*
Figure 3. MadCap Feedback screenshot*
Meeting government mandates and customer demands
Conditional build tags combined with single-source publishing also help us support documentation requirements from the government and our customers.
For example, each year we need to certify our EHR technology with the Certification Commission for Health Information Technology (CCHIT). Delivering the printed manual for CCHIT certification used to be a time-consuming effort. Now it is just a matter of creating a conditional build of our Flare-based project
Similarly, some of our customers want to receive our documentation in Microsoft Word, so that they can modify the content for their own practice. Supporting these requests is as simple as creating a conditional build for Word.
Enhancing the User Experience
The third solution we use is the hosted MadCap Feedback Service, which guides us on how to enhance our users’ experiences.
It is a delicate balance. We want to get as many insights into how customers use our documentation and web-based help as possible, but we have to balance that with government protections on healthcare privacy.
The Feedback Service strikes that balance by letting us monitor what customers are looking for and how many hits a particular topic is getting---without divulging any specifics about the users.
Collectively, MadCap’s medical docuemntation tools make it so much easier to provide our customers the information they need in their format of choice. In turn, that makes my job a truly enjoyable one.
About athenahealth
In 1997, athenahealth’s co-founders Todd Park and Jonathan Bush purchased a birthing practice in California. Almost immediately, they were buried in paper and spent most of their time and energy trying to get paid. They looked for a solution, but couldn’t find one. So they built their own.
What resulted are athenahealth’s easy-to-use medical billing, practice management, and electronic health record (EHR) services. athenahealth’s web-based software, intelligent rules engine, and dedicated team of specialists address the many practice needs that impact both the quality of patient care and practice revenue.
About the Author
Peggy Spencer
Peggy Spencer is a technical writer at athenahealth, Inc. She has more than a decade of experience in the technical communications field.
* MadCap screenshots in this article are not images captured from the athenahealth system due to government restrictions on what healthcare information can be shared publicly.