I started my career in TechComm fresh from the world of software. For the first 20 years of my career, I worked almost exclusively with software products. It was a world I understood. I knew how to talk to the SMEs. I could read code. I was familiar enough with underlying technology to be able to understand new products or features quickly.
But when I shifted my focus to training and consulting, I began to work with clients in different domains: telecom, hardware, networking, security, business services, and universities. I even trained the TechComm team at a major discount retailer, which was both disturbing and eye-opening.
All of these were different from my comfortable world of software, and while I enjoyed the variety, I never felt as excited by the products or underlying technology.
An exciting challenge
In 2002, I began a long consulting relationship with a local medical device company. Their product was innovative and non-invasive – no blood, no mess, no pain! It was a major improvement for patients who needed to undergo a certain type of medical test. For me, it was an easy introduction into the field of medical devices. Years later, I would find myself watching surgical procedures, viewing gruesome images of tumors, and working with ICU medical teams. In retrospect, I am grateful that I had such a gentle transition into medical device documentation.
Around this time, I was contacted by Rambam, one of the largest hospitals in Israel. They needed help with their research program – specifically, training young doctors and medical researchers to write better research papers. I led workshops with different teams and departments, teaching concepts of technical communication. Their work was exciting, compelling, and had a positive human impact that is often lacking in the software world. They were saving lives and I was hooked.
These first contacts led me to more medical device clients. Each was a new opportunity to work with a device that could reduce pain, speed healing, or improve patient outcomes.
But to succeed with these projects, I had to quickly adapt to the special requirements of medical device documentation.
What is different?
There are some significant differences between documenting a software product and a medical device.
1. Regulatory rules all.
The first thing to get used to is the pervasive influence of regulatory requirements. While other industries deal with regulatory and compliance issues, there are few other domains where the regulations are so specific to documentation. When writing an IFU (Instructions for Use, as most medical device user guides are called), there are strict regulations about the symbols used, how those symbols are documented, what content is expected (Intended Use, Contraindications, Warnings and Precautions, etc.). Ignoring these guidelines may cause the product to be flagged during a regulatory review.
Your goal: Remove any potential cause of friction with the regulatory reviewers while providing useful content for the end users.
2. There are different players.
I have documented dozens of software products without any contact with a Risk Assessment Specialist or a Regulatory Specialist. In fact, most of my software clients don’t have those job positions in their organization! But risk assessment is critical with medical devices. The Risk Assessment Specialist is the person who can analyze potential problems from the engineering and development side, as well as from the user side. The Regulatory Specialist has to be current with all the information from the various regulatory bodies and make sure that the product development, the product interface, and the documentation all adhere to requirements. The Risk Assessment Specialist has to coordinate closely with the Regulatory Specialist to make sure that risks are identified and properly mitigated, either through product design or documentation.
Your goal: Work closely with both these players to make sure that the documentation syncs with their goals.
3. People can die.
It is pretty hard to think of life-and-death risks that could be associated with a database application. But medical devices present serious potential risks. You will have to rely far more heavily on expert guidance from the SMEs.
Your goal: Take the risks seriously!
4. You cannot be squeamish.
If you feel nauseated looking at pictures of body parts or watching videos of surgical procedures, this is not the area for you! This is not a matter of right or wrong; rather, you need to think about your job satisfaction.
Your goal: Be honest with yourself.
5. Not every device makes it to the market.
Medical devices have to go through a far more rigorous vetting process before they can ever be released to the market. I have worked on several devices that were ultimately scrapped before ever becoming a viable product. As a contractor/consultant, of course I was paid for my work. But you may find it disappointing or discouraging if you are used to the world of software, where releases are frequent and almost never scrapped.
Your goal: Understand that not every great idea ends up being a practical, feasible medical solution.
What is the same?
1. What the client wants may not be what the users need.
As with any product, documenting a medical device requires balancing sometimes contradictory needs between what your client wants and what the actual end users need.
Your goal: Understand the project, do your analysis properly, and try to guide the client towards the correct content and deliverable.
2. You may have multiple user groups.
If you have ever documented networking software or large enterprise software, you are used to dealing with completely different groups of users who have completely different needs and tasks (for example, end users and system administrators). With medical devices, we often deal with three unique user groups: doctors, nurses, and patients. Each group has different information needs.
Your goal: Make sure there is correct audience analysis and provide the right deliverables for the different groups.
3. You are still the communicator.
Don’t expect medical device clients to be any better at communicating during a project than their software counterparts. Confusion, miscommunication, project changes, and all the same chaos you know and love from the software world also appear in the medical device world.
Your goal: Take responsibility for clear internal communication during a project.
A final disclaimer
I am neither a doctor nor a regulatory expert! I am merely a TechComm professional who has developed skills and experience within the niche domain of medical devices. When working with any medical device client, it is your responsibility to make sure that you can meet their requirements and expectations.
Further, you may have noticed that I didn’t mention pharma (pharmaceuticals). Documenting pharma (medications, drugs, etc.) is significantly different from documenting medical devices. I have no experience with pharma clients and cannot offer any advice other than to say that they have their own unique set of rules and regulations.
Do you have experience documenting medical products that you would like to share with the readers of tcworld? Let us know!