Extending Windchill part type with 40 custom attributes for medical device regulatory compliance

PLM Windchill
, , , , , ,
1

Our organization manufactures Class II and Class III medical devices and we recently completed a major Windchill 12.0 CPS05 implementation focused on achieving 21 CFR Part 820 and EU MDR 2017/745 compliance at the data model level. The core challenge was capturing regulatory metadata directly on part objects rather than relying on downstream document attachments or spreadsheet-based workarounds.

We extended the WTPart soft type hierarchy by creating three new subtypes: MedDevComponent, MedDevAssembly, and MedDevRawMaterial. Each subtype was built using the Type and Attribute Manager in Windchill, leveraging the soft type framework so that no source-code customization was required. Across the three subtypes we defined approximately 40 custom attributes, organized into logical attribute groups within the UI for usability.

Key attribute categories included: regulatory classification fields (device class, GMDN code, UNSPSC code), biocompatibility fields mapped to ISO 10993 testing requirements (biocompatibility status, test method, approval date), sterilization parameters (sterilization method, SAL level, EO residual limit), labeling attributes (UDI-DI, UDI-PI format, GUDID submission status), and supplier qualification flags (approved supplier list status, deviation authorization reference).

For enumerated fields like sterilization method and biocompatibility status, we defined controlled vocabularies using Windchill enumeration types to enforce data integrity. Mandatory attributes were enforced using Object Initialization Rules (OIRs), ensuring that when a part of type MedDevComponent is created, critical fields like device class and UDI-DI cannot be left blank during the save action.

We also configured attribute-level access control so that only members of the Regulatory Affairs role can modify the UDI and biocompatibility fields post-creation, which we handled through a combination of lifecycle state-based access policies and a custom Windchill business rule.

The outcome has been significant: audit readiness improved dramatically, DHF traceability reports can now be generated directly from Windchill queries against part attributes, and our regulatory team eliminated an estimated 1,200 manual data entry hours per product line annually. The OIR enforcement alone prevented several near-miss data quality incidents that previously required corrective actions.

2

One lesson from a similar project on WC 12.0 CPS04: be very careful about the number of indexed attributes you enable on custom soft types. We initially indexed nearly all of our custom regulatory attributes to support fast queries in table views and reports. This caused noticeable degradation in part creation and check-in performance as our part count grew past 80,000 objects. Work with your DBA to profile the wt_part and subtypeattribute tables before and after indexing decisions. We ended up selectively indexing only the six attributes most commonly used in search filters — device class, UDI-DI, biocompatibility status, sterilization method, approved supplier flag, and GMDN code — and that brought performance back in line. The Windchill query framework handles non-indexed soft type attributes reasonably well for ad-hoc queries, just not at scale for saved searches running on a schedule.

3

This is a great case study, thank you for sharing. I have a question about the OIR configuration specifically. When you set mandatory attributes at the OIR level for your MedDevComponent subtype, did you run into any issues with bulk imports via Windchill’s Import/Export framework? We have a similar compliance project and we’re worried that enforcing OIRs on 15+ mandatory fields will break our existing CSV import processes for migrated legacy parts. Did you have to create any exceptions or relaxed rules for migration contexts?

4

We went through a very similar exercise at our company for IVD products under IVDR. One thing I’d add is the importance of attribute group ordering in the Type and Attribute Manager. When you have 40 attributes, the default rendering in the part information page becomes unusable without deliberate grouping. We created five named attribute groups — Regulatory Classification, Biocompatibility, Sterilization, Labeling, and Supplier Qualification — and mapped each attribute to its group. This made the UI manageable for end users and also aligned with how our regulatory binders are structured, which made training much easier. Also, for enumeration types specifically, make sure you plan for multi-language support early if you operate in multiple regions — adding that retrofit is painful.

5

Good question, Dana. Yes, we absolutely hit that wall during our migration phase. The OIRs as configured in the Type and Attribute Manager fire during standard object creation and save operations, which does include the Windchill Import utility. Our approach was to define a separate ‘MedDevComponent_Migration’ soft type with the same attributes but without mandatory OIR enforcement. We bulk-imported legacy parts into that staging type, then ran a custom Windchill workflow that prompted regulatory SMEs to validate and populate the mandatory fields before promoting the part to the full MedDevComponent type with a type-change operation. The type-change was done via a Windchill customization using the WTPartHelper API. It was extra work upfront but it gave us clean production data. I’d strongly recommend against relaxing OIRs permanently in production — the whole value is the enforcement.