Risk Assessments:Patient Safety and Innovation

Innovation Discussion18 July 2013

FDASIA Group • Charter

– The Food and Drug Administration Safety and Innovation Act (FDASIA) directed the HHS Secretary, acting through the Commissioner of the U.S. Food and Drug Administration (FDA), and in consultation with ONC and the Chairman of the FCC, to develop a report that contains a proposed strategy and recommendations on • an appropriate, risk-based regulatory framework for health IT, including medical mobile

applications, • that promotes innovation, • protects patient safety, • and avoids regulatory duplication.

– The FDA, FCC, and the HHS Office of the National Coordinator for Health IT (ONC) will review and consider the recommendations provided by the Health IT Policy Committee, based on input from the workgroup, as the three agencies write the report.

• Goal: recommended regulatory framework for regulation of HIT

Why promote innovation?

• The problems in healthcare have not been solved.– Quality consistency– Knowledge implementation– Cost control

• Technology is a tool to solve problems– E.g., medication errors

• Transcription errors – cPOE• Ordering correctly – cPOE with decision support• Administration – medication administration with bar coding

• Need to attract more, not less participation in solving healthcare problems.

Work Product Approaches

• Exam Results from Current Regulation – Experiences with current regulation– Impact on innovation

• Develop Innovation Requirements – General requirements– Specific requirements - stratified by source of innovation

• Thoughts on new regulatory framework for HIT and

innovation

Question

What has been the impact of current regulatory approaches

on innovation?

IOM Report

• Government’s Role (IOM Report)

– “The government in some cases is the only body able to • provide policy guidance and direction to complement,

bolster, and support private-sector efforts and • to correct misaligned market forces.”

Shepherding Role versus Defining Role

Regulatory Approaches

• Medical Device regulation• Certification regulation

Measurement of Regulatory Impact on Innovation

General Attributes / Requirements

IOM Report, Appendix DStringency Innovation

Flexibility Innovation – Defined as the number of implementation paths to meet compliance.

.Information Innovation

– Defined as if a regulation promotes more or less complete information in the market.

Medical Device versus HIT

Physical Device• Physical• Long development /

enhancement cycles• Fixed functionality• Task oriented

– Measured against the task

• Environment of operation relatively defined and static

• Contributing suppliers more controlled and measureable

• Labeled use

Software• Virtual• Constant change

– Major releases, minor releases updates of currently running software

– Network connectivity: security, privacy, upgradeability

– Customization and configuration expectation– What does Pre-Marketing Approval mean when

distributing monthly updates?• Configurable by design• Tools to extend the products function• Can be process oriented vs single task

– Measured against practice impact, not individual tasks

• Environment (hardware, other software on hardware) more open

• Contributing suppliers layered with many contributions not specifically designed for healthcare – e.g., PC or phone operating system

• Extended use

Medical Device Regulation

Pros• Process control, not

outcomes – standard: – consistent

manufacturing process that can be applied to software

• Confidence in resulting product

Cons• Clarity

– Who is subject to regulation?– Implementation barriers –

knowledge & overly prescriptive

• Geared to physical devices – Turnaround time– Configuration and extension– “Class Up” effect on software

working with device

• Blood Bank use case• Issue:

– start small without regulation, but then applying regulation after the fact

ONC Certification Regulation

• Motivation: defined product– Government is funding a capital improvement to

healthcare practice (link to Meaningful Use)– Therefore, obligation to promote good products– Therefore, certification of the products

• Effect on Innovation:– Assumption of known Best Practice where not known– Specification of Best Practice and certifying specific test

behaviors limits innovation– Working to the test – “Compliance Innovation”

Certification RegulationRole of Measurement

• Policy– Intent, vision, goal– Outcomes orientation

• Measurement – test cases– Specific imagined implementation

“Not everything that can be counted counts, and not everything that counts can be counted.” – Einstein or Cameron

“You can only manage what you measure.” ~Deming

Certification RegulationOther Impacts to Innovation

• Timing and scope– The certification regulation is extensive and the time for compliance short– The result is that certification has been the development priority of companies –

removing bandwidth for other innovation

• Endorsement and empowerment of private certification regimens: SureScripts– Another certification involving “Best Practice”– Little option to avoid this certification even though not specifically mandated by

regulation– “Best Practice” defined in less transparent, less responsive system; i.e., private entity

• Constant reporting of “changes” to software with unclear consequence of triggering re-certification– Uncertainty increase causes innovation decrease – every incentive NOT to change– Does not fit with constant updates of software

Certification RegulationSpecific Recommendations to Promote Innovation

• Increase the flexibility of compliance– Define the desired features– Avoid specific implementations in the description– Increase flexibility of compliance certification

• Avoid requirements dependent on effectively a single source• Increase predictability

– Staging the definition of the requirements versus having a defined roadmap of features

– Re-certification criteria

Comparison of Approaches

Medical Device Regulation• Process control• Pre-marketing approval – in some cases• Impact

– Can be positive when combining software from different sources – increased trust

– Lack of clarity (flipside of Regulatory Discretion) yields policy uncertainty

– Entry impedance • Clarity on requirements & process – purpose

of AAMI report• Late entry into process with existing product

– Continued overhead: heavy process versus agile development

– If fully applied to HIT and local implementation, devastating to market – Blood Bank example

– Regulatory avoidance: dis-qualify for regulatory inclusion – taxonomy discussion

Certification Regulation• Product definition• “Best Practice” feature definitions• Pre-use approval• Impact

– Reduced flexibility (defined features), reduced innovation

– Empowered added private regulation– Non-productive work to test –

“Compliance Innovation”– Less market neutral – favors existing

software with defined features– Regulatory avoidance: control each

features and test script

Lessons LearnedRecommendations for a New Regulatory Framework

• Certification regimens should be used judiciously– When specifying specific implementations, they can narrow creativity and innovation to a specific or narrowed list of

solutions• Some instances where narrowing choices is desirable: e.g., interoperability standards

– Innovation impact• Channel energy into working to the test – compliance innovation• Channel the discussion to definitional terms rather than meeting the market needs

• Transparency of results to replace certification

– Instead of a certification process to differentiate the market, use transparency– Transparency in the marketplace is more efficient and richer in content

• Certification just reveals that the system passed the certification test and all vendors will – at that point, there is no differentiation

– Having a transparent, “learning system” would provide a continuous spectrum of solutions and their results; i.e., rather than knowing that all the vendors have med reconciliation (the end result of a certification system), it could be discovered which vendor does it better.

• National goals should be encouraged – JCAHO, Meaningful Use

– They meet the “flexibility” test (Appendix D – IOM Report)– Set problem agenda, not product agenda– They do change and, if well set, correct the market and create markets– Where the market goes, vendors will follow

Questions

What are the specific innovation requirements?

Stratified by level of innovation or opportunity for innovation

Sources of InnovationFull Spectrum of the SocioTechnical System

• Developed software – vendor and local• Software setup / customization / extensions– Integration with medical processes – sociotechnical

system• Combining technologies– Communication devices– Predictable combinations (e.g., HL7 interfaces)– Non-predictable combinations (e.g., end user

combination of available technologies – software and hardware)

Questions

• Use cases• Vended software• Local creation of software• Local configuration of software• Local extension of software – using provided tools• Local combination of technologies

– Communication devices– Interoperability: HL7 interface, service calls, database sharing,

• Questions for each use case– What are the innovation requirements?– What is the accountability model for safety and quality?

Vended Software• Innovation requirements

– Policy clarity• In / out of regulatory focus• Re-certification / re-authorization rules

– Consistent international regulatory framework– Interoperability Standards – mixed effect

• Increased innovation opportunity for small-scale product to plug into existing market; “development ecosystem”• Defined endpoint decreases innovation• Limited governmental direction; facilitate market driven standards

– Eliminate / minimize defined features / certification approach• Process controls can enhance innovation – trust method

– Goals – set problems-to-solve agenda for innovation– Provide pathway to become compliant with regulation after the fact of development– Transparency between suppliers and with consumers– Accept relative risk

• Shift some process control to post-distribution• Framework of non-punitive disclosure of issues

• Accountability model– National regulatory framework

• Consistent national and international standards• Transparency of process, artifacts, and results

Locally Developed Software• Innovation requirements

– Policy clarity• In / out of regulatory focus• Re-certification / re-authorization rules

– Interoperability Standards – mixed effect• Increased innovation opportunity for small-scale product to plug into existing market; “development ecosystem”• Defined endpoint decreases innovation• Limited governmental direction; facilitate market driven standards

– Eliminate / minimize defined features / certification approach• Process controls can enhance innovation – trust method

– Goals – set problems-to-solve agenda for innovation rather than feature agenda– Provide pathway to become compliant with existing software (i.e., software developed before regulatory focus)– Transparency into supplied software (locally developed software most often leverages pieces of software intended or not for

medical use)– Accept relative risk

• Shift some process control to post-distribution• Framework of non-punitive disclosure of issues

– Local process controls– Turnaround time: lightweight process adaptable to different level of development effort and scope– Iterative development / implementation cycles

• Controlled pilots with real patient data and informed users

• Accountability model– National regulatory framework

• National process controls – administered locally & available for audit• Local, continuous oversight• Surveillance: feedback loop of results• Local control , governance , and accountability for pilot use

Locally Configured Software• Innovation requirements

– Transparency into supplier process and results– Open communication of issues– Adequate training and documentation of supplied software– Local process controls: review, testing, implementation, and surveillance– None to little federal oversight: inheritance of supplier oversight

• Accountability model– Customer controls – medical entity accountability

• Integration with local medical processes• Testing of configuration• Training of end users• Surveillance of results• Reporting of local results

– Documented process and proof of compliance to documented process

Locally Extended Software• Innovation requirements

– Transparency into supplier process and results– Open communication of issues– Adequate training and documentation of supplied software– Local process controls: review, testing, implementation, and surveillance– Accept relative risk

• Framework of non-punitive disclosure of issues

– Turnaround time: lightweight process adaptable to different level of development effort and scope– Iterative development / implementation cycles

• Controlled pilots with real patient data and informed users

– Local process controls– None to little federal oversight: inheritance of supplier oversight

• Accountability model– Customer controls – medical entity accountability

• Integration with local medical processes• Testing of extended software• Surveillance of results• Reporting of local results• Local control , governance , and accountability for pilot use

– Documented process and proof of compliance to documented process

Local Combination of Technologies• Innovation requirements– Local process controls

• Accountability model– Expectations of suppliers

Summary of Recommendations

• National accountability– Use process controls, rather than product definitions– National and international standards for quality

process – measureable and transparent– National interoperability standards lower the entry

cost– Encourage configuration and extension to support

process and solve problems– Transparency of product and results– Support ability to experiment or iteratively develop

Summary of Recommendations

• Local control, local accountability– Design, document, and prove a local control system– Covers

• Local configuration of software• Local extensions of software• Ability to iteratively develop, implement, and measure

changes• Integration with medical processes• Training of end users• Feedback / results collection and analysis

Biggest picture(Regulatory Group)

Looking at the three agencies together, is there a better way to regulate HIT?

Goals for New Regulatory Framework

• Eliminate fraudulent or sloppy actors from marketplace – some regulatory impedance and accountability for entry into market

• Support innovation (innovation requirements from previous slides)

• Transparent results to support market forces (increase information in the marketplace); i.e., marketplace rewards and punishments

IOM Report

• To encourage innovation and shared learning environments, the committee adopted the following general principles for government oversight:– Focus on shared learning,– Maximize transparency,– Be non-punitive,– Identify appropriate levels of accountability, and– Minimize burden.

Learning Environment Requirements

• Increase Information in the Marketplace– Pre- and Post marketing information– Common reporting format– Providers and vendor contribution– Open access

• Environment– Non-punitive

Comparison

Current Regulation• Defined solution• Slow response to innovation

and problems• Opaque results• Discourages participation

Learning Environment• Multiple solutions• Continuous innovation• Continuous measurement

of results• Encourages participation