Presentation is loading. Please wait.

Presentation is loading. Please wait.

February 6, 2015 Health IT Implementation, Usability and Safety Workgroup David Bates, chair Larry Wolf, co-chair.

Similar presentations


Presentation on theme: "February 6, 2015 Health IT Implementation, Usability and Safety Workgroup David Bates, chair Larry Wolf, co-chair."— Presentation transcript:

1 February 6, 2015 Health IT Implementation, Usability and Safety Workgroup David Bates, chair Larry Wolf, co-chair

2 Workgroup Members David W. Bates, Brigham and Women’s Hospital (Chair) Larry Wolf, Kindred Healthcare (Co-Chair) Joan Ash, Oregon Health & Science University Janey Barnes, User-View Inc. John Berneike, St. Mark's Family Medicine Bernadette Capili, New York University Michelle Dougherty, American Health Information Management Association Paul Egerman, Software Entrepreneur Terry Fairbanks, Emergency Physician Tejal Gandhi, National Patient Safety Foundation George Hernandez, ICLOPS Robert Jarrin, Qualcomm Incorporated Mike Lardieri, North Shore-LIJ Health System Bennett Lauber, The Usability People LLC Alisa Ray, Certification Commission for Healthcare Information Technology Steven Stack, American Medical Association Mickey McGlynn, Cerner Ex Officio Members Svetlana Lowry, National Institute of Standards and Technology Megan Sawchuck, Centers for Disease Control and Prevention Jeanie Scott, Department of Veterans Affairs Edwin Lomotan, Agency for Healthcare Research and Quality-Health and Human Services Betty Mims Johnson, Department of Veterans Affairs ONC Staff Ellen Makar, (Lead WG Staff) 2

3 HIT Implementation, Usability and Safety Draft Workplan MeetingsTask January 14, 2015 3:00PM-5:00PM ET EHRA presentation of collaborative work on usability efforts February 6, 2015 1:00 PM-3:00 PM ET Quality Management Systems Overview AHRQ Special Emphasis Notice February 20, 2015 1:00 PM-3:00 PM ET Vendor QMS Certification Criteria March 10, 2015 – HITPC Meeting Anticipated date to be charged by the HITPC with commenting on the Certification NPRM March 19, 2015 9:00-11:00am ET Certification NPRM overview and prepare to comment (anticipated date for planning purposes) March 26, 2015 11:30am-1:30pm ET Comment on Certification NPRM (anticipated date for planning purposes) April 3, 2015 2:30-4:30pm ET Finalize NPRM Comments (anticipated date for planning purposes) April 21, 2015 12:00-2:00pm ET TBD- Possible implementation discussion- (Medication Reconciliation example) May 1, 2015 2:30-4:30pm ET TBD May 12, 2015 – HITPC Meeting Certification NPRM Comments to the HITPC (anticipated date for planning purposes) May 11, 2015 11:30am-1:30pm ET RTI report out on the Safety Center Road Map

4 Agenda Objective: Presentations of Quality Management Systems used in HIT software design and the AHRQ Special Emphasis Notice: Interest in Research on Health IT Safety 1:00 p.m.Call to Order/Roll Call Michelle Consolazio, Office of the National Coordinator 1:05 p.m.Review of Agenda David Bates, chair Larry Wolf, co-chair 1:10 p.m.2014 Edition Certification Criteria: Quality Management System Quality System Principles for Health IT Development Sherman Eagles and Alan Kusinitz, SoftwareCPR 1:40 p.m. Group Discussion 2:15 p.m.AHRQ Special Emphasis Notice: Interest in Research on Health IT Safety Teresa Zayas Cabán, PhD, Chief of Health IT Research, Division of Health IT, Agency for Health IT Research and Quality 2:30 p.m. Group Discussion 2:45 p.m. Public Comment 3:00 p.m. Adjourn 4

5 2014 Edition Certification Criteria: Quality Management System §170.314(g)(4) Quality management system. For each capability that an EHR technology includes and for which that capability's certification is sought, the use of a Quality Management System (QMS) in the development, testing, implementation and maintenance of that capability must be identified. – (i) If a single QMS was used for applicable capabilities, it would only need to be identified once. – (ii) If different QMS were applied to specific capabilities, each QMS applied would need to be identified. This would include the application of a QMS to some capabilities and none to others. – (iii) If no QMS was applied to all applicable capabilities such a response is acceptable to satisfy this certification criterion. Test procedure: http://www.healthit.gov/sites/default/files/170.314g4qms_2014_t p_approvedv1.2.pdf http://www.healthit.gov/sites/default/files/170.314g4qms_2014_t p_approvedv1.2.pdf 5

6 Quality System Principles for Health IT Development Sherman Eagles and Alan Kusinitz SoftwareCPR 6

7 HIT systems can be very complex and there are many ways during development that an error can be caused 7

8 Draft FDASIA report priority areas for Health Management HIT 8

9 We are what we repeatedly do. Excellence then, is not an act, but a habit. Aristotle The goal of a quality system is the habit of excellence - consistently producing the right thing for users. 9

10 Continual Improvement The Demming cycle All quality management systems are based on achieving excellence by continual improvement 10

11 Background on Quality Principles for HIT Development 11

12 Quality Systems Origins and Evolution Quality management grew from work done by Shewhart and Demming on statistical control of variation in manufacturing Quality management became seen as universally applicable - applying to design and service as well as manufacturing The meaning of quality evolved from reducing variation to satisfying the customer 12

13 Examples of Quality Management Approaches International Organization for Standardization (ISO) Quality Management System (ISO 9001) Six Sigma Total Quality Management Capability Maturity Models 13

14 ISO Quality principles → Customer focus → Leadership → Involvement of people → Process approach → System approach to management → Continual improvement → Factual approach to decision making → Mutually beneficial supplier relationships 14

15 Quality System Standards ISO 9001 Quality management systems - Requirements ISO 90003 Software engineering – Guidelines for the application of ISO 9001 to computer software ISO 13485 Medical devices – Quality management systems – Requirements for regulatory purposes IEC 62304 Medical Devices – Software Life Cycle Processes 15

16 Using Quality System Principles for HIT Development 16

17 Why Quality Principles for HIT development? There is a broadly-based belief that HIT can offer tremendous benefits for healthcare, including: Reduced errors Improved efficiency and health care quality Reduced costs Increased patient engagement At the same time, there is concern that these benefits are not being achieved widely and that if HIT is not designed, developed, implemented, maintained or used properly, it can pose risks to patients. 17

18 IOM report on HIT and Patient Safety “the committee considers quality management principles and processes to be critical for the safety of health IT products” “Application of quality management practices needs to be a high priority for design and development activities.” “An industry standard is needed to ensure comprehensive quality management principles and processes are adopted throughout the health IT industry to provide health care organizations and the general public assurance that health IT products meet a minimum level of safety, reliability, and usability.” 18

19 The draft FDASIA Report proposed four key priority areas for health management HIT – the first was use of quality management principles “The application of quality management principles, including a quality systems approach by health IT stakeholders, is necessary for the safe design, development, implementation, customization, and use of health IT.” 19

20 Problems using the FDA Quality System Regulation (QSR) The QSR was developed to fit with US medical device laws and regulations including inspectional, premarket, and post market requirements. IOM report on HIT and Patient Safety stated “While the QSR provides vendors with flexibility, the committee does not believe the current quality system is the correct process needed for overseeing the health IT industry since it emphasizes regulation of design and labeling.” 20

21 Problems using existing standards Existing standards are organization level process-driven standards that may be good for developing software that controls medical devices, but may be poor at producing software that must be innovative and flexible Too much focus on prescriptive process requirements can impede innovation, a focus on best practices can support it Quality best practices can be applied to a product development as well as an organization Standards should be written using terminology that is commonly understood by the expected users of the standard. Existing standards are written using quality management terminology inherited from manufacturing –For HIT quality standards, we should use IT terminology, not quality terminology: SDLC instead of design controls Bug fixing instead of corrective action Process improvement instead of preventive action Configuration management instead of document control Installation and implementation instead of manufacturing And many others 21

22 How is health management HIT software different? Health management HIT software is different from medical device software –HIT complexity comes from domain content as well as from the software itself –HIT has a product life cycle very different from that of conventional medical device technologies –HIT exhibits great diversity in features, functions, and scope of intended and actual use, which tend to evolve over the life of the product. –The design of medical devices doesn’t change during implementation. HIT often has to change during implementation to fit a particular healthcare environment. –Users require shorter timelines for fixes and urgent changes 22

23 Key quality system principles for health management HIT Development These principles should be among the most important for a quality system used in development of HIT → Patient safety focus and culture → Customer focus → Leadership → Involvement of people, especially domain experts → Planned lifecycle approach (development, implementation, maintenance, etc.) → Continual improvement → Emphasis on best practices 23

24 These principles are similar to and overlap safety principles used by health care providers such as those from: –Agency for Healthcare Research & Quality (AHRQ) –The Joint Commission (THC) –Patient Safety Organizations (PSOs) The implementation of these principles and some of the quality practices used will of course be different than those used by providers 24

25 Patient safety first Practices Safety culture Safety risk management thinking and practices Risk management during implementation Involvement with Patient Safety Organizations Key benefits Proactive mitigation of possible HIT-related patient safety issues Fewer HIT-related patient safety incidents 25

26 Customer focus Practices Involvement of users, user IT and clinical domain experts User centered design Key benefits Reduction in potential for Use Error Reduction in cybersecurity issues Flexible and fast responses to customer needs/issues Increased effectiveness in the use of resources to enhance customer satisfaction Customer loyalty 26

27 Leadership Practices Executive management communicates key safety and quality goals Executive management reviews and reports progress on measures of safety and quality Key benefits Staff understands goals and are motivated to achieve organization’s objectives Activities are aligned and implemented in a unified way Miscommunication is minimized 27

28 Involvement of people Practices People understand the potential impact they can have on patient safety and on improving healthcare People propose innovative and creative approaches to improving safety and clinical effectiveness People openly discuss problems and share knowledge and experience about solutions Key benefits Motivated, committed and engaged people Innovation and creativity in achieving objectives All roles are engaged in developing solutions. People are trained for the roles they assume. Communications are both vertical and horizontal People participate in and contribute to continual improvement 28

29 Continual improvement Practices Establish goals and measures to track continual improvement including use error, safety and security measures Make continual improvement an objective and provide people with training and tools Key benefits Improve performance through improved organizational capabilities Alignment of improvement activities to strategic intent Flexibility to react quickly to problems and new public health opportunities 29

30 Emphasis on best practices Areas where use of best practices may be important Iterative development cycles Risk management Cybersecurity Usability design Implementation strategies (e.g., “big bang” versus incremental), The degree to which users can configure their IT system and the approaches to such configurations, Clinician training strategies, Front-line use (e.g., the IT integration into and redesign of clinical workflow), and Tools for analyzing and reporting results of care related to HIT (e.g., quality improvement). Patient Safety Organizations 30

31 Agile practices An example of the iterative development cycles best practice is the use of agile practices for software development AAMI has developed a Technical Information Report (TIR) that maps agile practices to the software development lifecycle activities in IEC 62304 The AAMI TIR demonstrates how agile practices can be used to meet quality system requirements 31 Figure 4─Mapping IEC 62304’s activities into AGILE’s INCREMENTAL/EVOLUTIONARY lifecycle

32 A continuum of quality guidance FDA QSR, ISO 13485 and IEC 62304 IMDRF SaMD Quality Guidance AAMI SW Committee Health Software Quality Principles NEEDED HIT quality principles and practices Applies to all medical devices International Medical Device Regulators Forum - Applies to software that is a medical device Applies to software that may be a medical device in some countries Applies to HIT software that is intended for health management Existing Under development Proposed (AAMI has initiated) 32

33 Tailoring existing standards A new standard for HIT quality principles and practices should not be prescriptive or overly burdensome It should not prevent organizations that have successfully used or tailored existing quality standards from continuing to use what is working for them 33

34 Pitfalls to Avoid in an HIT quality standard Direct references to requirements for medical device software and medical device risk management standards and regulations Exclusive use of general quality system terminology, standards or regulations Overly prescriptive process requirements that add a layer of bureaucracy This would create a high learning curve for HIT organizations and delay benefits that could be achieved with Quality System Guidelines tailored to the current state of the HIT industry. 34

35 Questions? 35

36 Special Emphasis Notice: Interest in Research on Health IT Safety Teresa Zayas Cabán, PhD Chief of Health IT Research Division of Health IT Agency for Health IT Research and Quality February 2015

37 Overview and Goals Recently published special emphasis notice (SEN) ► NOT-HS-15-005 o http://grants.nih.gov/grants/guide/notice- files/NOT-HS-15-005.html http://grants.nih.gov/grants/guide/notice- files/NOT-HS-15-005.html 37

38 Goals Fund research on safe health IT practices specifically related to the design, implementation, usability, and safe use of health IT by all users, including patients. Generate new evidence on safe health IT practices that could be used to inform health IT certification and other forms of policy guidance 38

39 Grant Mechanisms Health IT-focused R21 Funding Opportunity Announcement (FOA): PA-14-001 ► http://grants.nih.gov/grants/guide/pa-files/PA-14- 001.html http://grants.nih.gov/grants/guide/pa-files/PA-14- 001.html Standing R01 FOA: PA-14-291 ► http://grants.nih.gov/grants/guide/pa-files/PA-14- 291.html http://grants.nih.gov/grants/guide/pa-files/PA-14- 291.html 39

40 R01 Applications Personnel requirements: ► Personnel from health IT vendors and health care delivery organizations ► Patient Safety Organization and industry partnership are strongly encouraged 40

41 Timelines and Funding Limits Health IT-focused R21 (PA-14-001) ► Total (direct plus indirect) costs o No more than $200,000 in any given year o No more than $300,000 for entire project period ► Project period: Up to two years Standing R01 (PA-14-291) ► No more than $250,000 per year ► Project period: Up to five years 41

42 Discussion www.healthit.ahrq.gov 42

43 Next Meeting: Friday, February 20, 2015 1:00 PM-3:00 PM Eastern Time 43


Download ppt "February 6, 2015 Health IT Implementation, Usability and Safety Workgroup David Bates, chair Larry Wolf, co-chair."

Similar presentations


Ads by Google