Leveraging UDI Database Requirements to Drive Data Governance


Published on

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

Published in: Health & Medicine, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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 Control Provides 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 Requirements Preserves 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 Reporting Provide 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 Submissions Securely 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


  • Leveraging UDI Database Requirements to Drive Data Governance

    1. 1. May 21, 2014 Leveraging UDI Database Requirements to Drive Data Governance Rene Zoelfl Business Development Manager Medical Devices
    2. 2. 2MEDICAL DEVICES FDA’s Regulation on Unique Device Identification © 2014 PTC
    3. 3. MEDICAL DEVICES How this journey developed… © 2014 PTC
    4. 4. 4MEDICAL DEVICES “This rule is intended to substantially reduce existing obstacles to the adequate identification of medical devices used in the United States for safe and effective use… The rule would reduce medical errors that result from misidentification of a device or confusion concerning its appropriate use” Class II, Implantable (9/2015) UDI (Unique Device Identification) Regulatory Timeline PTC UDI solution released (9/2013) Class I, All (9/2018) Congress Mandates the unique identification of medical devices PTC R&D begins with the FDA and major device manufacturers FDA UDI proposed ruling Class III devices (9/2014) Class II, Other (9/2016) FDA UDI ruling published (9/2013) 2014-18: Enforcement begins for… FDA UDI Ruling Worldwide UDI regulations in work (April 2013, IMDRF) 2005 2007 2009 2011 2012 2013 2014 2015 2016 2018 492,000 adverse event reports / year 283,000 involved an injury 17,700 involved a death © 2014 PTC
    5. 5. 5MEDICAL DEVICES 5 Agenda © 2014 PTC • A checklist for FDA UDI compliance • Data management as lever for streamlined submissions – Current Situation – Challenges – Best Practices • How PTC solutions support UDI and data governance
    6. 6. 6MEDICAL DEVICES Executive Scorecard for a UDI Submission Solution © 2014 PTC Requirements, Should-Have’s, & Better to Have’s Compliance by the deadline System available to meet compliance deadline System supports 21 CFR Part 11 compliance* HL7 SPL (XML) Formatted submission Communicated to ESG (electronic submissions gateway) Capture acknowledgements from FDA Triage accept / reject / delayed status (7 days to correct**) High-level reportability for compliance across all products Collect and aggregate regulatory data centrally Templates / workflows / bulk load and approve Create, review, and approval permissions Connect to product development so GUDID data is current / UDI referenced in DHF (per 21 CFR Part 820.184) Connect to CAPAs/Complaints/NCs/Adverse Event reports (21 CFR Part 820.198) Architecture to accommodate future global regulations 124 days left to comply with the rule for class III devices
    7. 7. MEDICAL DEVICES Is there a single and reliable source of audit ready product data today? © 2014 PTC
    8. 8. 8MEDICAL DEVICES Problem Definition: Market and Regulatory Submissions Our observation: multiple systems house the 65 data points required by FDA © 2014 PTC FDA GUDID DB2 DB1 DB4 DB3 GDSN Future Global UDI Databases Global Providers US Providers Group Purchasing Org’s Product Changes New Geographies Internal processes / approvals .CIN .SPL .??? Market / eCommerce Data Regulatory Submissions .??? .???
    9. 9. 9MEDICAL DEVICES Our Recommended Approach for Streamlined Submissions © 2014 PTC SYNCHRONIZE CENTRALIZE HARMONIZE FDA GUDID DB2 DB1 DB4 DB3 Global Providers US Providers Group Purchasing Org’s GDSN Future Global UDI Databases Workflows/ Approvals .CIN .SPL .??? Changes / History Submissions/ Output Future Regulations submissions with unique market / regulatory needs data as changes are made upstream AGGREGATE REVIEW / CLEAN GOVERN
    10. 10. MEDICAL DEVICES What are the challenging parts? © 2014 PTC
    11. 11. 11MEDICAL DEVICES • Transparency about all devices falling under the rule – How many devices are affected at what deadline? • Clarity on – Which data are available? – Where are the 65 data points required for FDA UDI Submission housed within the organization? – Which data are electronically accessible? – Which data are correct for submission? – Are the data available in the required format? – Can the data be stored centrally? • What do the FDA required attributes mean? – i.e. what is brand name or the catalogue number in the context of the customer Where are all the data stored? Critical questions at the beginning © 2014 PTC
    12. 12. 12MEDICAL DEVICES • Who within the organization can validate the data? • Who is responsible for the program? • Need people in place that are dedicated to UDI – It isn’t just about submission, it is all about validation and maintenance – It isn’t solely an IT topic, but a regulatory challenge • How do I setup the account structure for communication with the FDA. Who is responsible within the Organization? Many stakeholders in many organizational units © 2014 PTC
    13. 13. MEDICAL DEVICES Best practices learned from the field How could the challenges be addressed? © 2014 PTC
    14. 14. 14MEDICAL DEVICES An approach to start with: UDI Requirements Assessment © 2014 PTC
    15. 15. 15MEDICAL DEVICES STAY COMPLIANT AND REDUCE THE RISK OF NEGATIVE AUDIT FINDINGS Best Practice I Data Governance ensure Accuracy and Uptodateness Automatically stay compliant as product data changes upstream, as required by the UDI rule. • Submissions Stay Current as Products Change – Live synchronization of UDI submissions with upstream data source(s) – As product data changes in upstream system(s), the system creates new or updated submissions • Available UDI Data Management – Centralized storage and management of UDI in a purpose-built UDI data model – Route to the right organizational roles via create/edit/review/approval workflows – Template and bulk-load capabilities for creation / approval of submissions – History and change/configuration management of UDI data to aid in future compliance with worldwide UDI regulations – Pre-submission validation using the same FDA algorithms used post-submission W H Y IT MATTER S W H AT IT MEA N S © 2014 PTC
    16. 16. 16MEDICAL DEVICES • Ensure data quality, integrity, and security – Capture and manage all required UDI information from multiple systems into a single data model • A single, centralized data model for e- commerce and UDI (starting with FDA GUDID) submissions – Scalable to future requirements while preserving data integrity and ease-of-use – Strong Integrations with other systems to rapidly pull UDI data into a single source • Centralize workflows, edits, reviews, and approvals – Pre-configured workflows route UDI information to the correct roles for review and approval • Keep business processes and roles aligned with e-commerce and regulatory data management needs REDUCE TIME AND EFFORT, IMPROVE ACCURACY OVER MANUAL METHODS Best Practice II Centralize Product and Regulatory Data Improve Efficiency and Reduce Risk with a single source of truth for product and regulatory data W H Y IT MATTER S W H AT IT MEA N S © 2014 PTC
    17. 17. 17MEDICAL DEVICES HELP ENSURE COMPLIANCE TO PROTECT FROM RISK Best Practice III Regulatory Compliance reducing risk and effort Extend compliance to include related industry requirements – with no additional effort • 21 CFR Part 11-Supportive Training – Completely pre-built, documented training developed and delivered by industry experts via eLearning and instructor-led options – Gain compliance faster by eliminating the need to create and conduct training internally • 21 CFR Part 11-Supportive Technology – Audit trail technology, electronic signatures, and secure review of electronic data – Complete solution validation package facilitates required validation process – Speed and streamline the audit process; help to reduce uncertainty and risk during audits • Accommodate Future UDI Regulations – Robust software architecture anticipates UDI regulations from future worldwide markets – Prepare to meet future global UDI rules and future changes to FDA UDI W H Y IT MATTER S W H AT IT MEA N S © 2014 PTC
    18. 18. MEDICAL DEVICES How did PTC reflect those best practices? © 2014 PTC
    19. 19. 19MEDICAL DEVICES DB4DB3DB2DB1 We designed our solution to facilitate data governance Lower the risk of noncompliance with accuracy, efficiency, traceability and scale  21 CFR Part 11- supportive technology  21 CFR Part 11- supportive training  21 CFR Part 830 – supportive solution  Solution technology facilitates validation  Accommodates future global UDI rulings Regulatory compliance Centralized Data Management Data Governance - Dynamic connections ensure changes flow down - Available centralized UDI regulatory data management with: - Bulk-load capabilities - Collection, control of data from disparate sources - OOTB workflow to create, review, approve submissions - Pre-built templates to bulk-create and bulk-approve - Pre-submission data validation with FDA algorithms - Change/configuration management of UDI data - Automatic data transformation - Human-readable PDF - Monitor and track FDA responses - Rejections/exceptions flagged for correction - High-level graphing and reporting - Historical record of submissions UDI data Centralized data if pre-existing OR… © 2014 PTC
    20. 20. 20MEDICAL DEVICES Revision control and data stewardship 5.0 PTC’s Unique Device Identification Solution ► Process Overview Collection of Data Review & Approvals e-signature Start Creation FDA Submission End Ongoing Change & Configuration Mgmt Regulatory Affairs 2.0 3.0 4.0 1.0 5.0 PLM Systems ERP Systems Home Grown Systems MDM Systems Doc & Labeling Systems Product “Specs” Collection of Products & key UDI attributes from Disparate systems – Automatic bulk Creation of UDI Objects & Initiation of Workflows 1.0 © 2014 PTC UDI Creator applies final edits to refines UDI submission then submits for approval 2.0 Generate HL7 SPL, submit to FDA Electronic Submissions Gateway (ESG) – Monitor Acknowledgments 4.0 E-Signature and review/approval workflows 3.0
    21. 21. 21MEDICAL DEVICES Technical Architecture Overview The PTC UDI Complete Solution Includes Services and Software Components. • PTC Core UDI Submission Engine – Manages Inputs, Workflows, Approvals, Configuration and Change • PTC Submission Cartridges – Manage formatting, communication & monitoring for Agency Submission Doc / Labeling Regulatory PLM ERP/MDM Spreadsheet Import UDI Database Create Wizard UDI Algorithm PTC Core UDI Submission Engine UDI Templates “Populate from Source Method” Calls Data Populators if used Wizard or Spreadsheet US FDA Cartridge © 2014 PTC
    22. 22. 22MEDICAL DEVICES Vision: Centralized Data Management © 2014 PTC Product Based Information – Design, BOM, Parts, Variants etc.. Document Based Information – SOPs, Policies, Quality Manual Quality Records Based on Products & Documents – CAPA, NCs, Complaints, Audits etc.. Design Manuf. Distribution & Use Support & Service Concept • A Documents Backbone - Manage & Control all key documents / Document Control • A Products Backbone - Provide Control of Product information / Design Control, DHF, DMR, BOM and BOO• A Quality Backbone – Quality Activities & Processes interact with the Anchor Points for Products and Processes Requirements Design Inputs Risk & Hazards Failure Modes Design Validation Design Reviews Regulatory submissions Material Compliance CAPA Nonconformance Manufacturing Process Plans Manufacturing Instructions CAPA Complaints CAPA Complaints Service Issues FDA Market Approval Enable streamlined data governance over the entire product life cycle
    23. 23. 23MEDICAL DEVICES Summary Corner Stones for a product data centric UDI implementation © 2014 PTC • UDI as regulatory must have or opportunity to drive future data quality and governance • Communicate and win stakeholders Develop Strategy and Scope • Systems and Owners • Gaps to UDI requirements • Inconsistencies Identify Data Sources • Data preparation and evaluation • Iterative approach; build, evaluate, define process • Review data quality at each iteration of test load Evaluate Data Quality • Improve process and data; solidify submission process • Be clear on ownerships Define Cleansing and Governance Process • Submission handling, and approval concept • Integration strategy Define submission procedure and triage concept