This is the article I recently wrote and sent to TechCraft.
______________________
Working for a noble cause
- Technical Writing in the Life Sciences and Health Care Domain
Those among us, who follow the technical writing mailing lists in India, are used to questions from freshers in the field on the career path of technical writers (TWs) after a few years in the profession. Another oft-repeated question is related to the perception about lack of respect to technical writers in an IT organization.
While responding to such questions, we see senior members of the profession advise the TW to focus on improving his/her skills and obtain domain knowledge- and both career growth as well as respect will follow. It is obvious that one of the main trends today is the increasing emphasis on domain-knowledge for the technical writer. And when a TW acquires domain knowledge, there could be a natural career progression, which may not be currently visible.
For TWs working in the IT industry, the Life Sciences and Health Care (LSH) domain offers an assured and exciting career path. In fact, there are very few domains that offer such varied opportunities and also give the individual a feeling that he/she is working for a noble cause – saving human lives and making this a better society for all of us.
Interestingly, questions related to the career prospects of TWs in this domain have been related to Bio-medical writing and not the regular writing for IT. Entry into the field as a medical or scientific writer requires knowledge of Pharma and Bio-chemistry terminology, and so, is very difficult for a TW working in the IT industry to make the transition to. However, there is a lot of technical writing involved in the IT side of the domain as well, one that does not require medical or scientific communication skills. Moreover, the LSH IT side provides a distinct career path for technical writers who are willing to learn about the domain and take up higher responsibilities for the software solution delivery.
Let’s take a quick dive into this domain now and see what I am talking about. To make it easier for us, I shall focus on just the sub-domain of Pharmaceuticals in this article.
Importance of IT in Pharma industry: It takes about $1 billion for drug firms to discover a compound, conduct clinical trials, obtain approvals from regulatory agencies and then release the product into the market. This whole process (from preliminary identification to market launch) takes around 7-8 years on average. Products lose their patent protection and become generic after 15 years. And since the patents are filed quite early in the process as Investigative New Drugs (INDs), companies have around 7 years to make the most of their drug.
Naturally, Pharma companies are always trying to cut down the cycle time on drug development and also cut the costs involved, while striving to maximize their post-launch returns. IT solutions can help in a big way in all these aspects. Therefore, it is not surprising that Pharma companies were among the first to adopt IT in all their business processes.
However, this industry operates in a highly regulated environment. Human lives are at stake, if even a minor mistake is made at any stage of the entire cycle. (And we all know that most software tools have some bugs or the other!) Regulatory agencies such as FDA in USA, MHRA in UK etc. monitor the research, clinical trials, manufacturing and distribution of the drugs. While doing so, they also investigate the use of IT systems and their impact on the Safety, Identity, Strength, Purity, and Quality (SISPQ) of the product. These agencies have also issued guidance to the industry on software development and maintenance, and formulated regulations on usage of electronic records and electronic signatures (ER: ES), Good Manufacturing Practices (GMP), Good Clinical Practices (GCP), Good Promotion Practices (GPP) and so on. In addition, there are other regulations governing Data Privacy (privacy of patient information etc.) such as SAFE HARBOR. The Pharma companies themselves know that their ‘data’ is their intellectual property, and they go to great lengths to ensure Information Security.
As you can see, there are a whole host of regulations under which the information systems have to be developed, installed and maintained. And guess what, the one underlying feature of all these regulations is that the company must show ‘evidence that they have the systems under control’. How is this evidence to be shown? Yes, it has to be ‘documented evidence’ and the documentation has to be in a ‘controlled state’ too!
It is very simple to do the math and figure that there will be a humungous amount of documentation being done at these companies. And as industry moves from paper-based to electronic records, the documentation will also involve all kinds of tools that you can imagine.
Big deal! Some of you may say. It looks like there is a lot of documentation to be done, but if we just create templates for all document types and then use a good document management system to automate the review and approvals process, we should be home safe and sound; where is the career path, you may ask.
That brings us to Computer Systems Validation (CSV).
The regulatory agencies expect the Pharma companies to ‘validate’ the IT systems so that there is a high degree of assurance that the system operates in a manner consistent with its documented requirements. Computer Systems Validation refers to those processes that provide this assurance through documented evidence of control. To hazard a simplistic definition, CSV is more like the typical QA process in software development and maintenance, with a few additional controls thrown in for good measure.
In this regulated IT environment, a system refers to the software, hardware, data and the business process, all put together. And when we ‘validate’ this system, we need to take everything into consideration, along with risk assessment, and regulatory compliance.
Again, this validation is not limited to the software development phase alone. It begins a little before the requirements stage (What can begin before requirements stage? Patience...we are getting there.), and in some cases may continue even after the system is retired. Yes, even after the system is retired, because we no longer have the system but we still have the data handled by the system, and regulations may require us to retain the data for inspection for 15 years or more after retirement.
CSV begins when the business sees a need for a new IT system. After the business case is approved, the business criticality and regulatory impact of the proposed system is identified. Based on this impact, a risk profile of the proposed system is drawn up. This risk profile documents the results of the risk assessment and the resulting decisions about how the proposed system will be validated.
These documents are then used to develop the Validation Plan, which is more like the Project Plan for a typical SW project. From here on, the process is a lot like the regular SDLC, till the system is in production. Supporting documentation (Standard Operational Procedures - SOPs) is produced for Security, Business Continuity, Disaster Recovery, Backup and Restore, Business Process (offline processes surrounding the system), Roles and Responsibilities document and so on, on an ‘as applicable’ basis. This is design-level validation.
To maintain the system thus designed in a state of validation, the living documents -requirements, design, and traceability, risk profile, business process, roles and responsibilities, and the change management SOP etc., are the most important artifacts. They need to be updated as and when there are some changes to the system. At a minimum, a periodic review of the system must be done once in a year. And the system must be re-validated after major upgrades, enhancements etc., based on the extent of changes to its requirements and design.
The inherent rigor of the process, the challenges involved in ensuring that business owners and system custodians implement the process thoroughly, and more importantly have documented evidence that every decision was thought through and reviewed by appropriate people, the need to justify any deviations from the stated process (deviations are inevitable, right?), the effort involved in revising the documents and maintaining them with proper revision history and version control – these are just a few of the complexities involved in the CSV compliance management. And so, the people who handle this process and deliver compliance are highly regarded in the organization. If compliance is an issue, the system may not go live, causing millions of loss. If system goes live without being compliant, an external auditor may discover the fact and it could result in the company losing its reputation, incurring heavy financial losses and in some cases, even the license to produce drugs. In short, this is a business critical activity in any pharmaceutical company. Not only because it’s a legal requirement and it makes business sense. More importantly, because ‘compliance’ is the right thing to do (ethical) as human lives are at stake.
Path for Technical Writers: Typically, one could start as a technical writer as one would do in any IT organization. At this stage, the TW will simply create documents taking inputs from the Validation Lead/Coordinator, or the SMEs for that system, both from the IT and business side. The TW will also be expected to route the documents for reviews and approvals, assist in creating the Validation Package, and maintaining the hard copy/electronic libraries.
By working on documents related to various platforms and applications, the TW will gain a solid understanding of the validation process for various systems involving diverse technologies.
At the next level, the TW would become a Validation Lead. The role involves working with the system custodian, the testing lead and the Quality representative, to define the Validation Plan and implement the same through the design validation phase and also managing the validation activities during the maintenance phase. If the services of a TW are not available, the Validation Lead is expected to execute that role as well.
The role of a Validation Coordinator or Validation Manager is more or less the same as the Validation Lead, with the exception that in this role, the individual may handle the validation for a large portfolio of applications or platforms ( in case of platforms, it is called Qualification of the platform). The Validation Manager also typically gets involved right from the business and regulatory impact analysis and risk assessment stages. In some organizations, the Validation Manager will be leading a team of Validation Leads and TWs.
Another stream open to people who spend a few years as a validation lead, is that of Business Integrators or Business Innovators (BI). This is more of an IT function. The role involves working with the business area, understanding their IT needs and providing them with various IT solutions that they can choose from. Once the solution is accepted, the BI works with the IT department to develop and run the system. The BI is in most cases the custodian for the system, and along with the business owner, is responsible for the validation of the system. The Validation team helps the BI in achieving the regulatory compliance. In many cases, the BI also performs several validation activities and signs on all the documents, as the system custodian.
In a sense, the BI performs the role of a bridge between the IT and business users. Isn’t that what seasoned technical writers do in many IT companies?
And the Validation Manager performs a role akin to a Technical Writing project manager, of course with a lot of business and regulatory understanding thrown in. The role is almost like a cross between a QA professional, a TW project manager and a business integrator. I am sure at least some of the senior professionals in technical communication departments have a role profile similar to this.
The advantage is that while there is a career progression from being a TW to that of a Validation Manager/Business Integrator and beyond, there will still be substantial involvement in actual writing, with the additional satisfaction of delivering the right kind of solutions that eventually enable safer and more effective medicines to be developed.
For those interested, a simple Google search for ‘Computer Systems Validation’ will throw up many resources that can help gain a clearer understanding of the profession. Technical writers with a flair for quality processes and a knack for understanding business processes should be able to make the transition without much difficulty.
______________________
Working for a noble cause
- Technical Writing in the Life Sciences and Health Care Domain
Those among us, who follow the technical writing mailing lists in India, are used to questions from freshers in the field on the career path of technical writers (TWs) after a few years in the profession. Another oft-repeated question is related to the perception about lack of respect to technical writers in an IT organization.
While responding to such questions, we see senior members of the profession advise the TW to focus on improving his/her skills and obtain domain knowledge- and both career growth as well as respect will follow. It is obvious that one of the main trends today is the increasing emphasis on domain-knowledge for the technical writer. And when a TW acquires domain knowledge, there could be a natural career progression, which may not be currently visible.
For TWs working in the IT industry, the Life Sciences and Health Care (LSH) domain offers an assured and exciting career path. In fact, there are very few domains that offer such varied opportunities and also give the individual a feeling that he/she is working for a noble cause – saving human lives and making this a better society for all of us.
Interestingly, questions related to the career prospects of TWs in this domain have been related to Bio-medical writing and not the regular writing for IT. Entry into the field as a medical or scientific writer requires knowledge of Pharma and Bio-chemistry terminology, and so, is very difficult for a TW working in the IT industry to make the transition to. However, there is a lot of technical writing involved in the IT side of the domain as well, one that does not require medical or scientific communication skills. Moreover, the LSH IT side provides a distinct career path for technical writers who are willing to learn about the domain and take up higher responsibilities for the software solution delivery.
Let’s take a quick dive into this domain now and see what I am talking about. To make it easier for us, I shall focus on just the sub-domain of Pharmaceuticals in this article.
Importance of IT in Pharma industry: It takes about $1 billion for drug firms to discover a compound, conduct clinical trials, obtain approvals from regulatory agencies and then release the product into the market. This whole process (from preliminary identification to market launch) takes around 7-8 years on average. Products lose their patent protection and become generic after 15 years. And since the patents are filed quite early in the process as Investigative New Drugs (INDs), companies have around 7 years to make the most of their drug.
Naturally, Pharma companies are always trying to cut down the cycle time on drug development and also cut the costs involved, while striving to maximize their post-launch returns. IT solutions can help in a big way in all these aspects. Therefore, it is not surprising that Pharma companies were among the first to adopt IT in all their business processes.
However, this industry operates in a highly regulated environment. Human lives are at stake, if even a minor mistake is made at any stage of the entire cycle. (And we all know that most software tools have some bugs or the other!) Regulatory agencies such as FDA in USA, MHRA in UK etc. monitor the research, clinical trials, manufacturing and distribution of the drugs. While doing so, they also investigate the use of IT systems and their impact on the Safety, Identity, Strength, Purity, and Quality (SISPQ) of the product. These agencies have also issued guidance to the industry on software development and maintenance, and formulated regulations on usage of electronic records and electronic signatures (ER: ES), Good Manufacturing Practices (GMP), Good Clinical Practices (GCP), Good Promotion Practices (GPP) and so on. In addition, there are other regulations governing Data Privacy (privacy of patient information etc.) such as SAFE HARBOR. The Pharma companies themselves know that their ‘data’ is their intellectual property, and they go to great lengths to ensure Information Security.
As you can see, there are a whole host of regulations under which the information systems have to be developed, installed and maintained. And guess what, the one underlying feature of all these regulations is that the company must show ‘evidence that they have the systems under control’. How is this evidence to be shown? Yes, it has to be ‘documented evidence’ and the documentation has to be in a ‘controlled state’ too!
It is very simple to do the math and figure that there will be a humungous amount of documentation being done at these companies. And as industry moves from paper-based to electronic records, the documentation will also involve all kinds of tools that you can imagine.
Big deal! Some of you may say. It looks like there is a lot of documentation to be done, but if we just create templates for all document types and then use a good document management system to automate the review and approvals process, we should be home safe and sound; where is the career path, you may ask.
That brings us to Computer Systems Validation (CSV).
The regulatory agencies expect the Pharma companies to ‘validate’ the IT systems so that there is a high degree of assurance that the system operates in a manner consistent with its documented requirements. Computer Systems Validation refers to those processes that provide this assurance through documented evidence of control. To hazard a simplistic definition, CSV is more like the typical QA process in software development and maintenance, with a few additional controls thrown in for good measure.
In this regulated IT environment, a system refers to the software, hardware, data and the business process, all put together. And when we ‘validate’ this system, we need to take everything into consideration, along with risk assessment, and regulatory compliance.
Again, this validation is not limited to the software development phase alone. It begins a little before the requirements stage (What can begin before requirements stage? Patience...we are getting there.), and in some cases may continue even after the system is retired. Yes, even after the system is retired, because we no longer have the system but we still have the data handled by the system, and regulations may require us to retain the data for inspection for 15 years or more after retirement.
CSV begins when the business sees a need for a new IT system. After the business case is approved, the business criticality and regulatory impact of the proposed system is identified. Based on this impact, a risk profile of the proposed system is drawn up. This risk profile documents the results of the risk assessment and the resulting decisions about how the proposed system will be validated.
These documents are then used to develop the Validation Plan, which is more like the Project Plan for a typical SW project. From here on, the process is a lot like the regular SDLC, till the system is in production. Supporting documentation (Standard Operational Procedures - SOPs) is produced for Security, Business Continuity, Disaster Recovery, Backup and Restore, Business Process (offline processes surrounding the system), Roles and Responsibilities document and so on, on an ‘as applicable’ basis. This is design-level validation.
To maintain the system thus designed in a state of validation, the living documents -requirements, design, and traceability, risk profile, business process, roles and responsibilities, and the change management SOP etc., are the most important artifacts. They need to be updated as and when there are some changes to the system. At a minimum, a periodic review of the system must be done once in a year. And the system must be re-validated after major upgrades, enhancements etc., based on the extent of changes to its requirements and design.
The inherent rigor of the process, the challenges involved in ensuring that business owners and system custodians implement the process thoroughly, and more importantly have documented evidence that every decision was thought through and reviewed by appropriate people, the need to justify any deviations from the stated process (deviations are inevitable, right?), the effort involved in revising the documents and maintaining them with proper revision history and version control – these are just a few of the complexities involved in the CSV compliance management. And so, the people who handle this process and deliver compliance are highly regarded in the organization. If compliance is an issue, the system may not go live, causing millions of loss. If system goes live without being compliant, an external auditor may discover the fact and it could result in the company losing its reputation, incurring heavy financial losses and in some cases, even the license to produce drugs. In short, this is a business critical activity in any pharmaceutical company. Not only because it’s a legal requirement and it makes business sense. More importantly, because ‘compliance’ is the right thing to do (ethical) as human lives are at stake.
Path for Technical Writers: Typically, one could start as a technical writer as one would do in any IT organization. At this stage, the TW will simply create documents taking inputs from the Validation Lead/Coordinator, or the SMEs for that system, both from the IT and business side. The TW will also be expected to route the documents for reviews and approvals, assist in creating the Validation Package, and maintaining the hard copy/electronic libraries.
By working on documents related to various platforms and applications, the TW will gain a solid understanding of the validation process for various systems involving diverse technologies.
At the next level, the TW would become a Validation Lead. The role involves working with the system custodian, the testing lead and the Quality representative, to define the Validation Plan and implement the same through the design validation phase and also managing the validation activities during the maintenance phase. If the services of a TW are not available, the Validation Lead is expected to execute that role as well.
The role of a Validation Coordinator or Validation Manager is more or less the same as the Validation Lead, with the exception that in this role, the individual may handle the validation for a large portfolio of applications or platforms ( in case of platforms, it is called Qualification of the platform). The Validation Manager also typically gets involved right from the business and regulatory impact analysis and risk assessment stages. In some organizations, the Validation Manager will be leading a team of Validation Leads and TWs.
Another stream open to people who spend a few years as a validation lead, is that of Business Integrators or Business Innovators (BI). This is more of an IT function. The role involves working with the business area, understanding their IT needs and providing them with various IT solutions that they can choose from. Once the solution is accepted, the BI works with the IT department to develop and run the system. The BI is in most cases the custodian for the system, and along with the business owner, is responsible for the validation of the system. The Validation team helps the BI in achieving the regulatory compliance. In many cases, the BI also performs several validation activities and signs on all the documents, as the system custodian.
In a sense, the BI performs the role of a bridge between the IT and business users. Isn’t that what seasoned technical writers do in many IT companies?
And the Validation Manager performs a role akin to a Technical Writing project manager, of course with a lot of business and regulatory understanding thrown in. The role is almost like a cross between a QA professional, a TW project manager and a business integrator. I am sure at least some of the senior professionals in technical communication departments have a role profile similar to this.
The advantage is that while there is a career progression from being a TW to that of a Validation Manager/Business Integrator and beyond, there will still be substantial involvement in actual writing, with the additional satisfaction of delivering the right kind of solutions that eventually enable safer and more effective medicines to be developed.
For those interested, a simple Google search for ‘Computer Systems Validation’ will throw up many resources that can help gain a clearer understanding of the profession. Technical writers with a flair for quality processes and a knack for understanding business processes should be able to make the transition without much difficulty.
Comments
cheers,
Kumar