The fourth example entry from my seemingly endless engineering experience record for the PEO. In this job I took on a more challenging role in western Canada within a medical device startup and grew into a senior position, including management type responsibilities.
Work Experience
Once again, not supervised directly by a P. Eng., but part of a division of the organization headed by a professional engineer (not in Ontario, by the way).
| Start Date | (2011-ish) |
| End Date | (2012-ish) |
| Company | Growing Medical Startup |
| Position | Software Product Developer |
| Supervisor | (Not A P. Eng.) (Mailing address) |
| P. Eng. Reference | (A senior executive above me in the org. chart, a P. Eng.) (Mailing address) |
| Responsibilities | Lead software developer and team lead for the console software on the (Product Name) imaging system for open surgery. An FDA-approved imaging system that provides real-time visualization of a patient's vascularity and perfusion during surgery. |
2.2.1 Application of Theory
| Analysis | I used continuous automated testing to perform a reliability and stability analysis for the system software, prior to software release and also when investigating reported software issues. Through this testing, I measured the frequency of software failures and mean time to failure in various scenarios. As software stability was improved, an improvement from less than one hour between failures to > 24 hr operational time was observed. |
| Design and Synthesis | I led the design and development of upgrades to the console software, in order to increase the quality and usability of the software. As noted above, the resultant increase in stability was measurable. The console software relied on several off-the-shelf (OTS) software components. It was my responsibility to test, select, and replace these components as needed (due to either functionality or cost concerns). I selected the OpenCV library for image processing tasks, replacing Matlab. I also selected Microsoft's Reporting component to replace Crystal Reports. These component replacements resulted in increased software stability and reduced licensing costs. |
| Testing Methods | I led the implementation of a fully automated continuous integration and testing regime, whereby each software change was immediately compiled, installed onto an online medical imaging device, and run through continuous tests with the results delivered to developers via e-mail. |
| Implementation Methods | Initially field software upgrades were performed exclusively by technicians, due to the upgrade complexity. I developed a simpler software install package that allowed the upgrade to be performed by the clinical specialist, resulting in significant cost savings for deployment. |
2.2.2 Practical Experience
| Function of components as part of the larger system | The console software represented one component in a complex system that also included an on-board PC, imaging hardware (2 cameras, 1 near-infra-red laser), a laser controller with control firmware, and all interconnecting hardware (cables, laser fibre, etc.). I investigated many reported system failures and this required in-depth knowledge of the entire system, as a reported symptom could manifest as the result of the failure of a software or hardware component and pinpointing the cause was rarely trivial. |
| Limitations of practical engineering and related human systems in achieving desired goals | The console software ran on a Microsoft Windows based PC. The stability of the software relied on a functional operating system. I found that a number of field-reported issues were the result of users (hospital OR staff in a time-sensitive environment) simply disconnecting the machine's power source in order to initiate a shutdown (as opposed to using the system's power button). These abrupt system shutdowns adversely affected the operating system and, hence, the console software. This represented one of many instances highlighting the importance of thorough user training to ensure the proper operation of the device. |
| The significance of time in the engineering process | One member of our software testing team was located remotely, in a different time zone. I managed and directed his QA activities and this required significantly more planning and proactive communication than for local team members. |
| Knowledge and understanding of codes, standards, regulations and laws that govern applicable engineering activities | This was my first experience working on an FDA-approved medical device. I was trained on and functioned within the company's rigorous quality management system (QMS) in an environment where any changes to the product specification, design, production and maintenance procedures, etc. required review and sign-off. I also supported the regulatory team in providing technical input to documents for the FDA and European CE marking. |
2.2.3 Management of Engineering
As was the case here, you’ll find that with more experience and an increasingly senior role, it becomes progressively easier to find applicable content for sections such as these. The proof is in the pudding: no N/A’s in this write-up.
| Planning | Along with the product manager, I performed the requirements gathering and functional specification efforts for version 2.0 of the system software. This included meeting with users of the system (clinical specialists and physicians), product stakeholders (management, production team), and internal technical team members. Based on this information, I authored the initial software requirements specification (SRS) and development plan for version 2.0 of the console software. |
| Scheduling | As software team lead, the estimation, prioritization, and assignment of development and testing tasks were shared between myself and the product manager. |
| Budgeting | Management and maintenance of software licenses for off-the-shelf software was my responsibility. One software package we held licenses for was MATLAB. Piece-by-piece, I drove efforts to replace and reduce our dependency on MATLAB and therefore lower its significant licensing costs. |
| Supervision | Initially, console software development was handled by an external consultancy. As the first internal developer on the console software, I reviewed resumes of and interviewed prospective new team members. I was part of the decision-making group that selected successful applicants. I trained new software developers and testers who became part of the small team focused on the console software. As team lead, I was the software architect and technical lead. I prioritized development and testing tasks for team members. I was the communication point between the team and management. |
| Project Control | During development of version 2.0, I maintained a dynamic development schedule, which estimated the release date for the software. As business requirements evolved, the schedule was analyzed and changed, adjusting the feature set to the new expectations of the customer and accelerating the development schedule to achieve a new market release date. |
| Risk Assessment | Risk assessment is a formal requirement under most medical device regulations (e.g. FDA). For each software design change, previous risk assessments for the software and system as a whole were reviewed and, if needed, adjusted to reflect the new design. The major reason for decoupling the console software from the laser controller software were the risks of the latter far outweigh that of the former. The decoupling allowed the frequent changes to the console software (which had no direct interaction with the patient) to be of lower risk. |
2.2.4 Communication Skills
| Preparing written work | I authored and updated several software documents including a software requirements specification (SRS), software design description (SDD), software release notes, software test plans and test reports. |
| Oral Reports or Presentations | I frequently performed product demonstration presentations for potential investors and collaborating companies. |
| Presentations to General Public | A group of engineering students were toured around our facilities and given presentations on the engineering work being performed. I participated in these presentations. |
2.2.5 Social Implications of Engineering
| The value of benefits of engineering work to the public | Enabling surgeons to visualize perfusion in real-time, during surgery, which was previously not feasible, enables improved patient outcomes during procedures such as plastic reconstructive and wound care surgeries. I witnessed, directly from surgeons, testimonials as to the effectiveness of the technology. |
| The safeguards in place to protect the employees and the public and mitigate adverse impacts | Regulations demanded that we have a CAPA (Corrective Action, Preventative Action) procedure in place. The procedure required us to react immediately and decisively to resolve problems with the device and also to proactively anticipate and prevent problems that could occur in the future. I participated in several CAPA instances, which had me performing a technical investigation into the problem and writing a report on the findings. |
| The relationship between engineering activity and the public at large | I documented, in accordance with FDA regulations, all product feedback that I received first-hand. Although this did not occur during my tenure, I was trained to know that any adverse events involving the device that endangered patients must be reported to the FDA and general public. |
| The significant role of regulatory agencies on the practice of engineering | The entire product development cycle within which the engineering team operated was shaped, in large part, by the demands of the regulatory bodies (e.g. FDA) and standards organizations (e.g. ISO 13485) overseeing the medical device domain. All development, testing, and field activities resulted in documented artifacts, reviewed and approved by engineers and management at all levels. Although time-consuming, the QMS ensured a high-quality product. |