Regulations, Documentation, and the Product Lifecycle

Worked for an architectural firm “back in the day.” Took the new house plans for review to the local governing agency, the county government. Plans were soundly rejected. It looked they had slaughtered a small animal on the blueprints. Heavily marked up with a red pen and a large rejected stamp on the cover sheet. Never had this problem before but created a new set with the required additions and took them back for review. Again, rejected with an entirely new sea of requirements. Spoke with the plan checker, “Dave,” who informed us that he was “going to clean up the county.” Created a new set of plans and again took them back for review. Asked for Dave, “oh, we fired Dave, give me your plans.” Immediately stamped approved on them and I was on my way.

Obtaining approval for any design relies on documenting, for the pertinent agency, that governing regulations have been met. In the case of a new house, it includes the review of the construction documents and subsequent in-field inspections during construction.

In the case of Medical Devices, it involves the creation of three documentation sets, all under the review and governance of the FDA CFR Part 820, the EU MDR, and ISO 13485.2016. Specifically, requirements for quality management, where an organization needs to demonstrate its ability to provide medical devices and related services that consistently meet customer and applicable regulatory requirements. These documentary sets are: The Design History File (DHF), the Device Master Record (DMR) and in the case of the FDA regulations, the Device History Record (DHR). These documents describe the entire lifecycle of a device, from concept and stakeholder requirements, to design development, hand-off to manufacturing, and the history of a specific unit or batch.

Historically, and even in the recent past, these documents were often gathered from various siloed sources at the end of design and incorporated into several large binders that attempted to describe the documents, decisions, and changes that occurred during the design efforts. In addition, large spreadsheets were created that again tried to capture the design intent, process, and results. A best practice is to show the relationships and linkages between stakeholder requirements, design inputs and outputs, and between design verification and validation in a traceability matrix. It might be possible to capture this in a spreadsheet if design were a straight-line effort, however, all design efforts are iterative processes with many changes and reworks along the way. Capturing the many changes that occur becomes a maintenance nightmare for the spreadsheet owner. Herding cats or straightening deck chairs—choose your metaphor.

At Aras we call this the ability to “Own the Lifecycle.” Success in product development, regulatory compliance, and digital transformation all depend on better ways to own your product’s information, end-to-end across the lifecycle. Ownership means that the information is immediately accessible, complete, accurate, and actionable by the stakeholders whose job it is to effect improvements. What’s more, data and technologies must be able to be transformed, to be used in new ways, as a result of the flexible approach of the platform they reside on. For a business to sustain transformation year over year—including the next technology and service innovations that haven’t even been dreamed of yet—information and actions must be managed end-to-end across the product’s lifecycle on a platform that can continually be added to, adapted, upgraded, and evolved to meet the company’s ever-changing strategic needs.

The benefits of owning your lifecycle are immediate, persistent, and valuable. They include:

  • Productivity gains that facilitate on-time product launches
  • Improved product quality and support with the ability to rapidly respond to changing customer demands
  • Supporting new markets, new service business models, and creating new product offerings
  • Faster and more assured regulatory compliance by capturing product data as it happens, not as an afterthought—risk avoidance
  • Face an audit with confidence knowing that information is held or federated into a single knowledge base, readily available
  • Development of a feedback loop for next generation products sharing operation and configuration information backwards in the lifecycle

This is the first of three blogs that lays out the premise that the only efficient way to document a medical device product’s lifecycle and “Own its Lifecycle” is within a modern, resilient Product Lifecycle Management (PLM) platform where all requirements and design decisions are captured, and a traceability matrix or digital thread is automatically created as design work proceeds; not as an afterthought or manual effort. Providing a view across the platform of the product as a system, along with the larger systems in which it exists and their impact, should persist throughout the lifecycle. The platform should provide visibility into requirements for every domain that contributes to the product’s definition, and it should maintain connections to requirements upstream from the product data downstream, out into service and operational phases, to ensure requirements are met.

Anonymous
  • Is there a way to trigger standard operating procedures (SOPs) at various phases of the product lifecycle as part of the process planning package? Additionally, can such SOPs be implemented within Aras as a workflow map of sorts to show conformance to regulatory authorities?