Architects and engineers develop architectural drawings with the intent to communicate the designers understanding and execution against local, regional, and national design standards and regulations. The completed set of documents are submitted for review and approval. This set of drawings becomes the “approved construction set.” After construction, another set of drawings is often created. This set of documents is known as “as-built drawings” or “record drawings,” which document exactly how the building was constructed, capturing any deviations or modifications to the original approved construction documents. For the contractor, the drawings provide a clear record of changes made during construction and can clarify any problems going forward in the later construction phases. For the building owner they are invaluable if later modifications are contemplated or for troubleshooting if problems arise. They become the documents of record if legal issues occur.
In the Medical Device field, in addition to the Design History File (DHF) and the Device Master Record (DMR), another document set is required, which is basically the as-built documentation of a manufactured specific batch, lot, or unit. FDA quality regulations set out the following requirements.
Each manufacturer shall maintain Device History Records (DHR's). Each manufacturer shall establish and maintain procedures to ensure that DHR's for each batch, lot, or unit are maintained to demonstrate that the device is manufactured in accordance with the DMR and the requirements of this part. The DHR shall include, or refer to the location of, the following information:
- The dates of manufacture
- The quantity manufactured
- The quantity released for distribution
- The acceptance records which demonstrate the device is manufactured in accordance with the DMR
- The primary identification label and labeling used for each production unit
- Any unique device identifier (UDI) or universal product code (UPC), and any other device identification(s) and control number(s) used
As explained in two previous blogs “Regulations, Documentation, and the Product Lifecycle” and “Regulations, Documentation, and the Digital Thread” the DHR is difficult to generate if the information is trapped in siloes of domains, documents and spreadsheet records. It is much easier to accomplish if the information is kept in a Product Innovation Platform such as Aras Innovator. Inherent in the platform is a Digital Thread enabling full product lifecycle traceability, allowing previously siloed teams across the enterprise to work concurrently with the latest product information. It facilitates the generation of the DHF and DMR by creating connections to critical information, allowing you to track a product and its digital assets, from concept, through design, manufacturing, quality, and field maintenance. In the same manner, the generation of the DHR is a byproduct of the connectivity and data accessibility within the platform.
All well and good, time saved, improved product quality, and risk avoidance in being compliant. The interesting part of this is that in generating the DHR you may have also created a Digital Twin of the product instance and opened exciting new business opportunities.
A point of clarity here—what a Digital Twin is and what it is not. First what it is not—a Digital Model of a product that has yet to be built. Or simply a representation of what might be with only a passing resemblance to actual products in the field. The DHF and DMR describe what can and should be and how it is to be manufactured but a lot happens along the way—exceptions, part replacements, supplier changes, and design changes have likely occurred. Only when that product is done with its manufacturing process, and its configuration, including electrical, mechanical, and software has been recorded, can the DHR and the first Digital Twin be created. The DHR and a true Digital Twin, faithfully and fully describe an actual instance of a product as required by regulations and required to expand business operations outside of the design and manufacturing domains of the lifecycle and into Operations and Maintenance.
Maintenance is all about keeping products working and prolonging their life. To do this organizations must be effective at maintenance which is defined as performing work according to a defined plan to mitigate the consequences of failure―and doing the work in a cost-effective manner. Over time, as maintenance is performed with the physical product, some information about how it has changed, is lost. This loss of context results in sending the wrong people, parts, or tools out to a job, which results in an increased cost of maintenance, less work being performed, longer downtimes that raise production costs, all of which reduce a maintenance organization’s effectiveness. An effective Digital Twin configuration, connected to critical information using the Digital Thread, will provide the context you need to avoid common issues.
With a true Digital Twin, foundationally built on a Digital Thread, within a Product Innovation Platform, several possibilities are available to support maintenance including improved accuracy of your predictions for downtime and outages. Information accuracy to perform work management, right people, tools and parts for the right product for diagnosis and information access. Current contextual simulations to repeat anomalies; working towards workable solutions.
This is the final in a three part series that explores 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. The first two in the series are: “Regulations, Documentation, and the Product Lifecycle” and "Regulations, Documentation, and the Digital Thread." You can learn more at our web site: https://www.aras.com/en/industries/medical-devices.