Interview Questions for Engineering Documentation

Engineering documentation encompasses a wide range of materials designed to communicate technical information. These documents are crucial for design, manufacturing, operation, maintenance, and safety. I’m familiar with many types, including:

• Design Documents: These detail the design specifications of a product or system, encompassing schematics, diagrams, calculations, and simulations. For example, a detailed blueprint for a bridge would fall under this category.
• Manufacturing Documents: These guide the production process, including bills of materials (BOMs), process flowcharts, and quality control procedures. A manufacturing process for a circuit board, with precise component placement diagrams, would be an example.
• User Manuals: These instruct end-users on how to operate and maintain a product. A user manual for a smartphone, explaining its features and troubleshooting steps, is a prime example.
• Technical Guides: These provide in-depth explanations of technical concepts or procedures, often aimed at technicians or engineers. Think of a troubleshooting guide for a complex piece of machinery.
• Maintenance Manuals: These documents outline procedures for regular maintenance, repairs, and troubleshooting. A maintenance manual for an aircraft engine, detailing inspection intervals and repair procedures, is critical for safety.
• Safety Manuals: These detail safety procedures and regulations relevant to the use and operation of equipment. A safety manual for a chemical plant, outlining emergency procedures and hazard identification, is paramount.
• Test Procedures and Reports: These outline the testing methods and document the results of tests conducted on a product or system. Detailed reports on stress testing of a bridge are an example.

The specific types of documentation involved heavily depend on the complexity and nature of the engineering project.

I have extensive experience with several authoring tools, including MadCap Flare and RoboHelp. I’ve used them to create everything from simple instruction sheets to complex, multi-volume technical manuals. MadCap Flare, in particular, is a powerful tool for single-sourcing content, allowing for efficient updates and consistency across multiple outputs (print, web, PDF). RoboHelp offers strong features for creating context-sensitive help systems and integrating with various software platforms. My experience involves not only creating the documentation itself but also managing the content structure, using features like templates, variables, and conditional logic to ensure consistency and scalability. For example, I’ve used Flare’s conditional build features to create different versions of a manual for different product configurations, avoiding redundant content creation.

Ensuring consistency and accuracy is paramount. My approach involves several key steps:

• Style Guides and Templates: Using a comprehensive style guide ensures consistent terminology, formatting, and writing style throughout all documentation. Templates pre-populate documents with consistent headers, footers, and other formatting elements. I create and rigorously enforce these.
• Version Control: I utilize version control systems (like Git) to manage changes, track revisions, and allow collaboration. This prevents conflicts and enables easy rollback if necessary.
• Peer Reviews: I always incorporate peer reviews into my workflow, ensuring that another set of eyes reviews the documentation for accuracy, clarity, and consistency before publication.
• Automated Checks: I leverage tools that can automatically check for spelling and grammar errors, broken links, and inconsistencies in formatting and style.
• Content Management Systems (CMS): For larger projects, a CMS provides central management of content, reducing the risk of inconsistencies and allowing multiple contributors to work simultaneously.

This multi-faceted approach ensures that the final documentation is not only accurate but also highly readable and user-friendly.

My process for creating user manuals or technical guides is iterative and user-centric:

1. Requirements Gathering: I begin by thoroughly understanding the target audience and the intended purpose of the documentation. This involves collaborating with engineers, designers, and marketing teams.
2. Information Architecture: I develop a clear structure for the document, outlining the topics and their logical flow. This often includes creating sitemaps or outline documents.
3. Content Creation: I write the content using clear, concise language and appropriate visuals. This involves incorporating screenshots, diagrams, and other multimedia elements to enhance understanding.
4. Review and Revision: Multiple rounds of review with stakeholders, technical experts, and end-users help identify and address potential issues with accuracy and clarity.
5. Testing and Refinement: I conduct usability testing with the target audience to identify areas for improvement in terms of clarity, navigation, and overall user experience.
6. Publishing and Distribution: Finally, I publish the documentation in the chosen format (print, online help, PDF) and ensure it is readily accessible to the end-users.

Throughout this process, continuous feedback loops are incorporated to ensure the quality and usefulness of the documentation.

Handling feedback is a crucial part of the documentation process. I treat feedback as an opportunity for improvement. My approach includes:

• Organized Tracking: I use a system (like a spreadsheet or issue tracking software) to systematically track all feedback, assigning priorities and deadlines for addressing each comment.
• Clear Communication: I maintain open communication with reviewers and stakeholders, providing timely updates on the status of addressing their feedback.
• Justification of Decisions: When changes aren’t made based on feedback, I provide clear justification for those decisions, ensuring transparency and collaboration.
• Revisions and Version Control: I document all revisions carefully, utilizing version control to track changes and facilitate easy rollback if needed.
• Follow-Up: After incorporating feedback, I follow up with reviewers to ensure they are satisfied with the changes made.

This process ensures that feedback leads to tangible improvements in the quality and accuracy of the documentation, leading to a better user experience.

Single sourcing is a content strategy where a single source of information is used to create multiple outputs. For example, a single paragraph in a master document could be reused in a user manual, a technical guide, and an online help system. This drastically reduces redundancy and the risk of inconsistencies. My experience with single sourcing is extensive, primarily using MadCap Flare. The benefits are numerous:

• Reduced Redundancy: Updating information only needs to happen in one place, saving significant time and effort.
• Improved Consistency: Ensures consistent terminology and style across all documents.
• Enhanced Maintainability: Updates are applied across all outputs simultaneously, simplifying maintenance and ensuring everyone has the latest version.
• Cost Savings: Reduces the overall time and resources required for documentation creation and maintenance.

I’ve successfully implemented single-sourcing strategies on several complex projects, resulting in significant improvements in efficiency and quality.

I am very familiar with DITA (Darwin Information Typing Architecture). DITA is an XML-based specification for creating modular, reusable content. Understanding DITA allows for the creation of highly structured and manageable documentation. My understanding extends to the creation and management of DITA maps, topics, and other elements, as well as the use of DITA processing tools for generating various output formats (HTML, PDF, etc.). I appreciate its ability to support single sourcing and its structured approach to information management. It is particularly useful for large, complex projects requiring extensive reusability and flexibility. While I haven’t had hands-on experience with every DITA editor, my knowledge of the underlying architecture allows me to quickly adapt to any DITA-based workflow.

Version control systems (VCS), like Git, are indispensable for managing engineering documentation. Think of it like collaborative writing on a shared document, but with a complete history of every change. Instead of overwriting files, Git tracks every alteration, allowing for easy rollback to previous versions if needed, and enabling multiple people to work on the same documents concurrently without conflicts.

My experience includes using Git extensively for managing documentation across multiple projects. I’ve utilized branching strategies to manage different versions of documentation (e.g., a ‘develop’ branch for ongoing updates and a ‘master’ branch for the stable, released version). I’m proficient in using Git commands like git commit, git push, git pull, git merge, and git branch to track changes, collaborate with team members, and resolve merge conflicts. I also leverage platforms like GitHub and GitLab for repository hosting, issue tracking, and collaborative review of documentation changes.

For example, on a recent project, we used Git to manage a large user manual. Each section was assigned to a different team member, and Git allowed us to merge their individual contributions seamlessly. If an error was discovered in a released version, we could easily revert to a previous, stable version using Git’s version history.

Managing documentation updates for large-scale projects requires a structured approach. I typically use a combination of tools and processes. First, a clear documentation plan is crucial. This plan outlines the documentation’s scope, target audience, update schedule, and responsibility assignments. A well-defined content management system (CMS) can simplify updates and collaboration. Many use wikis, or specialized documentation platforms, which have built-in version control and user access management.

For larger projects, I often employ a modular approach, breaking down the documentation into smaller, manageable chunks. This allows for parallel updates by multiple team members. A robust change management process is also critical. All updates should be reviewed and approved before being deployed, minimizing the risk of errors or inconsistencies. This often involves using a pull request system within the version control system (like Git) for review and approval before merging into the main branch. Regular updates and clearly defined update schedules ensure the documentation remains current.

Imagine building a house. You wouldn’t build the entire thing at once; you’d break it into sections (foundation, walls, roof). Similarly, a large documentation project needs to be broken down into smaller, manageable sections for effective updates.

Incorporating user feedback is crucial for creating effective documentation. I usually employ several strategies. Firstly, I integrate feedback mechanisms directly into the documentation. This can include providing feedback forms at the end of each chapter or section or using commenting features on online documentation platforms. Secondly, I actively solicit feedback through surveys, user interviews, and focus groups. These more structured methods can provide detailed insights into user needs and challenges.

Analyzing this feedback helps identify areas requiring improvement in clarity, completeness, accuracy, or organization. This feedback is then used to revise the documentation iteratively. Tools like user analytics on online documentation platforms can also provide valuable insights into usage patterns, identifying sections that users struggle with or commonly skip over. Tracking usage patterns allows for data-driven improvements, focusing changes where impact is greatest.

For instance, if user feedback consistently points to confusion regarding a particular process, I would revise that section to improve clarity and add visual aids or examples.

Ensuring clarity and accessibility in documentation is paramount. I achieve this through several methods. Firstly, I use clear, concise language, avoiding jargon wherever possible. If technical terms are necessary, I provide clear definitions. Secondly, I employ a logical structure, using headings, subheadings, and bullet points to organize information effectively. This makes it easier for users to find the information they need.

Visual aids like diagrams, charts, and illustrations can significantly enhance clarity. I focus on using visuals that are simple, clean, and easy to understand. Accessibility is ensured by using appropriate font sizes, sufficient contrast between text and background, and alt text for all images. I also ensure compatibility across different devices and browsers. Finally, I adhere to established style guides for consistency and readability. For example, a consistent tone of voice across the documentation ensures uniformity and improves comprehension.

Think of it like giving directions. Clear, concise directions with visuals (a map) will be much more effective than a rambling, unclear explanation.

Identifying the target audience is the first step in creating effective documentation. This determines the language, style, level of detail, and overall approach. The target audience could range from novice users to expert engineers. I gather information about the audience through various methods. This might include reviewing user personas (if available), conducting interviews with stakeholders, or analyzing user data if the documentation has already been published.

Understanding their technical proficiency, experience with the product or system, and their goals when using the documentation helps tailor the content appropriately. For example, documentation for experienced engineers can be more technical and concise, while documentation for novice users needs to be more explanatory and detailed. A thorough understanding of the audience ensures that the documentation meets their needs and is easily understood.

It’s like writing a recipe: a recipe for a seasoned chef will differ significantly from one for a beginner.

I have extensive experience creating documentation in various formats, each with its own strengths and weaknesses. PDFs are ideal for archiving and printing, offering a consistent visual experience across different systems. However, they’re less suitable for dynamic content or interactive elements. HTML is excellent for online documentation, allowing for interactive content, hyperlinks, and easy updates. Online help systems (like those integrated into software applications) provide context-sensitive assistance and often incorporate search functionalities.

My approach involves choosing the format best suited to the intended use and audience. For example, a user manual might be best delivered as a PDF for offline use, while an API reference guide is typically more effective as HTML with interactive elements and search capabilities. I’m proficient in using tools like MadCap Flare, Adobe FrameMaker, and various HTML editors to create high-quality documentation across different formats. The key is to select the format which best suits the audience’s needs and the intended method of access (online or offline).

Consider a restaurant menu. A PDF is great for a takeaway menu, while an interactive online version allows for easy updating of daily specials.

Creating effective diagrams and illustrations is crucial for enhancing the clarity and understanding of complex concepts. I use a combination of software and best practices. I often start by sketching out the diagrams on paper to plan the layout and content. Then I use vector graphics software like Adobe Illustrator or Inkscape to create professional-looking diagrams. For more technical diagrams, such as flowcharts or system architecture diagrams, I may use specialized tools like Lucidchart or draw.io.

My approach emphasizes simplicity and clarity. I avoid unnecessary detail and focus on conveying the essential information clearly and concisely. I use consistent styles and labeling throughout the diagrams for consistency and to avoid confusion. I also pay close attention to color schemes and fonts to ensure that the diagrams are easily readable and visually appealing. Importantly, I always include alt text to make the diagrams accessible to users with visual impairments.

Creating a good diagram is like telling a story using pictures. It should be easy to follow and visually engaging, conveying information efficiently.

Handling technical ambiguities in source material is crucial for creating accurate and reliable documentation. My approach involves a multi-step process. First, I carefully review the source material, identifying any unclear sections, conflicting information, or missing details. I then utilize several strategies to resolve these ambiguities. This might involve:

• Consulting subject matter experts (SMEs): I directly engage with engineers or other specialists to clarify the technical points. This includes creating a list of specific questions to ensure efficient communication.
• Reviewing related documentation: Often, answers can be found in other documents, specifications, or design files related to the subject.
• Conducting independent research: If the ambiguity persists, I conduct research using reliable technical resources to validate information and fill knowledge gaps. This could include reviewing industry standards or academic papers.
• Documenting assumptions and limitations: If complete resolution is impossible, I transparently document my assumptions and any limitations in the understanding of the material. This ensures readers are aware of potential uncertainties.

For example, if I encounter conflicting information about a component’s operating temperature range, I wouldn’t make assumptions. I’d directly contact the design engineer to clarify the correct value and document the source of the information to ensure traceability.

Compliance with relevant standards and regulations is paramount in engineering documentation. This ensures clarity, consistency, and safety. My approach ensures compliance through several key steps:

• Identifying applicable standards: I begin by identifying the relevant standards, such as ISO, IEEE, or industry-specific regulations, depending on the project type and the document’s purpose.
• Using standard templates and style guides: Many organizations provide pre-approved templates and style guides that adhere to these standards. Consistently using these ensures compliance from the outset.
• Regular reviews and audits: I conduct regular internal reviews of the documentation to ensure compliance. I often also participate in formal audits or inspections for adherence to these standards.
• Version control and traceability: Maintaining a version control system allows for tracking changes, ensuring that the latest version complies with current regulations. It also aids in traceability of approvals and modifications.
• Staying up-to-date: Industry standards and regulations are constantly evolving; I dedicate time to stay informed of any relevant updates and make necessary revisions to the documentation accordingly.

For instance, in documenting a medical device, compliance with FDA regulations like 21 CFR Part 820 would require meticulous documentation controls, design history files, and precise language to avoid ambiguity.

Style guides and templates are fundamental tools for creating consistent and professional documentation. I have extensive experience using these in various projects. They promote readability, maintain a uniform appearance, and save significant time.

• Understanding the purpose: Before using a style guide or template, I thoroughly understand its purpose and intended application. This includes understanding the formatting guidelines, terminology, and any specific requirements.
• Customization and adaptation: While I leverage existing style guides and templates, I also know when to adapt them to meet the specific needs of a project. This could involve adjusting the formatting or adding new sections to better convey information.
• Consistency and enforcement: I ensure strict adherence to the style guide and template throughout the documentation process. This maintains consistency and readability for the end-user.
• Training and collaboration: I ensure all team members understand and follow the style guide and templates. This often includes training sessions or collaborative workshops to ensure everyone is on the same page.

For example, in a previous project involving several different technical writers, we used a shared style guide in MadCap Flare, ensuring consistency in formatting, terminology, and graphic style across all generated documentation.

Managing multiple documentation projects simultaneously requires effective prioritization and organization. I use a combination of strategies:

• Project prioritization matrix: I use a matrix to rank projects based on urgency and importance. This allows me to focus on high-priority tasks first, ensuring timely completion of critical documents.
• Detailed project plans: Each project has a detailed plan with defined timelines, milestones, and deliverables. This allows for proactive tracking of progress and identification of potential delays.
• Work breakdown structure (WBS): Complex projects are broken down into smaller, manageable tasks. This improves organization and allows for better resource allocation.
• Time management techniques: I utilize techniques like time blocking and the Pomodoro Technique to optimize my workflow and focus on completing tasks efficiently.
• Regular communication and status updates: I maintain consistent communication with stakeholders, providing regular updates on the progress of each project. This ensures everyone is informed and allows for proactive problem-solving.

For example, I might prioritize writing the user manual for a critical software release over a less urgent training document. The project plans would specify deadlines, review dates, and resource allocation for each document.

Measuring the effectiveness of documentation is crucial to ensure it achieves its intended purpose. I use a variety of metrics:

• Usability testing: I conduct usability testing to evaluate how easily users can understand and use the documentation. This might involve observing users as they interact with the document or conducting surveys to gather feedback.
• Task completion rate: I measure the rate at which users can successfully complete tasks based on the documentation’s instructions. A high task completion rate indicates effective and clear instructions.
• User satisfaction surveys: Surveys help gather user feedback on the overall quality, clarity, and helpfulness of the documentation.
• Support ticket analysis: The number of support tickets related to the documented system can indirectly indicate the effectiveness of the documentation. Fewer tickets often suggest better clarity and completeness.
• Search analytics (if applicable): For online documentation, analyzing search queries reveals common user questions and areas needing improvement.

For instance, a low task completion rate in a usability test might indicate ambiguous instructions or missing information, prompting necessary revisions to the documentation.

Collaboration is essential in gathering accurate and complete information for documentation. I employ a variety of methods:

• Interviews: I conduct structured interviews with engineers and stakeholders to gather detailed information about the system or product. This allows for in-depth understanding and clarification of technical points.
• Workshops and meetings: Facilitating workshops or meetings with multiple stakeholders allows for collaborative information gathering and discussion of critical aspects.
• Documentation reviews: I actively solicit feedback from engineers and subject matter experts during the review process. This ensures accuracy and completeness of the information.
• Email and instant messaging: For quick clarifications or updates, I effectively use email and instant messaging to maintain consistent communication.
• Use of collaboration tools: I leverage collaborative platforms such as shared document repositories (e.g., SharePoint, Google Workspace) to ensure efficient information sharing and version control.

For example, to document a complex software system, I might conduct interviews with developers, testers, and product managers to gather information about various aspects of the system, from its architecture to its functionalities.

Technical illustrations play a crucial role in conveying complex information clearly and concisely. I ensure their effective integration using these methods:

• Identifying illustration needs: I start by identifying areas where illustrations would best clarify complex concepts or processes. This often involves reviewing the text and identifying potentially confusing passages.
• Collaborating with illustrators: I work closely with technical illustrators to convey information accurately and visually appealingly. This involves providing clear instructions, specifications, and any necessary technical information.
• Using appropriate illustration types: I choose the most suitable illustration type—diagrams, flowcharts, screenshots, etc.—depending on the information to be conveyed. The goal is to select the most effective and understandable representation.
• Ensuring clarity and accuracy: The illustrations need to be clear, accurate, and easy to interpret. I review every illustration carefully to ensure its accuracy and adherence to design standards.
• Proper formatting and integration: Illustrations are incorporated seamlessly into the document, using appropriate captions, labels, and cross-referencing. Their placement must enhance readability rather than disrupt the flow.

For example, to explain a complex network architecture, I would work with an illustrator to create a clear and concise network diagram, complete with labels for each component and data flow.

Building and maintaining a robust knowledge base is crucial for efficient knowledge sharing and problem-solving within an organization. My experience involves not only creating the initial content but also implementing strategies for ongoing updates, version control, and user accessibility.

For example, in a previous role at a software company, I spearheaded the creation of a knowledge base using a combination of a wiki platform (MediaWiki) and a robust tagging system. This allowed for easy categorization and searchability of documents ranging from troubleshooting guides to internal API specifications. We used a structured approach, defining categories and subcategories beforehand, ensuring consistency and logical organization. Regular reviews and updates, involving feedback from users, were a key part of the process. This iterative approach ensured the knowledge base remained relevant and helpful. We also implemented a system for version control, allowing us to track changes and revert to previous versions if needed.

Another example involved building a knowledge base for a manufacturing firm, focusing on standardizing maintenance procedures. This involved working closely with technicians to create clear, concise documentation using visual aids like flowcharts and diagrams, making it easily accessible even for those with limited technical writing experience. Success here meant reducing downtime and improving the efficiency of maintenance operations.

Translating complex technical information into easily understandable language requires a deep understanding of both the subject matter and the target audience. It’s about bridging the gap between technical jargon and plain English (or the appropriate language). This often involves simplifying complex concepts, using analogies, and avoiding unnecessary technical terms.

For instance, when explaining a complex algorithm, instead of using dense mathematical notations, I might use a real-world analogy like a recipe, breaking down the steps in a logical, sequential manner. Visual aids such as diagrams, flowcharts, and screenshots significantly improve comprehension. Active voice and concise sentence structures are crucial for clarity. I always strive to focus on the ‘what’ and ‘why’ before diving into the ‘how,’ ensuring the reader grasps the overall purpose before delving into specifics.

Consider explaining the process of cloud computing: instead of diving into complex architecture diagrams and networking protocols, I’d start with a simple analogy like comparing it to renting storage space rather than owning it. Then, I’d gradually introduce more technical aspects, ensuring each step builds upon the previous one.

XML (Extensible Markup Language) is a powerful tool for structuring documentation, particularly when dealing with large, complex projects. My experience encompasses utilizing XML for creating single-source publications, which means generating various output formats (like HTML, PDF, and EPUB) from a single XML source file. This approach ensures consistency and simplifies the update process.

I’m proficient in using XML editors and associated technologies like XSLT (Extensible Stylesheet Language Transformations) to transform XML data into different output formats. For example, I’ve used XML to create API documentation, leveraging its ability to structure information hierarchically, making it easy to navigate and search for specific functions or parameters. <function name="calculateSum"> <description>Calculates the sum of two numbers.</description> <param name="num1" type="integer"/> <param name="num2" type="integer"/> <return type="integer"/> </function> This XML snippet defines a function, its parameters, return type, and description, allowing for structured and easily parsed documentation.

The benefit lies in maintainability; a change made to the central XML file automatically reflects in all output formats, saving considerable time and effort.

Content Management Systems (CMS) are indispensable for managing and publishing documentation effectively. My experience includes using various CMS platforms like WordPress, Drupal, and dedicated documentation platforms such as Read the Docs and Sphinx. The choice of CMS depends on the project’s scale, complexity, and specific requirements.

Using a CMS streamlines the workflow by providing features like version control, user roles and permissions, and collaborative editing capabilities. For instance, in one project, we used WordPress with a custom plugin to create an internal knowledge base. The plugin allowed us to organize documentation into categories, manage user access levels, and track changes. This ensured that only authorized personnel could edit sensitive documents while keeping an audit trail of all modifications.

With Sphinx, I’ve created robust, searchable documentation for software projects, leveraging its ability to generate HTML, PDF, and other formats from reStructuredText or Markdown source files. The ability to integrate with version control systems like Git further enhances workflow efficiency and collaboration.

User testing is critical to ensuring documentation is effective and user-friendly. My approach involves a combination of methods, including usability testing, user surveys, and A/B testing.

Usability testing typically involves observing users as they try to complete specific tasks using the documentation. This allows me to identify areas of confusion, frustration, or ambiguity. I use think-aloud protocols, where users verbalize their thoughts and actions as they interact with the documentation, providing valuable insights into their mental models and understanding. For example, I might ask a user to find a specific procedure within the manual and observe how long it takes, noting any difficulties they encounter.

Surveys and A/B testing help quantify user feedback and assess the effectiveness of different writing styles or organizational structures. For example, I might compare two versions of a document, each with a different organization structure, to see which one users find more user-friendly.

Adapting documentation style to different audiences and purposes is essential for effective communication. The key is understanding the reader’s technical expertise, their goals, and their preferred learning styles.

For technical experts, detailed, technical descriptions with specific jargon are appropriate. For less technically inclined users, simple language, analogies, and visual aids are crucial. For example, a technical manual for engineers would include detailed specifications and diagrams, while a user guide for end-users would prioritize ease of understanding and simple instructions. The purpose also dictates the style. A quick-start guide needs to be concise and focused on essential steps, whereas a comprehensive reference manual needs to be exhaustive and detailed.

Consider writing documentation for a new software application. For software developers, the documentation would include detailed API specifications, class diagrams, and code examples. In contrast, for end-users, the documentation would emphasize ease of use, focusing on step-by-step instructions, screenshots, and frequently asked questions.

One challenging project involved creating documentation for a complex, newly developed medical device. The challenge lay in the high level of accuracy and precision required due to regulatory compliance and safety considerations. The technical specifications were highly intricate, and the target audience included medical professionals with diverse levels of technical expertise.

To overcome these obstacles, I implemented a multi-faceted approach. First, I worked closely with the engineering team to thoroughly understand the device’s functionality and limitations. Then, I created a detailed documentation plan outlining the scope, target audience, and deliverables. I used a modular approach, breaking down the documentation into smaller, manageable components to improve workflow. I also employed a rigorous review process involving subject matter experts and end-users to ensure accuracy and clarity. The use of visuals, including detailed diagrams and 3D models, significantly improved comprehension. Finally, we conducted extensive usability testing with medical professionals, incorporating their feedback to refine the documentation before final release, ensuring it met regulatory requirements and was readily understandable by its intended users. The result was a well-received documentation suite that satisfied regulatory requirements while ensuring ease of use and comprehension by medical professionals.