Delivered at the event “UDIs and Traceability for Medical Devices 2014” in Munich, May 21 – 22, 2014, Europe's only UDI-dedicated event for the medical device industry – with keynotes from the FDA and European Commission– this slideshare presents a Solution Provider’s perspective on the impact of Master Data on the UDI submission to the FDA UDI data base. In detail, the presentation highlights the following subjects:
- A checklist for compliance – What to consider when selecting a solution for UDI data submission
- Data management as a lever for streamlined submissions – Current situation, challenges, and best practices for establishing data governance within an organization
- How PTC solutions support UDI and data governance – PTC’s UDI solution and the broader approach for central product data management
PTC has spent the past two years – in partnership with the FDA and major medical device manufacturers – building a software solution to meet the proposed UDI requirement by helping companies ensure compliance in the most effective and efficient manner possible. (Optional: Set this up against possible homegrown tools they could spend time and money on but would strain resources and may not be as efficient / effective as possible in the short timeframe before compliance is required.)
For that reason, PTC is able to offer the first end-to-end tool for UDI compliance developed in partnership with the FDA, and with partners we are committed to helping achieve compliance by the mid-2014 deadline.
The history:
In June 2011, the FDA began to push the idea of a mandated UDI (Unique Device Identifier), and PTC began discussing how to handle this requirement via a PLM (Product Lifecycle Management) software solution. About a year later, at our PTC Live user event, the first UDI customer discussions took place with the major medical device manufacturers who already partner with PTC, and interest among customers began building.
Within its established relationship with the FDA, formal R&D at PTC began in order to create the first of its kind, end-to-end tool for UDI compliance. The tool will be in a state of early release to a set of PTC customers this June, with full release slated for this September.
UDI enforcement by the FDA begins in mid-2014, making this the perfect time to consider what your plan is for compliance with the new regulation, including
how you will manage the extensive up-front activities necessary to gain compliance in time, in order to not interrupt the sale of devices across state lines starting in mid-2014; and
how you will continue to manage UDI data going forward – including product versioning, new product development, variants of existing products, and the workload associated with managing compliance not just for the FDA regulation but for similar regulations in different markets on a continual basis into the future.
This is a complex problem that PTC began addressing early, working together with the FDA and major device manufacturers to determine how to solve it most effectively and efficiently. Homegrown tools – even if they began development today – would be time- and labor-intensive, would require significant IT involvement, and may not reach the levels of effectiveness and efficiency that PTC has already begun to prove out with current customers.
Cover page +deep-dive slides + timeline of in-house development (for ROI calc) + annotated appendix (where quoted In law) + screenshots of PTC software + internal competitive landscape set up +
Mike to provide 820/830 guidance / review + level of effort estimator for timeline for ROI competitive pricing discussion and timeline / not missing anything – Mike to do
Marcus to provide additional timeline info and cost / test cases / etc. – Dan has email out
Scott Barkman: time to build training program – Dan has email out or will send.
1) Requirements >> one pg. – supporting the law. (1 – requirements of the law) – part 830 (regulatory over to top page) (pink + page one) (headers for each to talk you through it: headers for page two: data management, training, software validation) + run down a comparison of time and $$ to build from Mike and Marcus to compare against doing it yourself in-house) (q/a, etc.) && put internal costs against this to get $$- and cost-justify our solution. (set up for testing with FDA – successful tests with FDA – so this should go onto p. 2 – practically supporting the law with a software solution)
2) Practically supporting the law (must-haves) (nice-to-haves) -- not absolutely required because you can go on FDA website – why software vs. manual submission – software usability requirements
(engage with prospects prior to a demo – any software should be able to do this. Can they check the box?)
(get this to consultants: consultant education session – Deloitte, PWC, etc. – use the same checklist) (because we answer it well)
Part 830
Requirements for a software system vs. manually? You buy a software tool because…
What if you can create HL7 SPL but doesn’t support Part 11? Compliant with ESG, not Part 11 – when compliance is noncompliance.
Part 820 (Quality System Regulations) – where it’s called out in FDA UDI – identify this to call out in this list. -- **Mike to give**
Risks against each of these sets – explore the risks – against requirements, must-haves, and better to haves.
Timeline defining developing in-house (steps around in-house vs. OOTB) – for a level of effort estimator: Software Validation piece. Develop / Test / Validate / Train all users
What we have = OOTB / validated / training program developed (for checklist) – time it took to build use cases, test cases, write and execute – how long does this take? Mike P. and Marcus T. – effort this took / timeline this took – should be for a level of effort estimator: level of effort it took a s/w company was X …
Part 11 (X)
Part 830 core – update tertiary system (complaints, DHF, DHR are required – need to own the data is another one to check off on here, for this) – 830.360 – records maintained by labeler – “records must be associated with a particular version or model” – should be tied to DMR – p.38 – requirement for DHR – UDI belongs in DHR
*Meeting 21 CFR Part 11 is requirement of the manufacturer – para. GUDID draft guidance for industry (will cite from final at eoNov.)p.26, section 4 paras 2&3 (p.26)
** Page ____
*** 21 CFR Part 830.50 para A and B
>> Risks against these; >> Set-up for Demo >> PDF version to leave with customer & encourage them to use as a needs-assessment & comparison doc. To set up ptc vs. alternate solutions (in-house, competitors, e-commerce) >> hand to consultants >> use internally to show how competitors compare >> Annotated pages of how we meet these requirements (screen captures) >> out to marketing for blogs, etc.
Submission + DM means our s/w extends
Client uses PTC software as a centralized “product data master” – GHX hex connected to center one –
Two options for labeler: submission + DM – needs DM – extends – changes, approval workflows, on LH side – submission output – CIN, SPL, etc on upper RH side and future regs
Change and Configuration ControlProvides complete management of definition updates and multiple submissions for various markets. Manage multiple product versions with UDI data associated to the product definition. PTC UDI maintains a link to the source data as changes are made, keeping the UDI data model updated with source data throughout the change and configuration process.
Future Global RequirementsPreserves a snapshot of submission records for accurate reporting, as required by the FDA, while maintaining data flexibility to allow for compliance with future regulatory requirements.
Advanced ReportingProvide for easy audit responses and recall traceability, as well as easy readability for communication throughout the enterprise.
Purpose-Built UDI Model Capture and manage all required UDI information from multiple systems into a single data model with robust history and version control. Scalable to future requirements while preserving data integrity and ease-of-use. Intuitively manage history, track changes, implement version control.
Pre-Configured Templates
Standardize training, capture and updating of UDI information, reviews, and approvals with a pre-configured data model based on the FDA regulation.
Strong Integrations
With other systems to rapidly pull UDI data into a single source. Once data link is established, changes flow-down from original source to UDI data model, presubmission, to ensure updates are captured and UDI data model is current. Excel bulk-loaders enable the migration of large quantities of legacy data for UDI submission.
Internal Reviews
Pre-configured workflows route UDI information to the correct roles for review and approval and captures eSignatures in compliance with 21 CFR Part 11
SPL Formatting
Automatically formats UDI data into the correct, SPL HL7 format required for FDA submission, while including a human-readable format for ease-of-use and communication throughout the enterprise. (An interesting anecdote “off the record” is that PTC brought the lack of “human readability” factor to the attention of the FDA and the FDA is now using our “human-readable” format to translate from the submission format to a human-readable form)
Secure SubmissionsSecurely and automatically publish information to the FDA’s GUDID with built-in reporting and traceability as required by the regulation.
Validated solution -
Actively Marketed Device Model is the level at which our pricing occurs – charging by different versions/variants of the same product family.
UDI is the level at which submission occurs, and includes different packaging configurations
SN + UDI have to be included on the device label, together, so this is one level DOWN from UDI – the SN is each individual manufactured item.
When the product changes, those changes have to flow down from the initial level (product family through to models, e.g., and/or if the change is made at the model level – either way, it has to flow down to the UDI submission and to the FDA so that the two remain synchronous so that you don’t risk falling out of compliance. Then (of course) the changes are manifest in the manufactured product (SN by SN – where the labeling reflects the new UDI) – NOTE that sometimes product changes require a new UDI submission and sometimes they require a revision to an existing UDI submission depending on which of the data points change.
Differentiators = Governance piece in its entirety; Manage and Synchronize for customers that do not have expensive ERP-based data management, relationship with FDA, reporting on overall compliance, creation of PDF, records maintained in-house, and UDI data model to manage UDI data centrally (if needed in place of an MDM or other centralized regulatory data management system) – including history / change config
Realizing_Interfaces_A15.ppt
The Technology piece:
PTC has a lot of technology solutions (CAD, SLM, ALM, SCM) and a system (through PLM) by which to manage and interconnect them.
We are leaders across these five critical business areas with the technology system and knowhow to flexibly connect all five, allowing us to drive transformation across the total product lifecycle and enterprise.
Our solutions, whether standalone or working together as a system, enable us to transform the way products are created and serviced so our customers can achieve ongoing product and service advantage
SYSTEM DETAIL SLIDES LOCATED IN THE APPENDIX