DITA is seeing increasing use outside of the original computer software and hardware sectors from which it was born. One of those areas where DITA has taken off is in the healthcare technology sector, and recently I had the pleasure to interview Mike Kocik, who is the Information Architect at Carestream, where he has led the efforts of his technical writing team in a transition to using DITA XML. In the following interview he talks about what led Carestream to go down this path, and advantages that DITA offers and the special challenges of producing documentation in this industry:
DITAWriter: Can you tell me a little bit about your role there at Carestream as their Information Architect?
Mike Kocik: I work in the Documentation group of Carestream’s Technical Communications and Localization (TCL) department. This group consists of three full-time writers (plus myself, part-time) and two contract writers. As an Information Architect, the bulk of my work to date is spent configuring and fine-tuning our DITA environment so that everything—from the authoring templates to the content management system to the publishing tools—works as smoothly as possible for our writers. Along with maintaining that DITA environment in our department, I am also responsible for configuring and maintaining it at each of our three localization vendors’ sites so that they can translate and publish our DITA content. I update these environments periodically as our processes mature and our use of DITA expands.
Another main function of my role is to serve as the trainer and resident expert for all things DITA and Documentum, our CMS. Though a few of our writers were familiar with topic-based authoring, all of them were new to DITA. From a year before implementation through today, I have been educating our writers on DITA concepts and usage, content management best practices, and aspects of taxonomy and metadata. I do this in both formal and informal sessions. As writers’ comprehension develops, I introduce more complex subjects and processes. A major part of that education involved creating our department’s guide for DITA (written in DITA, of course!), which covers the concepts and usage particular to our environment.
DITAWriter: Where are you in your DITA implementation? What were you using before tool-wise and why did your firm make the switch to DITA?
Mike Kocik: Our DITA implementation has been live since January of this year. We are using DITA 1.1 with FrameMaker 11 as our authoring application and also as our PDF publishing application using the DITA-FMx plug-in. DITA-FMx also integrates the DITA-OT into FrameMaker nicely so that we can produce online help in CHM and WebHelp formats (though an additional pass-through using RoboHelp is required).
DITA 1.1 provides all of the necessary functions that our writers need at this point, though we hope to move to DITA 1.2 (or 1.3) as soon as our CMS supports it. This will allow us to use the Learning and Training specialization. (Our Training group is not yet using DITA, and there is a lot of potential there for reuse.)
Before DITA, we used FrameMaker (structured) to produce manuals and RoboHelp to produce online help. We moved to DITA for a few key reasons: It was becoming too timely and costly to localize our FrameMaker and RoboHelp source files, we needed a way to support multiple software configurations of one of our products without having to duplicate content, and we needed a more efficient way to produce printed documentation from our online help.
The move to DITA was somewhat gradual. First, we moved from an old structured FrameMaker template to a new FM template that used DITA elements as its structure. Then we moved to “full” DITA that completely eliminated writing in the FM file format.
So far, the implementation has been quite successful with the common “quick wins” (eliminating desktop publishing costs), and with increasing efficiency in our publishing methods. We are converting legacy FM content on a per-case basis (reuse potential, where the product is in its lifecycle, size of the content), and we are creating any new content in DITA.
DITAWriter: Can you tell me anything about the special challenges of creating documentation within the public health sector?
Mike Kocik: Because Carestream manufacturers medical devices, it is regulated by the FDA. Documentation in regulated companies is typically under higher scrutiny to make sure that the information we communicate does not cause harm to our users. Though manufacturers in other sectors also have that concern, for example, where electrical current or heavy machinery is involved, ours goes beyond that. With medical device content, incorrect information could ultimately lead to patient misdiagnosis through improper use or the failure to maintain the equipment properly. DITA topic re-use makes it easier for us to maintain content and warnings that are shared across our suite of manuals and help systems and ensures the information is consistently correct.
The particular challenges for our sector are the extensive approval cycles that our content requires and the controlled environment in which it’s stored. Before we can release/deploy our published content, it must be formally approved by as many as 12 different roles, which include Health & Safety, Regulatory, and Compliance. We must store that content in a validated system that provides version control and access control. Formally validating a CMS is a project in itself that can take several weeks to months, depending on the size and complexity of the system. When audited, we must be able to show traceability from the deployed content back to the source in our CMS.
DITAWriter: Given that DITA allows you to reuse content and that you have extensive checks and balances in place to verify any changes made, does that mean that a “pre-approved” topic in one document can be used automatically in another?
Mike Kocik: Good question, and one that I hear a lot! The short answer is ‘no,’ at least for companies like ours. People advocating (well-intentioned, I’m sure) for DITA will claim this as one of the benefits. The reason it’s typically not true is because the content must get approved in context of the entire deliverable (PDF, OLH, etc.) (The approved deliverable is known as the document of record.) For example, say that I wrote a DITA reference topic that listed all of the room dimensions required for a particular product’s installation. If approval were at the topic level, someone looking to reuse that topic could claim “hey, that one’s already been approved; I don’t have to send it in for review for the document I’m going to use it in.” But… then they find out that several aspects of the specs do not apply to their product’s document.
Now, that’s an oversimplified way of explaining it. In our sector, it would more likely be a reviewer saying “the second and third sentences of that notification don’t apply for the market where product X is being sold.”
DITAWriter: Traceability is becoming more an more of a factor in documentation processes in many sectors. How is this handled in your case?
Well, every auditor looks for something different, and with DITA, I expect auditors will have varying understanding of it. Because our approval system is separate from our CMS, we have to be pretty diligent around traceability. What we’ve had to show in the past (pre-DITA) was that we could find the source of a particular version of a document-of-record in our CMS, and that, if we were storing that d.o.r. (as a rendition) with the source, it was identical to what we deployed (CD or web portal). The first part of that statement we do using CMS metadata (e.g., “This version equates to Rev C in the approval system). The second part we can do with a simple checksum utility.
DITAWriter: At what level (tech writers or executives) was the decision made to go with DITA. And why DITA and not, for example, DocBook?
The DITA project got off the ground really from just the managerial level — my manager at the time plus her manager. It helped that I was able to put together a solution that wasn’t going to take multiple thousands of dollars and years to get to. I think DocBook was never considered (even from the start before I joined the company) because it had/has the stigma of being outdated and esoteric and that it lacked application support.
I am always interested in hearing more about people are implementing DITA. If you (and your company) are will to let me interview you, please let me know!
