Table of contents
  1. Story
  2. Slides
    1. Julia Skapik, MD, MPH
      1. ONC Opportunities in Health IT and Big Data
      2. Stay connected, communicate, , and collaborate visit . . .
      3. The Learning Healthcare System Workshop Summary
      4. The Current Frontier: The Health IT Interoperability Problem
      5. Current State
      6. The Interoperability Problem in Healthcare
      7. Future Vision
      8. “Old” vs. “New”Data Element: Ethnicity
      9. SDC Data Element Definition Framework
      10. Where Is Health IT Moving?
      11. JASON Report: Recommendations for Unified Federal Health Data Architecture
      12. Where Is Health IT Moving?
    2. Mera Choi
      1. S&I Framework: The Role of Standards in Supporting Healthcare Data Initiatives
      2. S&I Framework and Big Data
      3. How S&I Supports Healthcare Goals using Big Data
      4. S&I Initiatives
      5. Structured Data Capture (SDC)
      6. SDC Data Collection
      7. Data Access Framework (DAF)
      8. DAF Targeted Access
      9. Conclusion
      10. Questions and Discussion
  3. Spotfire Dashboard
  4. Research Notes
  5. President Bush 2004
    1. Transforming Health Care: The President’s Health Information Technology Plan
    2. The Problem: Challenges to the U.S. Health Care System
    3. The Solution – Health Information Technology
    4. The President’s Health Information Technology Plan
  6. SICoP and Ontolog Forum Propose Ontological Engineering to ONC in 2005
    1. Response to ONCHIT NHIN RFI #4150-24
      1. Background
        1. Active Participants
        2. Authors (w/ codes)
        3. About Ontolog
        4. What are Ontologies?
        5. Ontologies in Health Care
      2. Thesis
      3. General
      4. Organizational and Business Framework
      5. Management and Operational Considerations
      6. Glossary of Key Acronyms
  7. HL7 EHR Interoperability Work Group in 2007 Mentions SICoP
  8. Dr. Oliver Bohdenrider's NIH UMLS Group starts to help ONC
  9. New PCAST Report Says “Systems Engineering” Can Improve Health Care
  10. Fact Sheet: PCAST Report on Systems Engineering in Health Care
  11. Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering
    1. About the President’s Council of Advisors on Science and Technology
    2. The President’s Council of Advisors on Science and Technology
      1. Co-Chairs
      2. Vice Chairs
      3. Members
      4. Staff
    3. PCAST Systems Engineering in Health Care Working Group
      1. Co-Chairs
      2. Working Group
      3. Staff
      4. Science Writer
    4. Transmittal Letter
    5. Executive Summary
      1. Summary of Recommendations
    6. Introduction and Motivation for Improvement
    7. Successful Use of Systems Engineering in Other Industries
      1. Box 1: Overview of Systems Engineering
    8. Promise of Systems Engineering for Health and Health Care
      1. Table 1. Potential impact of systems engineering on different segments of the health system, showing selected challenges alongside potential systems methods and tools approaches​
      2. Box 2: Taking a systems approach to improve care across a community 15
    9. Factors Limiting Dissemination and Spread of Systems-Engineering Principles
      1. Figure 1. Distribution of Physicians by Practice Size, 2012. 22
    10. Goal 1: Accelerate Alignment of Payment Systems with Desired Outcomes
      1. Box 3: Virginia Mason Medical Center back pain clinic example— How payment policies can discourage systems engineering 25
    11. Goal 2: Increase Access to Relevant Health Data and Analytics
      1. Expanding clinical and operational data for improvement initiatives
        1. Box 4: Key conclusions from 2010 PCAST report and 2014 JASON report on health IT
      2. Expanding data available for assessing progress
        1. Table 2. Example data resources throughout the Department of Health and Human Services
        2. Box 5: CMS is Making Medicare Claims Data Available to Enrollees, Researchers, Accountable Care Organizations, Quality Reporting Organizations, and the Public 36
    12. Goal 3: Provide Technical Assistance in Systems-Engineering Approaches
    13. Goal 4: Involve Communities in Improving Health-care Delivery
      1. Positive results occur when partnering with communities
        1. Box 6: Improving care transitions with the community—CARE Network 47
        2. Box 7: Assisting communities using systems approaches—ReThink Health 49
      2. Opportunities exist for expanding community engagement in health-care delivery
    14. Goal 5: Share Lessons Learned from Successful Improvement Efforts
      1. Box 8: Recognizing successful use of systems engineering— Baldrige Performance Excellence Program 58
    15. Goal 6: Train Health Professionals in New Skills and Approaches
      1. Box 9: Training nurses in systems engineering
    16. Summary and Conclusions
    17. References
      1. 1
      2. 2
      3. 3
      4. 4
      5. 5
      6. 6
      7. 7
      8. 8
      9. 9
      10. 10
      11. 11
      12. 12
      13. 13
      14. 14
      15. 15
      16. 16
      17. 17
      18. 18
      19. 19
      20. 20
      21. 21
      22. 22
      23. 23
      24. 24
      25. 25
      26. 26
      27. 27
      28. 28
      29. 29
      30. 30
      31. 31
      32. 32
      33. 33
      34. 34
      35. 35
      36. 36
      37. 37
      38. 38
      39. 39
      40. 40
      41. 41
      42. 42
      43. 43
      44. 44
      45. 45
      46. 46
      47. 47
      48. 48
      49. 49
      50. 50
      51. 51
      52. 52
      53. 53
      54. 54
      55. 55
      56. 56
      57. 57
      58. 58
      59. 59
      60. 60
      61. 61
      62. 62
      63. 63
      64. 64
      65. 65
      66. 66
    18. Appendices
      1. Appendix A: Systems Engineering Overview
        1. What is it?
        2. How are systems formed?
        3. How is it operationalized?
        4. What strategies are used for improvement?
      2. Appendix B: Selected Examples of Systems Engineering in Health Care
        1. Redesigning a hospital pharmacy with systems engineering
          1. Figure B-1. Workflow in one pharmacy unit before (left) and after (right) systems-engineering methods were used. 62
        2. Addressing alcohol abuse in San Francisco
        3. Coordinating care across the community: Vermont Blueprint for Health
      3. Appendix C: Glossary
        1. Agile Management
        2. Business Process Management
        3. Complexity Science
        4. Human Factors
        5. Lean Enterprise System
        6. Lean Six Sigma
        7. Microsystem
        8. Performance Improvement
        9. Process Improvement
        10. Quality Management
        11. Queuing Theory Flow, and the Theory of Constraints
        12. Reliability And Maintainability
        13. Six Sigma
        14. Statistical Process Control
        15. System
        16. Systems engineering
        17. Systems science
      4. Appendix D: Abbreviations
      5. Appendix E: 2010 PCAST Report on Health Information Technology
      6. Appendix F: 2014 JASON Report on Health Data Infrastructure
        1. Findings
        2. Recommendations
      7. Appendix G: Illustrative Examples on Ways to Build HHS Data Leadership
      8. Appendix H: Additional Experts Providing Input
  12. Press Release on PCAST Report on Health Information Technology
  13. Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward
    1. About the President’s Council of Advisors on Science and Technology
    2. Co-Chairs
    3. Members
    4. Staff
    5. Transmittal Letter
    6. Executive Summary
      1. Advantages of focusing on a universal exchange language
      2. Recommendations
    7. PCAST Health Information Technology Working Group
      1. Co-Chairs
      2. Members
      3. Staff
    8. I. Introduction and Overview
      1. Introduction
      2. The Origins of This Study
      3. Analysis of the Problem
      4. The Present Federal Landscape
      5. Structure of This Report
    9. II. The Potential of Health IT
      1. Introduction
      2. Potential Benefits of Health IT: An Overview
        1. Table 1. The Potential Benefits of Health IT
      3. The Value of Patient-Specific Data to Patients
        1. Use Case 1
        2. Use Case 2
      4. The Value of Patient-Specific and Aggregated Data to Physicians
        1. Use Case 3
        2. Use Case 4
        3. Use Case 5
        4. Use Case 6
      5. The Value of Population Data for Research and Public Health
        1. Use Case 7
        2. Use Case 8
        3. Use Case 9
      6. Realizing the Potential of IT: A Data-Centric Approach
      7. Conclusion
        1. This chapter’s bottom line
    10. III. Health IT Today
      1. Introduction
      2. Historical Barriers to EHR Adoption
      3. Limitations of Present-Day EHRs
        1. Technology-Enabled Diagnoses
      4. Lessons from Early Adopters
        1. The Kaiser and VA Experience
        2. Experiences at Other Organizations
        3. Lessons and Challenges
      5. Health Information Exchanges
      6. New and Emerging Technologies
        1. “Cloud-Based” Technologies for Small Providers
        2. Personal Health Records
        3. Data Aggregation “Middleware”
      7. The HITECH Act and Shifting Incentives
      8. Opportunities and Challenges for ONC and CMS
      9. Conclusion
        1. This chapter’s bottom line
    11. IV. Technology for an Integrated Health IT Ecosystem
      1. Introduction
      2. Earlier Models for Enabling Data Exchange
      3. Universal Exchange Using Metadata-Tagged Data Elements
      4. Data Element Access Services
      5. Advantages of the Tagged Data Element Approach
        1. This chapter’s bottom line
    12. V. Privacy and Security Considerations
      1. Introduction
      2. The Present Framework
      3. The Need for Strong, Persistent Privacy Protections
      4. Deleterious Effects on Medical Research and Care
      5. Data Security: How Good Is Good Enough?
      6. A Health IT Architecture for 21st-Century Privacy and Security
      7. Privacy Protection of Metadata-Tagged Data Elements
    13. VI. Economic and Regulatory Issues
      1. Introduction
      2. Standards and Incentives for Interoperability
      3. Creating a Data Exchange Infrastructure
      4. A Regulatory Structure for Data Access
      5. Competition to Supply Technology
      6. Innovation and Markets for Applications
      7. The Broader Economics of Healthcare
      8. Estimating Costs
    14. VII. Health Data and the Research Opportunity
      1. Introduction
      2. The Potential for Real-Time, Real-World, and Comprehensive Data
      3. Supporting Research Uses
        1. Linking Patients to Clinical Studies
        2. Real-Time Patient Benefits from Comparative Effectiveness Research
    15. VIII. Guidance to Agencies
      1. Introduction
      2. A Feasible Roadmap to the Future
      3. Guidance on Necessary Design Choices
      4. Guidance on Meaningful Use Requirements
    16. IX. Recommendations
    17. References
      1. 1.
      2. 2.
      3. 3.
      4. 4.
      5. 5.
      6. 6.
      7. 7.
      8. 8.
      9. 9.
      10. 10.
      11. 11.
      12. 12.
      13. 13.
      14. 14.
      15. 15.
      16. 16.
      17. 17.
      18. 18.
      19. 19.
      20. 20.
      21. 21.
      22. 22.
      23. 23.
      24. 24.
      25. 25.
      26. 26.
      27. 27.
      28. 28.
      29. 29.
      30. 30.
      31. 31.
      32. 32.
      33. 33.
      34. 34.
      35. 35.
      36. 36.
      37. 37.
      38. 38.
      39. 39.
      40. 40.
      41. 41.
      42. 42.
      43. 43.
      44. 44.
      45. 45.
      46. 46.
      47. 47.
      48. 48.
      49. 49.
      50. 50.
      51. 51.
      52. 52.
      53. 53.
      54. 54.
      55. 55.
      56. 56.
      57. 57.
      58. 58.
      59. 59.
      60. 60.
      61. 61.
      62. 62.
      63. 63.
      64. 64.
      65. 65.
      66. 66.
      67. 67.
      68. 68.
      69. 69.
      70. 70.
      71. 71.
      72. 72.
      73. 73.
      74. 74.
      75. 75.
      76. 76.
      77. 77.
      78. 78.
      79. 79.
      80. 80.
      81. 81.
      82. 82.
      83. 83.
      84. 84.
      85. 85.
      86. 86.
      87. 87.
      88. 88.
      89. 89.
      90. 90.
      91. 91.
    18. Appendices
      1. Appendix A: Expert Input
      2. Appendix B: Acknowledgments
      3. Appendix C: Glossary
        1. Anonymize
        2. Authentication
        3. Authorization
        4. Clinical decision support
        5. Cloud-based
        6. Comparative effectiveness research
        7. Data element access services
        8. Data-centric
        9. Data element indexing
        10. De-identified
        11. Digital signature
        12. Electronic health record
        13. Encryption
        14. Genotype
        15. Health information exchange
        16. Health information technology
        17. HITECH Act
        18. Integration engines
        19. Key
        20. Meaningful use
        21. Metadata
        22. Metadata tag
        23. Middleware
        24. Patient-centric
        25. Personal health record
        26. Personalization
        27. Physician Quality Reporting Initiative
        28. Post-marketing surveillance
        29. Primary care medical home
        30. Randomized clinical trials
        31. Semantics
        32. Service-oriented architecture
        33. Standardized health records
        34. Syndromic surveillance
        35. Syntax
        36. Tagged data elements
        37. Two-factor authentication
        38. Universal exchange language
        39. Usability
        40. Value-based purchasing
        41. VistA
        42. XML
      4. Appendix D: Abbreviations

Data Science for EHRs

Last modified
Table of contents
  1. Story
  2. Slides
    1. Julia Skapik, MD, MPH
      1. ONC Opportunities in Health IT and Big Data
      2. Stay connected, communicate, , and collaborate visit . . .
      3. The Learning Healthcare System Workshop Summary
      4. The Current Frontier: The Health IT Interoperability Problem
      5. Current State
      6. The Interoperability Problem in Healthcare
      7. Future Vision
      8. “Old” vs. “New”Data Element: Ethnicity
      9. SDC Data Element Definition Framework
      10. Where Is Health IT Moving?
      11. JASON Report: Recommendations for Unified Federal Health Data Architecture
      12. Where Is Health IT Moving?
    2. Mera Choi
      1. S&I Framework: The Role of Standards in Supporting Healthcare Data Initiatives
      2. S&I Framework and Big Data
      3. How S&I Supports Healthcare Goals using Big Data
      4. S&I Initiatives
      5. Structured Data Capture (SDC)
      6. SDC Data Collection
      7. Data Access Framework (DAF)
      8. DAF Targeted Access
      9. Conclusion
      10. Questions and Discussion
  3. Spotfire Dashboard
  4. Research Notes
  5. President Bush 2004
    1. Transforming Health Care: The President’s Health Information Technology Plan
    2. The Problem: Challenges to the U.S. Health Care System
    3. The Solution – Health Information Technology
    4. The President’s Health Information Technology Plan
  6. SICoP and Ontolog Forum Propose Ontological Engineering to ONC in 2005
    1. Response to ONCHIT NHIN RFI #4150-24
      1. Background
        1. Active Participants
        2. Authors (w/ codes)
        3. About Ontolog
        4. What are Ontologies?
        5. Ontologies in Health Care
      2. Thesis
      3. General
      4. Organizational and Business Framework
      5. Management and Operational Considerations
      6. Glossary of Key Acronyms
  7. HL7 EHR Interoperability Work Group in 2007 Mentions SICoP
  8. Dr. Oliver Bohdenrider's NIH UMLS Group starts to help ONC
  9. New PCAST Report Says “Systems Engineering” Can Improve Health Care
  10. Fact Sheet: PCAST Report on Systems Engineering in Health Care
  11. Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering
    1. About the President’s Council of Advisors on Science and Technology
    2. The President’s Council of Advisors on Science and Technology
      1. Co-Chairs
      2. Vice Chairs
      3. Members
      4. Staff
    3. PCAST Systems Engineering in Health Care Working Group
      1. Co-Chairs
      2. Working Group
      3. Staff
      4. Science Writer
    4. Transmittal Letter
    5. Executive Summary
      1. Summary of Recommendations
    6. Introduction and Motivation for Improvement
    7. Successful Use of Systems Engineering in Other Industries
      1. Box 1: Overview of Systems Engineering
    8. Promise of Systems Engineering for Health and Health Care
      1. Table 1. Potential impact of systems engineering on different segments of the health system, showing selected challenges alongside potential systems methods and tools approaches​
      2. Box 2: Taking a systems approach to improve care across a community 15
    9. Factors Limiting Dissemination and Spread of Systems-Engineering Principles
      1. Figure 1. Distribution of Physicians by Practice Size, 2012. 22
    10. Goal 1: Accelerate Alignment of Payment Systems with Desired Outcomes
      1. Box 3: Virginia Mason Medical Center back pain clinic example— How payment policies can discourage systems engineering 25
    11. Goal 2: Increase Access to Relevant Health Data and Analytics
      1. Expanding clinical and operational data for improvement initiatives
        1. Box 4: Key conclusions from 2010 PCAST report and 2014 JASON report on health IT
      2. Expanding data available for assessing progress
        1. Table 2. Example data resources throughout the Department of Health and Human Services
        2. Box 5: CMS is Making Medicare Claims Data Available to Enrollees, Researchers, Accountable Care Organizations, Quality Reporting Organizations, and the Public 36
    12. Goal 3: Provide Technical Assistance in Systems-Engineering Approaches
    13. Goal 4: Involve Communities in Improving Health-care Delivery
      1. Positive results occur when partnering with communities
        1. Box 6: Improving care transitions with the community—CARE Network 47
        2. Box 7: Assisting communities using systems approaches—ReThink Health 49
      2. Opportunities exist for expanding community engagement in health-care delivery
    14. Goal 5: Share Lessons Learned from Successful Improvement Efforts
      1. Box 8: Recognizing successful use of systems engineering— Baldrige Performance Excellence Program 58
    15. Goal 6: Train Health Professionals in New Skills and Approaches
      1. Box 9: Training nurses in systems engineering
    16. Summary and Conclusions
    17. References
      1. 1
      2. 2
      3. 3
      4. 4
      5. 5
      6. 6
      7. 7
      8. 8
      9. 9
      10. 10
      11. 11
      12. 12
      13. 13
      14. 14
      15. 15
      16. 16
      17. 17
      18. 18
      19. 19
      20. 20
      21. 21
      22. 22
      23. 23
      24. 24
      25. 25
      26. 26
      27. 27
      28. 28
      29. 29
      30. 30
      31. 31
      32. 32
      33. 33
      34. 34
      35. 35
      36. 36
      37. 37
      38. 38
      39. 39
      40. 40
      41. 41
      42. 42
      43. 43
      44. 44
      45. 45
      46. 46
      47. 47
      48. 48
      49. 49
      50. 50
      51. 51
      52. 52
      53. 53
      54. 54
      55. 55
      56. 56
      57. 57
      58. 58
      59. 59
      60. 60
      61. 61
      62. 62
      63. 63
      64. 64
      65. 65
      66. 66
    18. Appendices
      1. Appendix A: Systems Engineering Overview
        1. What is it?
        2. How are systems formed?
        3. How is it operationalized?
        4. What strategies are used for improvement?
      2. Appendix B: Selected Examples of Systems Engineering in Health Care
        1. Redesigning a hospital pharmacy with systems engineering
          1. Figure B-1. Workflow in one pharmacy unit before (left) and after (right) systems-engineering methods were used. 62
        2. Addressing alcohol abuse in San Francisco
        3. Coordinating care across the community: Vermont Blueprint for Health
      3. Appendix C: Glossary
        1. Agile Management
        2. Business Process Management
        3. Complexity Science
        4. Human Factors
        5. Lean Enterprise System
        6. Lean Six Sigma
        7. Microsystem
        8. Performance Improvement
        9. Process Improvement
        10. Quality Management
        11. Queuing Theory Flow, and the Theory of Constraints
        12. Reliability And Maintainability
        13. Six Sigma
        14. Statistical Process Control
        15. System
        16. Systems engineering
        17. Systems science
      4. Appendix D: Abbreviations
      5. Appendix E: 2010 PCAST Report on Health Information Technology
      6. Appendix F: 2014 JASON Report on Health Data Infrastructure
        1. Findings
        2. Recommendations
      7. Appendix G: Illustrative Examples on Ways to Build HHS Data Leadership
      8. Appendix H: Additional Experts Providing Input
  12. Press Release on PCAST Report on Health Information Technology
  13. Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward
    1. About the President’s Council of Advisors on Science and Technology
    2. Co-Chairs
    3. Members
    4. Staff
    5. Transmittal Letter
    6. Executive Summary
      1. Advantages of focusing on a universal exchange language
      2. Recommendations
    7. PCAST Health Information Technology Working Group
      1. Co-Chairs
      2. Members
      3. Staff
    8. I. Introduction and Overview
      1. Introduction
      2. The Origins of This Study
      3. Analysis of the Problem
      4. The Present Federal Landscape
      5. Structure of This Report
    9. II. The Potential of Health IT
      1. Introduction
      2. Potential Benefits of Health IT: An Overview
        1. Table 1. The Potential Benefits of Health IT
      3. The Value of Patient-Specific Data to Patients
        1. Use Case 1
        2. Use Case 2
      4. The Value of Patient-Specific and Aggregated Data to Physicians
        1. Use Case 3
        2. Use Case 4
        3. Use Case 5
        4. Use Case 6
      5. The Value of Population Data for Research and Public Health
        1. Use Case 7
        2. Use Case 8
        3. Use Case 9
      6. Realizing the Potential of IT: A Data-Centric Approach
      7. Conclusion
        1. This chapter’s bottom line
    10. III. Health IT Today
      1. Introduction
      2. Historical Barriers to EHR Adoption
      3. Limitations of Present-Day EHRs
        1. Technology-Enabled Diagnoses
      4. Lessons from Early Adopters
        1. The Kaiser and VA Experience
        2. Experiences at Other Organizations
        3. Lessons and Challenges
      5. Health Information Exchanges
      6. New and Emerging Technologies
        1. “Cloud-Based” Technologies for Small Providers
        2. Personal Health Records
        3. Data Aggregation “Middleware”
      7. The HITECH Act and Shifting Incentives
      8. Opportunities and Challenges for ONC and CMS
      9. Conclusion
        1. This chapter’s bottom line
    11. IV. Technology for an Integrated Health IT Ecosystem
      1. Introduction
      2. Earlier Models for Enabling Data Exchange
      3. Universal Exchange Using Metadata-Tagged Data Elements
      4. Data Element Access Services
      5. Advantages of the Tagged Data Element Approach
        1. This chapter’s bottom line
    12. V. Privacy and Security Considerations
      1. Introduction
      2. The Present Framework
      3. The Need for Strong, Persistent Privacy Protections
      4. Deleterious Effects on Medical Research and Care
      5. Data Security: How Good Is Good Enough?
      6. A Health IT Architecture for 21st-Century Privacy and Security
      7. Privacy Protection of Metadata-Tagged Data Elements
    13. VI. Economic and Regulatory Issues
      1. Introduction
      2. Standards and Incentives for Interoperability
      3. Creating a Data Exchange Infrastructure
      4. A Regulatory Structure for Data Access
      5. Competition to Supply Technology
      6. Innovation and Markets for Applications
      7. The Broader Economics of Healthcare
      8. Estimating Costs
    14. VII. Health Data and the Research Opportunity
      1. Introduction
      2. The Potential for Real-Time, Real-World, and Comprehensive Data
      3. Supporting Research Uses
        1. Linking Patients to Clinical Studies
        2. Real-Time Patient Benefits from Comparative Effectiveness Research
    15. VIII. Guidance to Agencies
      1. Introduction
      2. A Feasible Roadmap to the Future
      3. Guidance on Necessary Design Choices
      4. Guidance on Meaningful Use Requirements
    16. IX. Recommendations
    17. References
      1. 1.
      2. 2.
      3. 3.
      4. 4.
      5. 5.
      6. 6.
      7. 7.
      8. 8.
      9. 9.
      10. 10.
      11. 11.
      12. 12.
      13. 13.
      14. 14.
      15. 15.
      16. 16.
      17. 17.
      18. 18.
      19. 19.
      20. 20.
      21. 21.
      22. 22.
      23. 23.
      24. 24.
      25. 25.
      26. 26.
      27. 27.
      28. 28.
      29. 29.
      30. 30.
      31. 31.
      32. 32.
      33. 33.
      34. 34.
      35. 35.
      36. 36.
      37. 37.
      38. 38.
      39. 39.
      40. 40.
      41. 41.
      42. 42.
      43. 43.
      44. 44.
      45. 45.
      46. 46.
      47. 47.
      48. 48.
      49. 49.
      50. 50.
      51. 51.
      52. 52.
      53. 53.
      54. 54.
      55. 55.
      56. 56.
      57. 57.
      58. 58.
      59. 59.
      60. 60.
      61. 61.
      62. 62.
      63. 63.
      64. 64.
      65. 65.
      66. 66.
      67. 67.
      68. 68.
      69. 69.
      70. 70.
      71. 71.
      72. 72.
      73. 73.
      74. 74.
      75. 75.
      76. 76.
      77. 77.
      78. 78.
      79. 79.
      80. 80.
      81. 81.
      82. 82.
      83. 83.
      84. 84.
      85. 85.
      86. 86.
      87. 87.
      88. 88.
      89. 89.
      90. 90.
      91. 91.
    18. Appendices
      1. Appendix A: Expert Input
      2. Appendix B: Acknowledgments
      3. Appendix C: Glossary
        1. Anonymize
        2. Authentication
        3. Authorization
        4. Clinical decision support
        5. Cloud-based
        6. Comparative effectiveness research
        7. Data element access services
        8. Data-centric
        9. Data element indexing
        10. De-identified
        11. Digital signature
        12. Electronic health record
        13. Encryption
        14. Genotype
        15. Health information exchange
        16. Health information technology
        17. HITECH Act
        18. Integration engines
        19. Key
        20. Meaningful use
        21. Metadata
        22. Metadata tag
        23. Middleware
        24. Patient-centric
        25. Personal health record
        26. Personalization
        27. Physician Quality Reporting Initiative
        28. Post-marketing surveillance
        29. Primary care medical home
        30. Randomized clinical trials
        31. Semantics
        32. Service-oriented architecture
        33. Standardized health records
        34. Syndromic surveillance
        35. Syntax
        36. Tagged data elements
        37. Two-factor authentication
        38. Universal exchange language
        39. Usability
        40. Value-based purchasing
        41. VistA
        42. XML
      4. Appendix D: Abbreviations

  1. Story
  2. Slides
    1. Julia Skapik, MD, MPH
      1. ONC Opportunities in Health IT and Big Data
      2. Stay connected, communicate, , and collaborate visit . . .
      3. The Learning Healthcare System Workshop Summary
      4. The Current Frontier: The Health IT Interoperability Problem
      5. Current State
      6. The Interoperability Problem in Healthcare
      7. Future Vision
      8. “Old” vs. “New”Data Element: Ethnicity
      9. SDC Data Element Definition Framework
      10. Where Is Health IT Moving?
      11. JASON Report: Recommendations for Unified Federal Health Data Architecture
      12. Where Is Health IT Moving?
    2. Mera Choi
      1. S&I Framework: The Role of Standards in Supporting Healthcare Data Initiatives
      2. S&I Framework and Big Data
      3. How S&I Supports Healthcare Goals using Big Data
      4. S&I Initiatives
      5. Structured Data Capture (SDC)
      6. SDC Data Collection
      7. Data Access Framework (DAF)
      8. DAF Targeted Access
      9. Conclusion
      10. Questions and Discussion
  3. Spotfire Dashboard
  4. Research Notes
  5. President Bush 2004
    1. Transforming Health Care: The President’s Health Information Technology Plan
    2. The Problem: Challenges to the U.S. Health Care System
    3. The Solution – Health Information Technology
    4. The President’s Health Information Technology Plan
  6. SICoP and Ontolog Forum Propose Ontological Engineering to ONC in 2005
    1. Response to ONCHIT NHIN RFI #4150-24
      1. Background
        1. Active Participants
        2. Authors (w/ codes)
        3. About Ontolog
        4. What are Ontologies?
        5. Ontologies in Health Care
      2. Thesis
      3. General
      4. Organizational and Business Framework
      5. Management and Operational Considerations
      6. Glossary of Key Acronyms
  7. HL7 EHR Interoperability Work Group in 2007 Mentions SICoP
  8. Dr. Oliver Bohdenrider's NIH UMLS Group starts to help ONC
  9. New PCAST Report Says “Systems Engineering” Can Improve Health Care
  10. Fact Sheet: PCAST Report on Systems Engineering in Health Care
  11. Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering
    1. About the President’s Council of Advisors on Science and Technology
    2. The President’s Council of Advisors on Science and Technology
      1. Co-Chairs
      2. Vice Chairs
      3. Members
      4. Staff
    3. PCAST Systems Engineering in Health Care Working Group
      1. Co-Chairs
      2. Working Group
      3. Staff
      4. Science Writer
    4. Transmittal Letter
    5. Executive Summary
      1. Summary of Recommendations
    6. Introduction and Motivation for Improvement
    7. Successful Use of Systems Engineering in Other Industries
      1. Box 1: Overview of Systems Engineering
    8. Promise of Systems Engineering for Health and Health Care
      1. Table 1. Potential impact of systems engineering on different segments of the health system, showing selected challenges alongside potential systems methods and tools approaches​
      2. Box 2: Taking a systems approach to improve care across a community 15
    9. Factors Limiting Dissemination and Spread of Systems-Engineering Principles
      1. Figure 1. Distribution of Physicians by Practice Size, 2012. 22
    10. Goal 1: Accelerate Alignment of Payment Systems with Desired Outcomes
      1. Box 3: Virginia Mason Medical Center back pain clinic example— How payment policies can discourage systems engineering 25
    11. Goal 2: Increase Access to Relevant Health Data and Analytics
      1. Expanding clinical and operational data for improvement initiatives
        1. Box 4: Key conclusions from 2010 PCAST report and 2014 JASON report on health IT
      2. Expanding data available for assessing progress
        1. Table 2. Example data resources throughout the Department of Health and Human Services
        2. Box 5: CMS is Making Medicare Claims Data Available to Enrollees, Researchers, Accountable Care Organizations, Quality Reporting Organizations, and the Public 36
    12. Goal 3: Provide Technical Assistance in Systems-Engineering Approaches
    13. Goal 4: Involve Communities in Improving Health-care Delivery
      1. Positive results occur when partnering with communities
        1. Box 6: Improving care transitions with the community—CARE Network 47
        2. Box 7: Assisting communities using systems approaches—ReThink Health 49
      2. Opportunities exist for expanding community engagement in health-care delivery
    14. Goal 5: Share Lessons Learned from Successful Improvement Efforts
      1. Box 8: Recognizing successful use of systems engineering— Baldrige Performance Excellence Program 58
    15. Goal 6: Train Health Professionals in New Skills and Approaches
      1. Box 9: Training nurses in systems engineering
    16. Summary and Conclusions
    17. References
      1. 1
      2. 2
      3. 3
      4. 4
      5. 5
      6. 6
      7. 7
      8. 8
      9. 9
      10. 10
      11. 11
      12. 12
      13. 13
      14. 14
      15. 15
      16. 16
      17. 17
      18. 18
      19. 19
      20. 20
      21. 21
      22. 22
      23. 23
      24. 24
      25. 25
      26. 26
      27. 27
      28. 28
      29. 29
      30. 30
      31. 31
      32. 32
      33. 33
      34. 34
      35. 35
      36. 36
      37. 37
      38. 38
      39. 39
      40. 40
      41. 41
      42. 42
      43. 43
      44. 44
      45. 45
      46. 46
      47. 47
      48. 48
      49. 49
      50. 50
      51. 51
      52. 52
      53. 53
      54. 54
      55. 55
      56. 56
      57. 57
      58. 58
      59. 59
      60. 60
      61. 61
      62. 62
      63. 63
      64. 64
      65. 65
      66. 66
    18. Appendices
      1. Appendix A: Systems Engineering Overview
        1. What is it?
        2. How are systems formed?
        3. How is it operationalized?
        4. What strategies are used for improvement?
      2. Appendix B: Selected Examples of Systems Engineering in Health Care
        1. Redesigning a hospital pharmacy with systems engineering
          1. Figure B-1. Workflow in one pharmacy unit before (left) and after (right) systems-engineering methods were used. 62
        2. Addressing alcohol abuse in San Francisco
        3. Coordinating care across the community: Vermont Blueprint for Health
      3. Appendix C: Glossary
        1. Agile Management
        2. Business Process Management
        3. Complexity Science
        4. Human Factors
        5. Lean Enterprise System
        6. Lean Six Sigma
        7. Microsystem
        8. Performance Improvement
        9. Process Improvement
        10. Quality Management
        11. Queuing Theory Flow, and the Theory of Constraints
        12. Reliability And Maintainability
        13. Six Sigma
        14. Statistical Process Control
        15. System
        16. Systems engineering
        17. Systems science
      4. Appendix D: Abbreviations
      5. Appendix E: 2010 PCAST Report on Health Information Technology
      6. Appendix F: 2014 JASON Report on Health Data Infrastructure
        1. Findings
        2. Recommendations
      7. Appendix G: Illustrative Examples on Ways to Build HHS Data Leadership
      8. Appendix H: Additional Experts Providing Input
  12. Press Release on PCAST Report on Health Information Technology
  13. Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward
    1. About the President’s Council of Advisors on Science and Technology
    2. Co-Chairs
    3. Members
    4. Staff
    5. Transmittal Letter
    6. Executive Summary
      1. Advantages of focusing on a universal exchange language
      2. Recommendations
    7. PCAST Health Information Technology Working Group
      1. Co-Chairs
      2. Members
      3. Staff
    8. I. Introduction and Overview
      1. Introduction
      2. The Origins of This Study
      3. Analysis of the Problem
      4. The Present Federal Landscape
      5. Structure of This Report
    9. II. The Potential of Health IT
      1. Introduction
      2. Potential Benefits of Health IT: An Overview
        1. Table 1. The Potential Benefits of Health IT
      3. The Value of Patient-Specific Data to Patients
        1. Use Case 1
        2. Use Case 2
      4. The Value of Patient-Specific and Aggregated Data to Physicians
        1. Use Case 3
        2. Use Case 4
        3. Use Case 5
        4. Use Case 6
      5. The Value of Population Data for Research and Public Health
        1. Use Case 7
        2. Use Case 8
        3. Use Case 9
      6. Realizing the Potential of IT: A Data-Centric Approach
      7. Conclusion
        1. This chapter’s bottom line
    10. III. Health IT Today
      1. Introduction
      2. Historical Barriers to EHR Adoption
      3. Limitations of Present-Day EHRs
        1. Technology-Enabled Diagnoses
      4. Lessons from Early Adopters
        1. The Kaiser and VA Experience
        2. Experiences at Other Organizations
        3. Lessons and Challenges
      5. Health Information Exchanges
      6. New and Emerging Technologies
        1. “Cloud-Based” Technologies for Small Providers
        2. Personal Health Records
        3. Data Aggregation “Middleware”
      7. The HITECH Act and Shifting Incentives
      8. Opportunities and Challenges for ONC and CMS
      9. Conclusion
        1. This chapter’s bottom line
    11. IV. Technology for an Integrated Health IT Ecosystem
      1. Introduction
      2. Earlier Models for Enabling Data Exchange
      3. Universal Exchange Using Metadata-Tagged Data Elements
      4. Data Element Access Services
      5. Advantages of the Tagged Data Element Approach
        1. This chapter’s bottom line
    12. V. Privacy and Security Considerations
      1. Introduction
      2. The Present Framework
      3. The Need for Strong, Persistent Privacy Protections
      4. Deleterious Effects on Medical Research and Care
      5. Data Security: How Good Is Good Enough?
      6. A Health IT Architecture for 21st-Century Privacy and Security
      7. Privacy Protection of Metadata-Tagged Data Elements
    13. VI. Economic and Regulatory Issues
      1. Introduction
      2. Standards and Incentives for Interoperability
      3. Creating a Data Exchange Infrastructure
      4. A Regulatory Structure for Data Access
      5. Competition to Supply Technology
      6. Innovation and Markets for Applications
      7. The Broader Economics of Healthcare
      8. Estimating Costs
    14. VII. Health Data and the Research Opportunity
      1. Introduction
      2. The Potential for Real-Time, Real-World, and Comprehensive Data
      3. Supporting Research Uses
        1. Linking Patients to Clinical Studies
        2. Real-Time Patient Benefits from Comparative Effectiveness Research
    15. VIII. Guidance to Agencies
      1. Introduction
      2. A Feasible Roadmap to the Future
      3. Guidance on Necessary Design Choices
      4. Guidance on Meaningful Use Requirements
    16. IX. Recommendations
    17. References
      1. 1.
      2. 2.
      3. 3.
      4. 4.
      5. 5.
      6. 6.
      7. 7.
      8. 8.
      9. 9.
      10. 10.
      11. 11.
      12. 12.
      13. 13.
      14. 14.
      15. 15.
      16. 16.
      17. 17.
      18. 18.
      19. 19.
      20. 20.
      21. 21.
      22. 22.
      23. 23.
      24. 24.
      25. 25.
      26. 26.
      27. 27.
      28. 28.
      29. 29.
      30. 30.
      31. 31.
      32. 32.
      33. 33.
      34. 34.
      35. 35.
      36. 36.
      37. 37.
      38. 38.
      39. 39.
      40. 40.
      41. 41.
      42. 42.
      43. 43.
      44. 44.
      45. 45.
      46. 46.
      47. 47.
      48. 48.
      49. 49.
      50. 50.
      51. 51.
      52. 52.
      53. 53.
      54. 54.
      55. 55.
      56. 56.
      57. 57.
      58. 58.
      59. 59.
      60. 60.
      61. 61.
      62. 62.
      63. 63.
      64. 64.
      65. 65.
      66. 66.
      67. 67.
      68. 68.
      69. 69.
      70. 70.
      71. 71.
      72. 72.
      73. 73.
      74. 74.
      75. 75.
      76. 76.
      77. 77.
      78. 78.
      79. 79.
      80. 80.
      81. 81.
      82. 82.
      83. 83.
      84. 84.
      85. 85.
      86. 86.
      87. 87.
      88. 88.
      89. 89.
      90. 90.
      91. 91.
    18. Appendices
      1. Appendix A: Expert Input
      2. Appendix B: Acknowledgments
      3. Appendix C: Glossary
        1. Anonymize
        2. Authentication
        3. Authorization
        4. Clinical decision support
        5. Cloud-based
        6. Comparative effectiveness research
        7. Data element access services
        8. Data-centric
        9. Data element indexing
        10. De-identified
        11. Digital signature
        12. Electronic health record
        13. Encryption
        14. Genotype
        15. Health information exchange
        16. Health information technology
        17. HITECH Act
        18. Integration engines
        19. Key
        20. Meaningful use
        21. Metadata
        22. Metadata tag
        23. Middleware
        24. Patient-centric
        25. Personal health record
        26. Personalization
        27. Physician Quality Reporting Initiative
        28. Post-marketing surveillance
        29. Primary care medical home
        30. Randomized clinical trials
        31. Semantics
        32. Service-oriented architecture
        33. Standardized health records
        34. Syndromic surveillance
        35. Syntax
        36. Tagged data elements
        37. Two-factor authentication
        38. Universal exchange language
        39. Usability
        40. Value-based purchasing
        41. VistA
        42. XML
      4. Appendix D: Abbreviations

 

 

Story

My Four Phases of Ontology for EHR:

1. President Bush 2004: “By computerizing health records, we can avoid dangerous medical mistakes, reduce costs, and improve care.”
http://georgewbush-whitehouse.a...­

Note: Obama Administration starts VA Blue Button for Personal Health Records

2. SICoP and Ontolog Forum Propose Ontological Engineering to ONC in 2005: http://ontolog.cim3.net/cgi-bin...­

Note: Health Datapalooza V June 2014: I tell ONC my experience and they admit they should have used Ontological Engineering! Cite Session I attended and what I said there and the response afterwards to have me apply for a fellowship.

3. HL7 EHR Interoperability Work Group in 2007 Mentions SICoP: http://semanticommunity.info/Health_Level_7

Note: Stakeholders who mentioned social or process interoperability in their definitions tended to be clinical process oriented, including management engineering; others were “next generation” sources and academics (the Federal CIO Council's Semantic Interoperability Community of Practice SICoP, the Institute of Medicine) and several were non-U.S.

4. Dr. Oliver Bohdenrider's NIH UMLS Group starts to help ONC: http://semanticommunity.info/Da...­

Note: President of AMA Says Meaningful Use would be integration of largest EHRs for big data to study rae diseases.

My comments on the Two Key Reports

1. Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering

This report, which was informed by the deliberations of a working group comprised of PCAST members and prominent health-care and systems-engineering experts, identifies a comprehensive set of actions for enhancing health care across the Nation through greater use of systems-engineering principles. Systems engineering, widely used in manufacturing and aviation, is an interdisciplinary approach to analyze, design, manage, and measure a complex system in order to improve its efficiency, reliability, productivity, quality, and safety  It has often produced dramatically positive results in the small number of health-care organizations that have incorporated it into their processes.But in spite of excellent examples, systems methods and tools are not yet used on a widespread basis in U.S. health care.

Note: The Semantic Community example is Be Informed for HealthCare.gov

2. Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward

The recent Government BIG DATA Symposium, June 17-18, included two presentations by the Office of the National Coordinator for Health Information Technology as follows:

Dr. Julia Skapik, Medical Officer, Office of the National Coordinator for Health Information Technology, DHHS
“ONC/HIT Perspectives and Initiatives” Slides

Ms. Mera Choi, Chief, Standards Division, Office of Science and Technology, Office of the National Coordinator for Health Information Technology (ONC/HIT), DHHS “Standards and Interoperability in Health Data Initiatives” Slides See CDE Browser and S&I Framework Wiki

The recent Health Datapalooza V included two sessions of interest that I attended

HHS Initiatives to Accelerate Innovative Data Applications

Participants:

  • Jacob Reider, MD, Office of the National Coordinator for Health Information Technology
  • Jon White, MD, Agency for Healthcare Research & Quality, Health & Human Services
  • Doug Fridsma, MD, PhD, Office of the National Coordinator for Health Information Technology
  • Josh Mandel, MD, Harvard Medical School
  • Joy Pritts, JD, Office of the National Coordinator for Health Information Technology
     

The Office of the National Coordinator for Health Information Technology (ONC) is working every day to foster the availability
and use of health data to drive innovations that improve health and health care. In this session, you’ll learn about how ONC’s
technical standards enable people to access, use and display health information in new ways, including the Consumer Information
Exchange portfolio and Data Access Framework. We’ll also discuss how startups can build privacy and security into each layer of
app development, and the role of clinical and consumer decision support in sharing knowledge in standard forms so patients and
providers can make better, evidence-based choices. Finally, we’ll talk about how an ONC grant led to the creation of SMART
Platforms. SMART is an open standards-based approach using FHIR, OAuth, and the Web to integrate third-party apps with
Health IT systems.

DataLab

Moderators

  • Justine Carr, MD, Chair, National Committee on Vital and Health Statistics Workgroup on Data Access and Use
  • Damon Davis, US Department of Health and Human Services

Your opportunity to meet some of the federal government data experts is here. This year we’ll tell some of the inspiring stories
of how innovators are using data complimented by the background information on how and why the data was collected and
curated as told by the data stewards. Come learn how to use assets from the Departments of Health & Human Services, other
Federal agencies and state governments from the individuals who champion action in improving public access to information to
catalyze innovation. Each agency in the federal government is staffed by experts who are well versed in the division’s information
resources available on data.gov (administrative data, survey data, research data, medical/scientific content, etc.). The DataLab will
also feature opportunities for focused discussions with data experts for “deep dives” into agency resources. There will be live
demonstrations and announcements of new data resources. The goal of the session is to give innovators and entrepreneurs an
overview of new, updated and emerging datasets that can be used to support new applications and services.​

MORE TO FOLLOW

Slides

Julia Skapik, MD, MPH

Slides

Office of Standards & Technology
Office of the National Coordinator for Health IT
Julia.skapik@hhs.gov
(202)475‐2470

ONC Opportunities in Health IT and Big Data

JuliaSkapik06172014Slide1.png

Stay connected, communicate, , and collaborate visit . . .

JuliaSkapik06172014Slide3.png

The Learning Healthcare System Workshop Summary

JuliaSkapik06172014Slide17.png

The Current Frontier: The Health IT Interoperability Problem

JuliaSkapik06172014Slide41.png

Current State

JuliaSkapik06172014Slide42.png

The Interoperability Problem in Healthcare

JuliaSkapik06172014Slide43.png

Future Vision

JuliaSkapik06172014Slide44.png

“Old” vs. “New”Data Element: Ethnicity

JuliaSkapik06172014Slide45.png

SDC Data Element Definition Framework

JuliaSkapik06172014Slide46.png

Where Is Health IT Moving?

JuliaSkapik06172014Slide47.png

JASON Report: Recommendations for Unified Federal Health Data Architecture

JuliaSkapik06172014Slide48.png

Where Is Health IT Moving?

JuliaSkapik06172014Slide49.png

Mera Choi

Slides

S&I Framework Coordinator
Office of the National Coordinator for Health IT

ONC website: http://www.healthit.gov/
S&I Framework Wiki: http://wiki.siframework.org/

S&I Framework: The Role of Standards in Supporting Healthcare Data Initiatives

MeraChoi06172014Slide1.png

S&I Framework and Big Data

MeraChoi06172014Slide6.png

How S&I Supports Healthcare Goals using Big Data

MeraChoi06172014Slide7.png

S&I Initiatives

MeraChoi06172014Slide8.png

Structured Data Capture (SDC)

MeraChoi06172014Slide9.png

SDC Data Collection

MeraChoi06172014Slide10.png

Data Access Framework (DAF)

MeraChoi06172014Slide11.png

DAF Targeted Access

MeraChoi06172014Slide12.png

Conclusion

MeraChoi06172014Slide13.png

Questions and Discussion

MeraChoi06172014Slide14.png

Spotfire Dashboard

Research Notes

President Bush 2004

Source: http://georgewbush-whitehouse.archiv...404/chap3.html

Note: This is historical material, "frozen in time." The web site is no longer updated and links to external web sites and some internal pages will not work.

Promoting Innovation and Competitiveness
 

A New Generation of American Innovation

 

Transforming Health Care: The President’s Health Information Technology Plan

“By computerizing health records, we can avoid dangerous medical mistakes, reduce costs, and improve care.”

--President George W. Bush, State of the Union Address, January 20, 2004

  • President Bush has outlined a plan to ensure that most Americans have electronic health records within the next 10 years.The President believes that better health information technology is essential to his vision of a health care system that puts the needs and the values of the patient first and gives patients information they need to make clinical and economic decisions – in consultation with dedicated health care professionals.
  • The President’s Health Information Technology Plan will address longstanding problems of preventable errors, uneven quality, and rising costs in the Nation’s health care system.

The Problem: Challenges to the U.S. Health Care System

Executive Summary

Hydrogen Fuel Technology: A Cleaner and More Secure Energy Future

Transforming Health Care: The President's Health Information Technology Plan

Promoting Innovation and Economic Security Through Broadband Techonolgy

Better Education for Better Jobs

Making Federal Job Training Work Better for America's Workers

  • The U.S. health care system has a long and distinguished history of innovation. Discoveries move from the laboratory bench to the bedside, as basic research results are translated into new understanding of diseases, better diagnostic tools, and innovative treatments.
  • At the same time, our health care system faces major challenges. Health care spending and health insurance premiums continue to rise at rates much higher than the rate of inflation. Despite spending over $1.6 trillion on health care as a Nation, there are still serious concerns about preventable errors, uneven health care quality, and poor communication among doctors, hospitals, and many other health care providers involved in the care of any one person.
    • The Institute of Medicine estimates that between 44,000 and 98,000 Americans die each year from medical errors. Many more die or have permanent disability because of inappropriate treatments, mistreatments, or missed treatments in ambulatory settings. Studies have found that as much as $300 billion is spent each year on health care that does not improve patient outcomes – treatment that is unnecessary, inappropriate, inefficient, or ineffective.
  • All these problems – high costs, uncertain value, medical errors, variable quality, administrative inefficiencies, and poor coordination – are closely connected to our failure to use health information technology as an integral part of medical care. The innovation that has made our medical care the world’s best has not been applied to our health information systems. Other American industries have harnessed advanced information technologies, to the benefit of American consumers. Our air travel is safer than ever, and consumers now have ready and safe access to their financial information. Unlike these other industries, medicine still operates primarily with paper-based records. Our doctors and nurses have to manage 21st century medical technology and complex medical information with 19th century tools. America’s medical professionals are the best and brightest in the world, and set the standard for the world. It is a testament to their skill that they are able to achieve high-quality care in this antiquated system. In this outdated, paper-based system:
    • A patient's vital medical information is scattered across medical records kept by many different caregivers in many different locations – and all of the patient’s medical information is often unavailable at the time of care. For example, patients with medical emergencies too often are seen by doctors with no access to their critical medical information, such as allergies, current treatments or medications, and prior diagnoses.
    • Physicians keep information about drugs, drug interactions, managed care formularies, clinical guidelines, and recent research in memory – a difficult task given the high volume of information.
    • Medical orders and prescriptions are handwritten and are too often misunderstood or not followed in accordance with the physician’s instructions.
    • Consumers lack access to useful, credible health information about treatment alternatives, which hospitals and physicians are best for their needs, or their own health status.
    • Physicians do not always have the best information to select the best treatments for their patients, resulting in an unacceptable lag time before new scientific advances are used in patient care. They also do not have ready access to complete information about their patients, do not know how other doctors are treating their same patients, or how other health care providers around the country treat patients with the same condition. These conditions set the stage for preventable medical errors.

The Solution – Health Information Technology

  • Today, the President announced an ambitious goal of assuring that most Americans have electronic health records within the next 10 years.
    • Within the next 10 years, electronic health records will ensure that complete health care information is available for most Americans at the time and place of care, no matter where it originates. Participation by patients will be voluntary.
    • These electronic health records will be designed to share information privately and securely among and between health care providers when authorized by the patient.
  • President Bush believes that innovations in electronic health records and the secure exchange of medical information will help transform health care in America - improving health care quality, preventing medical errors, reducing health care costs, improving administrative efficiencies, reducing paperwork, and increasing access to affordable health care.
  • The steps we need to take across the Nation are already underway in some places. Health information technologies – electronic medical records, computerized ordering of prescriptions and other medical tests, clinical decision support tools, and secure exchange of authorized information – improve quality, reduce medical errors, and prevent deaths. In the past three years, some communities, hospitals, clinicians, patient groups, and information technology companies have acted to improve their health information systems. These pioneering communities are taking the initiative and showing that health care can and must be modernized.
  • The President envisions a dramatically changed system:
    • When arriving at a physician’s office, new patients do not have to enter their personal information, allergies, medications, or medical history, since it is already available.
    • A parent, who previously had to carry the child’s medical records and x-rays in a large box when seeing a new physician, can now keep the most important medical history on a keychain, or simply authorize the new physician to retrieve the information electronically from previous health care providers.
    • Arriving at an emergency room, a senior with a chronic illness and memory difficulties authorizes her physicians to access her medical information from a recent hospitalization at another hospital - thus avoiding a potentially fatal drug interaction between the planned treatment and the patient’s current medications.
    • Three patients with unusual sudden-onset fever and cough that would not individually be reported, show up at separate emergency rooms, and the trend is instantly reported to public health officials, who alert authorities of a possible disease outbreak or bioterror attack.

The President’s Health Information Technology Plan

  • To achieve his 10-year goal, the President is taking the following steps to urge coordinated public and private sector efforts that will accelerate broader adoption of health information technology:
    • Adopting Health Information Standards. The President called for the completion and adoption of standards that will allow medical information to be stored and shared electronically while assuring privacy and security. The necessary work is already well underway and much of it has already been completed. In the last several years, the Department of Health and Human Services (HHS) has been collaborating with the private sector and other Federal agencies to identify and endorse voluntary standards that are necessary for health information to be shared safely and securely among health care providers. Federal agencies are accelerating their use of these standards. As part of this effort, HHS has recently negotiated and licensed a comprehensive medical vocabulary and made it available to everyone in the Nation at no cost. The results of these projects include standards for:
      • Transmitting X-Rays Over the Internet: Today, a patient’s chest x-ray can be sent electronically from a hospital or laboratory and read by the patient’s doctor in his office.
      • Electronic Laboratory Results: Laboratory results can be sent electronically to the physician for immediate analysis, diagnosis and treatment, and could be automatically entered into the patient’s electronic health record if one existed. For example, a doctor could retrieve this information for a hospitalized patient from his office, assuring a prompt response and eliminating errors and duplicative testing due to lost laboratory reports.
      • Electronic Prescriptions: Patients will save time because prescriptions can be sent electronically to their pharmacists. By eliminating illegible handwritten prescriptions, and because the technology automatically checks for possible allergies and harmful drug interactions with other drugs, standardized electronic prescriptions help to avoid serious medical errors. The technology also can generate automatic approval from a health insurer.
    • Doubling Funding to $100 Million for Demonstration Projects on Health Care Information Technology. To build upon the progress already made in the area of health information technology standards over the last several years, the President’s proposed FY 2005 budget includes $100 million for demonstration projects that will help us test the effectiveness of health information technology and establish best practices for more widespread adoption in the health care industry.
      • This increase builds on the President’s FY 2004 budget which included $50 million, and these new resources will support more local and regional grants so that pioneering communities, physicians, and hospitals can show that health care can be transformed by adopting and implementing health information technology.
      • In April 2004, more than 600 applications for funding were received for these grants, and HHS will be awarding grants this summer, following their peer-reviewed process for selecting grantees.
    • Using the Federal Government to Foster the Adoption of Health Information Technology.As one of the largest buyers of health care – in Medicare, Medicaid, the Community Health Centers program, the Federal Health Benefits program, Veterans medical care, and programs in the Department of Defense – the Federal Government can create incentives and opportunities for health care providers to use electronic records, much like the private sector is doing today. The President will direct these agencies to review their policies and programs and propose modifications and new actions, and to forward the recommendations to him within 90 days.
    • Creating a New, Sub-Cabinet Level Position of National Health Information Technology Coordinator. The President announced that he is creating a new sub-Cabinet level post at HHS, to provide national leadership and coordination necessary to achieve his 10-year goal. The individual will report directly to the HHS Secretary, and will be charged by the President with:
      • Guiding ongoing work on health information standards and working to identify and implement the various steps needed to support and encourage health information technology in the public and private health care delivery systems.
      • Coordinating partnerships between government agencies and private sector stakeholders to speed the adoption of health information technology.

SICoP and Ontolog Forum Propose Ontological Engineering to ONC in 2005

The Ontolog Community's open Response to the National Health Information Network RFI (Word: See Below) (of 2004.11.15), collaboratively authored by the NhinRfi response team, was delivered to the office of Dr. David Brailer, National Coordinator for Health Information Technology, on Jan. 18, 2005.

Response to ONCHIT NHIN RFI #4150-24

Source: http://ontolog.cim3.net/file/work/he...e_20050118.doc (Word)

Prepared by Ontolog Community

Date January 18, 2005

C-K, S-B, N-B:

Background

This RFI response is the product of the Ontolog community (http://ontolog.cim3.net) based on work done by a project team that included:

Active Participants

Nad Bhatti - Client Service Executive, Noblestar

Patrick Cassidy, Ph.D. - Ontologist, MITRE

Edward Cherlin -, Mathematician, Free Software Developer, Market Researcher

Anthony Cheung, Ph.D. - Professor of Clinical Pathology, Vice Chair for Research, Director of Biomedical Engineering in Pathology, UC Davis

Christopher Chute, M.D., Ph.D. - Professor and Chair, Biomedical Informatics, Mayo Clinic College of Medicine

Kurt Conrad - President, The Sagebrush Group (Lead Editor)

Michael Hogarth, M.D. - Associate Professor of Pathology and Laboratory Medicine, Director of Informatics in Pathology, Professor in Department of Pathology, UC Davis

Paul Koch, Ph.D. - Account Executive, Kevric Corporation

Mark Musen, M.D., Ph.D. - Stanford U. Medical Informatics, Stanford School of Medicine (Co-Convener)

Bo Newman - Founder, KM Forum

Brand Niemann, Ph.D. - Computer Scientist and XML and Web Services Specialist in the Office of Environmental Information, US EPA (Co-Convener)

Natasha Noy, Ph.D. - Senior Research Scientist, Stanford Medical Informatics, Stanford University School of Medicine

Adam Pease - CEO of Articulate Software, formerly Program Manager and Director of Knowledge Systems at Teknowledge

Chris Richardson - Director and Secretary, WorldVistA

Mark Roest - OpenVista

Nicolas Rouquette - Principal Member of Technical Staff, Jet Propulsion Laboratory

Bob Smith, Ph.D. - Prof. Emeritus, Cal State University, Long Beach (Co-Convener / Project Manager)

Samson Tu, Ph.D. - Senior Research Scientist, Stanford Medical Informatics, Stanford University School of Medicine

David Whitten, Treasurer, WordVistA

Peter Yim - President & CEO, CIM Engineering, Inc. (Co-Convener)

Authors (w/ codes)

            B-N      Nad Bhatti

            C-K      Kurt Conrad

            M-M    Mark Musen

            N-B      Bo Newman

            P-A      Adam Pease

            S-B      Bob Smith

            Y-P      Peter Yim

Although our work process involved distributing the complete RFI to all participants, individuals tended to focus on specific portions of the RFI.  To ease readability and understanding, individual passages are credited to their respective authors. In addition to the credited authors, however, it is important to recognize that many others participated in the process and many of their views are represented throughout the various responses.  Project details, working notes, and meeting minutes can be accessed at http://ontolog.cim3.net/cgi-bin/wiki.pl?NhinRfi.

About Ontolog

Ontolog is an open, international, virtual community of practice working on business domain ontologies.  It has over 100 members spread over 13 countries, to date.  The community was convened in 2002 to:

  • Discuss practical issues and strategies associated with the development of both formal and informal ontologies used in business, and
  • Identify ontological engineering approaches that might be applied to eBusiness standardization efforts.

Towards these ends, the Ontolog community has been working actively with the OASIS UBL technical committee, a number of associated international standards bodies that are contributing to the development of open eCommerce standards, various groups within the federal government that are concerned with semantic interoperability, and groups within the health care community that are involved with conceptual modeling and formalization.  Ontolog welcomed the opportunity presented by the RFI to consolidate and extend our thinking about the application of ontological engineering as it applies to health care.

What are Ontologies?

A formalized ontology is nominally an explicit specification of the conceptual understandings shared by a community of practice.  A formalized ontology seeks to provide complete, explicit, and unambiguous semantics for a targeted set of concepts within a domain of discourse, expressed in a computable language.

Ontologies are a key enabler for semantic interoperability between disparate systems.  For that reason, ontologies and ontological engineering represent emerging models for advanced IT systems, and are getting increased attention from both system developers and those responsible for setting IT policy.  Because ontologies allow various aspects of policy to be “abstracted out” of the system, enabling them to be managed and updated separately, they enable more sophisticated automated behaviors than would be practical with traditional, hard-coded software development approaches.

Ontologies in Health Care

Medical ontologies are not a new idea.  NIH, for example, is already an established leader in this field (see Kathy Lesh’s slides from Dec 9,2004 at http://colab.cim3.net/file/work/Expedition_Workshop/2004-12-09_CoherenceInKnowledge/Kevric-NSF-2004_12_09.ppt). Protégé, which is partially funded by NIH, is one the leading ontology development tools.  Space does not allow us to provide a complete inventory of all applicable examples (see the www.openclinical.org portal for specific initiatives), but the trends are clear.

Y-P, P-A, M-M, S-B, C-K:

Thesis

We believe that the development, refinement, and integration of advanced biomedical ontologies are critical to the success of the NHIN.

Our argument includes the following:

  • An assessment of some of the fundamental "Problems" that ONCHIT ‘s NHIN initiative is likely to encounter.
  • A listing of core design principles that will be essential to the development of a viable solution.
  • Elements of an overall implementation strategy, designed to deal with the identified issues.

Various past and current efforts at information integration have failed because of the following reasons:

  • Information models are created from scratch, rather than reusing earlier work.  This entails wasted effort from debugging and validating the new models, rather than reusing existing debugged and validated models.
  • Information models are created, ad hoc, by individuals and/or committees who are not systematically extending validated foundational models and who are not trained in the appropriate disciplines.
  • Information models fail to conform to the best practices of the knowledge representation and applied philosophy communities.  This is related to the reuse issue, described above.  The resulting models repeat prior mistakes instead of leveraging existing solutions
  • The representation languages which are used are either/both:
  • Informal -- Leaving the interpretation of the model to human comprehension of ambiguous natural language.
  • Insufficiently expressive -- Leading to the improper overloading of simple representational features.
  • Issues of concept definition are confused with issues of language (terminology) and/or issues of knowledge (facts).
  • Insufficient tool support.
  • Insufficient education and training of model authors.
  • The existence of too many implicit assumptions in the resulting models that make them brittle.  These assumptions are often undermined at a later time, when program scope changes or is expanded.
  • A divergence of models created by different authors, due to the lack of an objective and automated conformance and validation process.

We believe that in order for the vision of the National Health Information Network to be realized, the resulting system must be designed around the following architectural principles:

  • Reliance on open information models that can evolve and support industrial, governmental, and academic participants and thus enable the development of open software tools.
  • Use of formal ontologies, where the meanings of all terms are made explicit and the language in which the definitions are expressed is also open, formally defined, standard, machine-understandable, and computable.
  • All formalized semantics reflect the real-world terms and definitions used for the most common and general concepts in our world.  This needs to be done to ensure 1) effective communication among practitioners and patients (the ultimate users of any solution), and 2) that the conceptual scope is defined sufficiently-broadly to accommodate future requirements, opportunities, and expansions.

We propose the following be included in the NHIN to ensure that the resulting systems meet all of the technical, social, and policy challenges that they can be expected to encounter:

  • The use of open-source ontology development tools and environments (such as Protégé).
  • The use and reuse of formal ontologies -- in general -- and the adoption of a formal, common, upper ontology, in particular (such as one which could be developed through the mapping of the HL-7 RIM into SUMO).  This would allow domain ontologies to be developed as extensions of the common upper ontology in such a way as to ensure compatibility, interoperability, and efficient use of development resources.
  • The use of standard formal representation languages (such as the Ontology Web Language and Simplified Common Logic).
  • A program of education to train key organizations and personnel about ontology building, ontology reuse, and ontology tools, and ontology-based system architecture and design.
  • An objective and automated formal conformance and validation process for health and medical ontologies.
  • Reliance on an open collaboration model of stakeholder engagement.  This would include the engagement (and possibly even the formation) of multiple, open communities of practice to harness the distributed human, knowledge, and financial resources that could bootstrap and speed the development and continuous improvement of the envisioned National Health Information Network.

General

1.   The primary impetus for considering a NHIN is to achieve interoperability of health information technologies used in the mainstream delivery of health care in America. Please provide your working definition of a NHIN as completely as possible, particularly as it pertains to the information contained in or used by electronic health records. Please include key barriers to this interoperability that exist or are envisioned, and key enablers that exist or are envisioned. This description will allow reviewers of your submission to better interpret your responses to subsequent questions in this RFI regarding interoperability.

C-K, S-B, N-B:

Our answers address difficulties that the Ontolog group has with ONCHIT’s definition of the NHIN.

The Request For Information by the Office of the National Coordinator for Health Information Technology (ONCHIT) solicits the health community and other interested parties to identify potential issues with the design and road map for the NHIN, and by so doing, seek to improve the final proposal and resulting implementations.

At first, it appeared unclear to us whether the RFI was describing merely an IT system, or sought input on the whole system, including critical aspects of the associated social networks.  Although ONCHIT's currently envisioned solution is not described explicitly in the RFI, it is possible to make assumptions about it based on the nature of the questions asked and the wording of those questions.

The document appears to reflect an ongoing series of discussions with health information professionals.  The four explicit goals listed in the RFI are an excellent starting point, but they are not fully reflective of the full sets of interests (and associated values) that will need to be applied to design viable solutions.  We can expect to see numerous tradeoffs that will make it prohibitively difficult to predict the resulting negotiated policies without such broad-based involvement.

More specifically, the RFI seems be based on the idea of a monolithic database solution.  Although the term "network" is used throughout, we are unclear about how it differs for a database solution.  In fact, the term "network" could be replaced by "database" at most points in the document with no discernable change in meaning.  Consistent with this interpretation, most of the issues that are presented for comment are typical of large database initiatives.

For example, we see in question #23 a discussion of the design principles for a technical architecture.  We find this to be incredibly limited and problematic, as our working definition of the NHIN is not just an IT network but includes the broader social networks that will interact with the resulting automated systems.  We view the NHIN has a complex, indeed "organic" system, that cannot be reliably engineered.  The recent news reports of the problems that the FBI had with their multi-million dollar Virtual Case Management system is but one example of this phenomenon (LA Times, Jan 13, 2005: "New FBI Software May Be Unusable").  From working on large IT systems and reviewing the work of others, we have concluded that it is prohibitively difficult to engineer large, organic solutions.  Instead, you should focus on engineering the context for emergence, as any single technical architecture will either be inherently unstable or function as a barrier to needed change.

Our working definition of the NHIN anticipates various technologies and technology capabilities throughout its lifespan.  It anticipates that processes, policies, and practices will evolve through time.  It expects that the perceptions, understandings, and prioritizations of needs and opportunities will change, as well.  In short, we expect the NHIN to be naturally dynamic, supported by iterative and distributed software development cycles.  Instead of a single monolithic system, we expect that the NHIN will look more like the World Wide Web, where multiple tools and systems interact on the basis of established data standards.  These tools and systems developed and administered in a distributed fashion, enabling the NHIN to be able to evolve to meet changing objectives.

But data standards, alone, are not likely to be sufficient.  Data standards enable interoperability across multiple tools, but here we need to ensure interoperability across complete architectures and even "interoperability" between automated systems, the various policy making apparatus that will interact with it, doctors, patients, and others.  This will require a rich set of languages, standards, and conventions.  We are dealing with some 4,000 hospitals, over 800,000 physicians, and nearly 300,000,000 patients. How can alignment be ensured across these various contexts?  This is where the formalization of ontologies becomes critical and why we recommend that ontological development become a central aspect of the NHIN architecture.

Although much ontological work is currently being done within the health care community (see www.openclinical.org), the efforts are somewhat chaotic and not likely to supporting the NHIN's goals of reliable interoperability.  These efforts serve as a good starting point, but need to be augmented.  It is our view, that by taking an ontological approach to support the distributed development, implementation, and operation of the NHIN, many of the issues outlined in the RFI will be resolved at a fundamental level, without the need for significant corrective action.

If properly conceived of an implemented, the NHIN will function not just as an information network, moving data, but a knowledge network, enabling intelligent behavior across a wide range of automated, organizational, and individual agents.  Focusing policy and architecture on knowledge utilization and performance will enable and accelerate the formation and application of new knowledge, identify and eliminate incorrect and obsolete knowledge, and improve the flow of critical knowledge assets into the hands of those who need it, both practicing physicians, their anxious patients, and others.

P-A:

A key aspect of successful interoperability is shared meaning. The current state of practice in information systems is to develop interfaces between pairs of systems, where the interface strictly addresses the information of concern only to that pair. Efforts to employ common syntax are a necessary start, but do not solve the interoperability problem.

Much effort is currently being spent on redefining data models in XML syntax. Sharing a standard syntax can greatly improve the ease of integration across a large infrastructure. However, shared syntax is not sufficient without shared meaning. For that reason, an increasing amount of effort in the IT industry is being spent on developing shared XML schema. However, that too is insufficient, since such efforts tend to address constrained domains that are likely to break when requirements expand. Such efforts, by being specific to particular industries, also fail to reuse the best and most general information models that exist across domains. Lastly, even when schemas are shared and terms are carefully defined in English (or another human language), the meaning of a term is only as clear as its English definition. English sentences are invariably subject to ambiguity, vagueness and issues of how context affects meaning and interpretation.

The solution we envision has several parts, to address each of the key barriers just described. We believe that shared meaning is a critical aspect of interoperability. To have shared meaning we must have not only a common syntax, but also a common vocabulary. That common vocabulary should be defined in terms of the broadest and most general foundation concepts, in order to have robustness when requirements change or expand. The common vocabulary must be defined in a formal and computable language, so that interpretation of meaning can be supported by computers, and not subject to human interpretation. The common vocabulary should reuse as much general conceptual infrastructure as possible, in order to amortize costs over the widest possible set of interfaces, and to ensure the quality that comes from repeated use and testing of common information products.

Specifically, we believe that a formal upper ontology, defined in logic, is a necessary component in achieving large-scale interoperability. We envision a hierarchy of ontologies that build from a common semantic foundation.

2.   What type of model could be needed to have a NHIN that: allows widely available access to information as it is produced and used across the health care continuum; enables interoperability and clinical health information exchange broadly across most/all HIT solutions; protects patients’ individually-identifiable health information; and allows vendors and other technology partners to be able to use the NHIN in the pursuit of their business objectives? Please include considerations such as roles of various private- and public- sector entities in your response.

P-A:

A fully formal and logical model will help to ensure that clients and participants in a common health network will be able to understand how to connect to the common information model. The current practice often involves discussion with model "experts" or authors in order to understand fully what is meant by each term. A formal model will help ensure that all information and context is fully explicit, and nothing is left unstated and only in the head of the designer.

We believe that a completely open information model is also a necessity. Vendors must be able to use the common model without fee in order to spur adoption. The open source model will mean that academic institutions will be able to employ student resources to assist in infrastructure development, research and use, which would be much less likely if models were costly and proprietary.

While a formal, common information model does not directly address privacy issues, the use of a general upper model will ensure that many real-world aspects that have an impact on privacy can be successfully modeled, and therefore be taken into account in an integrated system that handles privacy concerns in both storage and access.

3.   What aspects of a NHIN could be national in scope (i.e., centralized commonality or controlled at the national level), versus those that are local or regional in scope (i.e., decentralized commonality or controlled at the regional level)? Please describe the roles of entities at those levels. (Note: “national” and  “regional” are not meant to imply federal or local governments in this context.)

P-A:

We believe that a hierarchy of information models will be needed. The upper ontology will be centralized and standard. We believe that there will be significant benefit in having some standardized, centralized body of health ontology information as well. If there is a proliferation of vocabularies with overlapping semantics, we will not be able to achieve the goal of interoperability.

There have been several barriers to large common information models in the past

  • The language in which models have been stated is insufficiently expressive, leading to "overloading" of language aspects for uses they were not intended
  • The language is insufficiently explicit, leading to a "grab bag" of models which are not provably overlapping, but which in fact are mutually redundant or inconsistent
  • The language is insufficiently formal, requiring human experts to understand the implicit definitions of terms in the model in order to assess whether model additions are redundant or contradictory
  • The model doesn't inherit from a common upper model, leading to duplication of general purpose concepts, and a proliferation of incompatible upper level concepts which each build in different simplifying assumptions.

Organizational and Business Framework

4.   What type of framework could be needed to develop, set policies and standards for, operate, and adopt a NHIN? Please describe the kinds of entities and stakeholders that could compose the framework and address the following components:

C-K, S-B, N-B:

To function as an effective mechanism for alignment, a formalized ontology should reflect shared conceptualizations.  Developing consensus around the "social ontology" can be difficult.  As we pondered this issue, we initially envisioned some type of policy board working in parallel to the recommended ontological engineering effort to provide input and resolve issues of semantic ambiguity, when they arise.

When we learned about the existence of the Dr. Brailer's Leadership Panel, comprised of the CEOs and CIOs from Fortune 500 companies, we saw this as an excellent basis for forming the need policy board.  As they represent a significant portion of the demand for health care (roughly 60% of spending, see http://www.cio.com/archive/101504/healthcare.html ), they represent a balanced set of interests involving both cost effectiveness and quality of care.

Augmented with appropriate governmental and NGO interests, the resulting policy board would not only enable the efficient resolution of various ontology policy and ontology engineering issues, but could be expected to effectively address other strategic health policy issues, as well.

a.   How could a NHIN be developed? What could be key considerations in constructing a NHIN? What could be a feasible model for accomplishing its construction?

C-K, S-B, N-B:

Central to our thesis is that the NHIN needs to be (and will be) developed in a decentralized, distributed fashion.  Formalized ontologies will enable the necessary data standards and policies to be effectively aligned.  Further, we expect that the policy board, when properly engaged will identify opportunities for operational improvement and associated automation opportunities that, in many cases, will be implemented without centralized funding.  If the policy board is augmented with a clearing house to collect lessons learned, best practices, and the results of other prototyping activities, local successes will be able to be scaled, as appropriate.

b.   How could policies and standards be set for the development, use and operation of a NHIN?

C-K, S-B, N-B:

This is one of the primary functions of the envisioned policy board.  The primary challenge is to balance competing stakeholder interests and not let narrow sectors dominate decision-making.  Leveraging representatives of the Fortune 500 helps ensure the balanced set of commercial and economic interests required for patient-centric policies and solutions.

c.   How could the adoption and use of the NHIN be accelerated for the mainstream delivery of care?

C-K, S-B, N-B:

Open standards and processes enable distributed development and experimentation.  Successes can be leveraged.  Mistakes can be marginalized.  Formalized ontologies ensure needed levels of alignment and interoperability.

d.   How could the NHIN be operated? What are key considerations in operating a NHIN?

5.   What kind of financial model could be required to build a NHIN?  Please describe potential sources of initial funding, relative levels of contribution among sources and the implications of various funding models.

C-K, S-B, N-B:

Can expect to need seed funding for the policy board, ontology engineering functions, and resulting development of data standards.  Some development projects are all but certain to be funded independently based on local business value and/or commercial opportunity.  Some project will need more centralized funding, based on the recommendations of the policy board.

6.   What kind of financial model could be required to operate and sustain a functioning NHIN?  Please describe the implications of various financing models. 

C-K, S-B, N-B:

Expect a mix of both local and centralized funding.

7.   What privacy and security considerations, including compliance with relevant rules of the Health Insurance Portability and Accountability Act of 1996 (HIPAA), are implicated by the NHIN, and how could they be addressed?

C-K, S-B, N-B:

This is a complicated set of related issues that will have to be worked out through time.  The important thing is to design system and associated technical architectures that will enable these policy changes to be implement with least disruption.  We believe that ontology-based architectures are critical to ensuring the longevity of investments in the face of the anticipated policy changes.         

8.   How could the framework for a NHIN address public policy objectives for broad participation, responsiveness, open and non-proprietary interoperable infrastructure?

C-K, S-B, N-B

The strong consumer interests on the proposed policy board will help ensure that the resulting data standards and specifications are open and provide a baseline for competition, not restrict it.

Management and Operational Considerations

9.   How could private sector competition be appropriately addressed and/or encouraged in the construction and implementation of a NHIN?

C-K, S-B, N-B:

If consumer interests are empowered to drive the core policies and standards, they can be expected to work to ensure competition. Once the large consumer interests on the policy board reach consensus on needed functionality, we can expect many to implement these capabilities within their own companies to realize the associated cost savings.  From there it is a relatively small step to sharing and system-wide deployment.

Open ontologies and open data standards will facilitate multiple, commercially-viable implementations and enable software providers to identify a niche markets that result in a wider variety of tools and solutions.  Accordingly, our recommendation can be expected to result in a competitive market for the technology suppliers and consumers involved in the construction and implementation of the NHIN.

10. How could the NHIN be established to maintain a health information infrastructure that:

a.   evolves appropriately from private investment;

b.   is non-proprietary and available in the public domain;

c.   achieves country-wide interoperability; and

d.   fosters market innovation.

B-N:

There are several factors that will be important for maintaining the health information infrastructure.

  • First, we must account for advances in computer technology. It is likely that computers will become smaller, have greater processing power and storage, and will communicate wirelessly at high communication bandwidth.
  • Second, we should follow the best practices that have been used in other industries to foster collaboration and create value for consumers. The industries that have created economic growth through collaboration technologies are the retail supply chain, air travel, and financial services.
  • Third, we must adopt technologies that will increase collaboration and enable the marketing of our network, including enterprise architecture and Web Ontology Language (OWL).
  • Fourth, consumers and physicians will become more computer literate, and the NHIN should factor growing computer literacy into its business model. We propose that these four principles be applied when planning for maintenance and enhancement of the NHIN.

Private investment in the network must be carefully calculated and iterated. While there may be a need for tax on a service or transaction, there is great potential for health care tax slowing automation and price deflation.  One example of taxation slowing economic growth is in the telecom industry. Voice over IP technology has depreciated the cost of a phone line by logarithmic portions. However, per phone line level taxation is preventing further price erosion because the taxes now represent 50-70% of the cost of a phone line. In addition, passing and changing tax laws is a notoriously difficult process. Voters inherently do not trust taxes. Whatever financing method is chosen for the network it must facilitate automation and price erosion.

An ontology is a vocabulary with structured relationships that can be understood by man or machines. For an ontology to be adopted it must be marketed and iterated and it must have terms whose meaning is inherent those that use it. Healthcare ontologies are used today. One example of this is the ICD-9, illness classification ontology system. This system represents classifications of illness such as the flu, the common cold, and a sprained ankle.  The primary application of this ontology is as the inventory item attribute on an insurance claim.

A patient goes to a doctor because they have a runny nose. The doctor diagnoses the illness as a common cold. The doctor completes a claim form and uses the ICD-9 code 'common cold' and submits to the insurer.   One of the features of ontologies is that they enable multiple hierarchies and different views of the same vocabulary.  In that context we could view ICD-9 as the doctor-insurer view of disease classifications. It could be possible that a new view of disease classifications could be created that faces consumers and has hierarchies and views that are meaningful to a consumer.  For example, Arthritis, a herniated disk, and a fractured vertebrae are examples of illnesses.

A consumer searching for a doctor may not know if they have any of these illnesses and may search on the term 'Back pain'. A view and hierarchy based on consumer vocabulary could be incorporated into the ontology and used to create an electronic marketplace. When a consumer searches on 'Back pain', all of the ICD-9 codes in that hierarchy, the physicians who are qualified to treat, and their pricing, could populate a consumer's search for healthcare providers. At the same time much of the pricing in health care is already done using ICD-9.

With some nudging from regulators to make this reality, consumers and employers could shop for health care online using EBay or Travelocity style electronic commerce based on the ICD-9 illness classification ontology and a consumer view incorporated into the ontology. This new marketplace will create new business models and destroy poor ones. This is a great opportunity for a healthcare network to pay for itself while leveraging already existing data integrity.           

  1. How could a NHIN be established so that it will be utilized in the delivery of care by healthcare providers, regardless of their size and location, and also achieve enough national coverage to ensure that lower income rural and urban areas could be sufficiently served?

C-K, S-B, N-B:

To the extent that the competitive market place that we envision does not provide needed capabilities to all communities, we would expect various governmental functions to step in and invest in the required infrastructures.  These investments are likely to be reduced due to the higher level of competition in the market, overall.

We have not elected to draft specific responses to the remaining questions, as most of the issues have already been covered fully in our previous answers.  In short, our position is that ontological misalignments throughout the health care value chain raise costs, either adding expense or creating breakdowns the prohibit needed actions.  We believe that an ontology-focused approach to the NHIN would improve overall effectiveness, control costs, and reduce risks of failure.

Glossary of Key Acronyms

FEA                 Federal Enterprise Architecture

FHA                 Federal Health Architecture

HL-7 RIM        HL-7 Reference Information Model

OASIS             Organization for the Advancement of Structured Information Standards

SUMO             Suggested Upper Merged Ontology

UBL                 Universal Business Language

TRL                 Technology Readiness Levels

XML                Extensible Markup Language

HL7 EHR Interoperability Work Group in 2007 Mentions SICoP

See: http://semanticommunity.info/Health_Level_7

Dr. Oliver Bohdenrider's NIH UMLS Group starts to help ONC

See: http://semanticommunity.info/Da...

New PCAST Report Says “Systems Engineering” Can Improve Health Care

Source: http://www.whitehouse.gov/blog/2014/...ve-health-care

Today, the President’s Council of Advisors on Science and Technology (PCAST) released a report to the President, Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering. The report comes at a critical time for the United States and for the health-care system in particular, with millions of Americans recently gaining health-care coverage due to the Affordable Care Act (ACA).

At the same time, the health-care system is challenged by rising costs, which now approach a fifth of the United States’ gross domestic product (GDP). A significant portion of those costs, however, does not produce better health or quality of care. In consultation with a working group including experts from the health and engineering sectors, PCAST, in its new report, identifies a comprehensive set of recommendations to address these cost and quality challenges, including through an interdisciplinary approach known as systems engineering.

Systems engineering has been widely used in other industries, such as manufacturing and aviation, to improve efficiency, reliability, productivity, quality, and safety of systems. It has begun to be used to good effect in health care, but, PCAST finds, the United States would benefit from more widespread adoption.

Among the barriers that limit the spread of systems engineering in health care is the predominant payment system— the fee-for-service method often discourages efficient care. To overcome this challenge, PCAST notes that providers should be paid for value—e.g., patient health-outcomes—rather than the volume of tests or treatments administered.

Systems engineering also depends on the availability of high-quality data that can be used for measuring progress, analyzing current challenges and opportunities, and enabling patients and providers to make more informed decisions.

The Nation has made great strides in encouraging clinicians and health care organizations to adopt electronic health records, although more work is needed to ensure those systems are interoperable and can exchange information. This is particularly challenging for the large percentage of physicians that are a part of small or loosely networked practices, which may have limited resources and capabilities to apply systems methods and tools.

PCAST also finds that the benefits of systems engineering can be realized at the community level and that—since people live the majority of their lives and experience their health outside of traditional health-care settings—engaging public and private community entities in improving the delivery of care and/or promoting health can enhance the quality of care and the health of communities.

Finally, the report speaks to the need for the United States to build a health-care workforce that has the necessary “know-how,” recommending that systems engineering concepts should be embedded in education and training for a wide variety of people involved in health care, from clinicians to administrators to public-health officials. 

PCAST believes that implementation of these strategies bears great potential to transform the Nation’s health-care system in positive ways, and hopes this new report will provide a framework to help the Administration achieve these aims as it proceeds with implementation of the Affordable Care Act.

  • Read the fact sheet here.
  • Read the full report here.

Christine Cassel, Ed Penhoet, and Maxine Savitz are members of PCAST and co-chairs of the PCAST Systems Engineering in Health Care Working Group.

Fact Sheet: PCAST Report on Systems Engineering in Health Care

Source: http://www.whitehouse.gov/sites/defa...-_may_2014.pdf (PDF)

The White House Office of Science & Technology Policy

For Immediate Release

May 29, 2014

Fact Sheet: PCAST Report on Systems Engineering in Health Care

In its new report to the President, Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering, the President’s Council of Advisors on Science and Technology (PCAST) identifies a comprehensive set of actions for enhancing health care across the Nation through broader use of systems-engineering principles. Informed by the deliberations of a working group consisting of PCAST members and prominent health-care and systems-engineering experts, the report proposes a strategy that involves: (1) reforming payment systems, (2) building the Nation’s health-data infrastructure, (3) providing technical assistance to providers, (4) increasing community collaboration, (5) sharing best practices, and (6) training health professionals in systems engineering approaches.

Systems engineering, widely used in manufacturing and aviation, is an interdisciplinary approach to analyze, design, manage, and measure a complex system in order to improve its efficiency, reliability, productivity, quality, and safety. It has often produced dramatically positive results in the small number of health-care organizations that have incorporated it into their processes. But in spite of such excellent examples, systems methods and tools are not yet used on a widespread basis in the American health-care system. In its new study, PCAST discusses the barriers to implementation of systems methods in health care, emphasizing among other things that a prerequisite to progress will be an acceleration of the alignment of payment systems with desired outcomes for individuals and populations—or, paying for value rather than volume.

PCAST also underscores the importance of high-quality data, measurement, and analyses to help patients and providers to make more-informed decisions, noting the key role that electronic health records and other health-information technology play in capturing data and enabling analysis. In its report, PCAST also calls for targeted education and training to foster the development of a health-care workforce that can apply systems-engineering approaches and emphasizes the value of increasing involvement of communities in health-care delivery.

The report includes seven broad recommendations, all of which support and reinforce each other as components of a strategy to improve the quality of delivery of health care and the health of Americans through systems engineering. The recommendations, which are elaborated upon in the PCAST report, include:

  • Recommendation 1: Accelerate the alignment of payment incentives and reported information with better outcomes for individuals and populations.
  • Recommendation 2: Accelerate efforts to develop the Nation’s health-data infrastructure.
  • Recommendation 3: Provide national leadership in systems engineering by increasing the supply of data available to benchmark performance, understand a community's health, and examine broader regional or national trends.
  • Recommendation 4: Increase technical assistance (for a defined period—3-5 years) to health-care professionals and communities in applying systems approaches.
  • Recommendation 5: Support efforts to engage communities in systematic healthcare improvement.
  • Recommendation 6: Establish awards, challenges, and prizes to promote the use of systems methods and tools in health care.
  • Recommendation 7: Build competencies and workforce for redesigning health care.

Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering

Source: http://www.whitehouse.gov/sites/defa...-_may_2014.pdf (PDF)

The President’s Council of Advisors on Science and Technology i PCAST Systems Engineering in Health Care Working Group

About the President’s Council of Advisors on Science and Technology

The President’s Council of Advisors on Science and Technology (PCAST) is an advisory group of the Nation’s leading scientists and engineers, appointed by the President to augment the science and technology advice available to him from inside the White House and from cabinet departments and other Federal agencies. PCAST is consulted about, and often makes policy recommendations concerning, the full range of issues where understandings from the domains of science, technology, and innovation bear potentially on the policy choices before the President.

For more information about PCAST, see http://www.whitehouse.gov/ostp/pcast

The President’s Council of Advisors on Science and Technology

Co-Chairs

John P. Holdren
Assistant to the President for
Science and Technology
Director, Office of Science and Technology Policy

Eric S. Lander
President
Broad Institute of Harvard and MIT

Vice Chairs

William Press
Raymer Professor in Computer Science and Integrative Biology
University of Texas at Austin

Maxine Savitz
Vice President
National Academy of Engineering

Members

Rosina Bierbaum
Dean, School of Natural Resources and Environment
University of Michigan

Christine Cassel
President and CEO
National Quality Forum

Christopher Chyba
Professor, Astrophysical Sciences and International Affairs
Director, Program on Science and Global Security
Princeton University

S. James Gates, Jr.
John S. Toll Professor of Physics
Director, Center for String and Particle Theory
University of Maryland, College Park

Mark Gorenberg
Managing Member
Zetta Venture Partners

Susan L. Graham
Pehong Chen Distinguished Professor Emerita in Electrical Engineering and Computer Science
University of California, Berkeley

Shirley Ann Jackson
President
Rensselaer Polytechnic Institute

Richard C. Levin (through mid-April 2014)
President Emeritus
Frederick William Beinecke Professor of Economics
Yale University

Michael McQuade
Senior Vice President for Science and Technology
United Technologies Corporation

Chad Mirkin
George B. Rathmann Professor of Chemistry
Director, International Institute for Nanotechnology
Northwestern University

Mario Molina
Distinguished Professor, Chemistry and Biochemistry
University of California, San Diego
Professor, Center for Atmospheric Sciences at the Scripps Institution of Oceanography

Craig Mundie
Senior Advisor to the CEO
Microsoft Corporation

Ed Penhoet
Director, Alta Partners
Professor Emeritus, Biochemistry and Public Health
University of California, Berkeley

Barbara Schaal
Mary-Dell Chilton Distinguished Professor of Biology
Washington University, St. Louis

Eric Schmidt
Executive Chairman
Google, Inc.

Daniel Schrag
Sturgis Hooper Professor of Geology
Professor, Environmental Science and Engineering
Director, Harvard University Center for Environment
Harvard University

Staff

Marjory S. Blumenthal
Executive Director

Ashley Predith
Assistant Executive Director

Knatokie Ford
AAAS Science & Technology Policy Fellow

PCAST Systems Engineering in Health Care Working Group

Co-Chairs

Christine Cassel*
President and CEO
National Quality Forum

Maxine Savitz*
Vice President
National Academy of Engineering

Ed Penhoet*
Director, Alta Partners
Professor Emeritus, Biochemistry and Public Health
University of California, Berkeley

Working Group

James P Bagian
Director
Center for Healthcare Engineering and Patient Safety
University of Michigan

Melinda Buntin
Professor and Chair
Department of Health Policy
Vanderbilt University School of Medicine

Molly Joel Coye
Chief Innovation Officer
University of California at Los Angeles Health System

Gary S. Kaplan
Chairman and CEO
Virginia Mason Health System

Charles M. Kilo
Chief Medical Officer
Oregon Health and Science University

Christopher F. Koller
President
Milbank Memorial Fund

Richard C. Levin*
President Emeritus
Frederick William Beinecke Professor of Economics
Yale University

Joe McCannon
Consultant

William Press*
Raymer Professor in Computer Science and Integrative Biology
University of Texas at Austin

William B. Rouse
Alexander Crombie Humphreys Chair
School of Systems and Enterprises
Director of the Center for Complex Systems and Enterprises
Stevens Institute of Technology

Elizabeth Teisberg
Professor of Family and Community Medicine
Dartmouth College

Deryk Van Brunt
President and Chairman
Healthy Communities Institute
Associate Clinical Professor
University of California at Berkeley
School of Public Health

Jed Weissberg
(Retired) Senior Vice President of Hospitals, Quality and Care Delivery Excellence
Kaiser Permanente

Heather M. Young
Associate Vice Chancellor for Nursing
Dean and Professor
University of California at Davis Betty Irene Moore School of Nursing

Staff

Marjory S. Blumenthal
Executive Director
President’s Council of Advisors on Science and Technology

Knatokie Ford
AAAS Science & Technology Policy Fellow President’s Council of Advisors on Science and Technology

Claudia Williams
Senior Health and IT Advisor
White House Office of Science and Technology Policy

Science Writer

Robert Saunders
Senior Director of Strategic Partnerships
National Quality Forum

Transmittal Letter

President Barack Obama
The White House
Washington, DC 20502

Dear Mr. President,

We are pleased to send you this report by your Council of Advisors on Science and Technology, Better Health Care and Lower Costs: Accelerating Improvement through Systems Engineering. This report comes at a critical time for the United States. Health-care costs now approach a fifth of the U.S. economy, yet a significant portion of those costs is reportedly “unnecessary” and does not lead to better health or quality of care. Millions more Americans now have health insurance and therefore access to the health care system as a result of the Affordable Care Act (ACA). With expanded access placing greater demands on the health-care system, strategic measures must be taken not only to increase efficiency, but also to improve the quality and affordability of care.

This report, which was informed by the deliberations of a working group comprised of PCAST members and prominent health-care and systems-engineering experts, identifies a comprehensive set of actions for enhancing health care across the Nation through greater use of systems-engineering principles. Systems engineering, widely used in manufacturing and aviation, is an interdisciplinary approach to analyze, design, manage, and measure a complex system in order to improve its efficiency, reliability, productivity, quality, and safety  It has often produced dramatically positive results in the small number of health-care organizations that have incorporated it into their processes. But in spite of excellent examples, systems methods and tools are not yet used on a widespread basis in U.S. health care.

PCAST’s recommendations themselves form a system for addressing a set of complementary concerns. The predominant fee-for-service payment system is the primary barrier to greater use of systems methods and tools in health care, as it serves as a major disincentive to more efficient care. First and prerequisite for other kinds of progress, the Nation must accelerate the transition to payment models that pay for value rather than volume. Recognizing that it is hard to improve what cannot be measured, PCAST also calls for accelerated development of the U.S. health-data infrastructure. The value of health data comes from their use; health information technology will play a critical role in system-improvement efforts and enhancing the understanding of the multiple factors that contribute to health outcomes. PCAST also recommends providing technical assistance to health-care providers in applying systems methods, particularly those with limited resources such as the small or loosely networked practices that comprise nearly 60 percent of physicians. Since most individuals live their lives and experience their health outside of the traditional health-care setting, PCAST proposes increasing engagement with communities in improving health-care delivery. Finally, systems-engineering knowhow must be propagated at all levels; PCAST recommends that the United States build a health-care workforce that is equipped with essential-systems engineering competencies that will enable system redesign.

Implementation of these strategies bears potential not only to improve the efficiency of care delivery, but also to improve its quality. PCAST hopes that this report will provide a framework that helps the Administration achieve these aims as it proceeds with ACA implementation. We are grateful for the opportunity to serve you and the Nation in this way.

Sincerely,
John P. Holdren
Co-chair, PCAST

Eric S. Lander
Co-chair, PCAST​

Executive Summary

In recent years there has been success in expanding access to the health-care system, with millions gaining coverage in the past year due to the Affordable Care Act. With greater access, emphasis now turns to guaranteeing that care is both affordable and high-quality. Rising health-care costs are an important determinant of the Nation’s fiscal future, and they also affect the budgets for States, businesses, and families across the country. Health-care costs now approach a fifth of the economy, and careful reviews suggest that a significant portion of those costs does not lead to better health or better care.

Other industries have used a range of systems-engineering approaches to reduce waste and increase reliability, and health care could benefit from adopting some of these approaches. As in those other industries, systems engineering has often produced dramatically positive results in the small number of health-care organizations that have implemented such concepts. These efforts have transformed health care at a small scale, such as improving the efficiency of a hospital pharmacy, and at much larger scales, such as coordinating operations across an entire hospital system or across a community. Systems tools and methods, moreover, can be used to ensure that care is reliably safe, to eliminate inefficient processes that do not improve care quality or people’s health, and to ensure that health care is centered on patients and their families. Notwithstanding the instances in which these methods and techniques have been applied successfully, they remain underutilized throughout the broader system.

The primary barrier to greater use of systems methods and tools is the predominant fee-for-service payment system, which is a major disincentive to more efficient care. That system rewards procedures, not personalized care. To support needed change, the Nation needs to move more quickly to payment models that pay for value rather than volume. These new payment models depend on metrics to identify high-value care, which means that strong quality measures are needed, especially about health outcomes. With payment incentives aligned and quality information available, health care can take advantage of an array of approaches using systems engineering to redesign processes of care around the patient and bring community resources, as well as medical resources, together in support of that goal.

Additional barriers limit the spread and dissemination of systems methods and tools, such as insufficient data infrastructure and limited technical capabilities. These barriers are especially acute for practices with only one or a few physicians (small practices) or for community-wide efforts. To address these barriers, PCAST proposes the following overarching approaches where the Administration could make a difference:

1. Accelerate alignment of payment systems with desired outcomes,

2. Increase access to relevant health data and analytics,

3. Provide technical assistance in systems-engineering approaches,

4. Involve communities in improving health-care delivery,

5. Share lessons learned from successful improvement efforts, and

6. Train health professionals in new skills and approaches.

Through implementation of these strategies, systems tools and methods can play a major role in improving the value of the health-care system and improving the health of all Americans.

Summary of Recommendations

Recommendation 1: Accelerate the alignment of payment incentives and reported information with better outcomes for individuals and populations.

1.1 Health and Human Services (HHS) should convene public and private payers (including Medicare, Medicaid, State programs, and commercial insurers) and employers to discuss how to accelerate the transition to outcomes-based payment, promote transparency, and provide tools and supports for practice transformation. This work could build on current alignment and measurement-improvement efforts at the Center for Medicare and Medicaid Services (CMS) and HHS broadly.

1.2 CMS should collaborate with the Agency for Healthcare Research and Quality (AHRQ) to develop the best measures (including outcomes) for patients and populations that can be readily assessed using current and future digital data sources. Such measures would create more meaningful information for providers and patients.

Recommendation 2: Accelerate efforts to develop the Nation’s health-data infrastructure.

2.1 HHS should continue, and accelerate, the creation of a robust health-data infrastructure through widespread adoption of interoperable electronic health records and accessible health information. Specific actions in this vein were proposed in the 2010 PCAST report on health information technology and the related 2014 JASON report to the Office of the National Coordinator for Health Information Technology (ONC).

Recommendation 3: Provide national leadership in systems engineering by increasing the supply of data available to benchmark performance, understand a community's health, and examine broader regional or national trends.

3.1 HHS should create a senior leadership position, at the Assistant Secretary level, focused on health-care transformation to advance information science and data analytics. The duties for this position should include:

  • Inventory existing data sources, identify opportunities for alignment and integration, and increase awareness of their potential;
  • Expand access to existing data through open data initiatives;
  • Promote collaboration with other Federal partners and private organizations; and
  • Create a more focused and deep data-science capability through advancing data analytics and implementation of systems engineering.

3.2 HHS should work with the private sector to accelerate public- and private-payer release of provider-level data about quality, safety, and cost to increase transparency and enable patients to make more informed decisions.

Recommendation 4: Increase technical assistance (for a defined period—3-5 years) to health-care professionals and communities in applying systems approaches.

4.1 HHS should launch a large-scale initiative to provide hands-on support to small practices to develop the capabilities, skills, and tools to provide better, more coordinated care to their patients. This initiative should build on existing initiatives, such as the ONC Regional Extension Centers and the Department of Commerce’s Manufacturing Extension Partnership.

Recommendation 5: Support efforts to engage communities in systematic health-care improvement.

5.1 HHS should continue to support State and local efforts to transform health care systems to provide better care quality and overall value.

5.2 Future CMS Innovation Center programs should, as appropriate, incorporate systems-engineering principles at the community level; set, assess, and achieve population-level goals; and encourage grantees to engage stakeholders outside of the traditional health-care system.

5.3 HHS should leverage existing community needs assessment and planning processes, such as the community health-needs assessments for non-profit hospitals, Accountable Care Organization (ACO) standards, health-department accreditation, and community health-center needs assessments, to promote systems thinking at the community level.

Recommendation 6: Establish awards, challenges, and prizes to promote the use of systems methods and tools in health care.

6.1 HHS and the Department of Commerce should build on the Baldrige awards to recognize health-care providers successfully applying system engineering approaches.

Recommendation 7: Build competencies and workforce for redesigning health care.

7.1 HHS should use a wide range of funding, program, and partnership levers to educate clinicians about systems-engineering competencies for scalable health-care improvement.

7.2 HHS should collect, inventory, and disseminate best practices in curricular and learning activities, as well as encourage knowledge sharing through regional learning communities. These functions could be accomplished through the new extension-center functions.

7.3 HHS should create grant programs for developing innovative health professional curricula that include systems engineering and implementation science, and HHS should disseminate the grant products broadly.

7.4 HHS should fund systems-engineering centers of excellence to build a robust specialty in Health-Improvement Science for physicians, nurses, health professionals, and administrators.

Introduction and Motivation for Improvement

In recent years, there has been success in expanding access to the health-care system, with millions gaining coverage in the past year due to the Affordable Care Act. 1 More than 8 million Americans signed up for health insurance between October 2013 and April 2014, and millions more gained coverage through Medicaid or their parents’ health plan. With greater access, emphasis now turns to guaranteeing that care remains high-quality and is affordable. Rising health-care costs are affecting the Nation’s fiscal future, and they also affect the budgets for States, businesses, and families across the country. Health-care costs now approach one-fifth of the economy, and careful reviews suggest that a significant portion of those costs does not lead to better health or better quality care. 2

In addition to ensuring that care remains affordable, there is a need to center health care on patients, families, and population health. That objective requires action on multiple fronts, as stated well by the Institute of Medicine 3: care should be safe, timely, effective, efficient, feasible and patient centered. There are opportunities to improve in each of these areas. For example, recent reviews suggest that over one-quarter of Medicare patients experienced some type of harm during a hospital stay, and other research finds that between one-fifth to one-third of all hospitalized patients experienced a medical error. Almost half of these errors were likely preventable.4 Other studies suggest that patients are not routinely involved in decisions about their treatments or managing their conditions. And anecdotal evidence and studies highlight the impact inefficiencies have on patients—long waits for appointments, information not transmitted between clinicians, and patients with complex diseases feeling lost trying to get the care they need.

These shortfalls are occurring even as most clinicians work tirelessly for their patients. Their work is frustrated by processes that contain unnecessary burdens and inefficiencies, with some studies suggesting that almost one-third of front-line health-care workers’ time is wasted. 5 The current stresses on clinicians mean that improvement initiatives cannot simply add to a clinician’s workload or rely on the clinicians finding time to participate in additional initiatives. Rather, successful and sustainable improvement must involve reconfiguring the workflow and overall environment in which these professionals practice, which can help to reduce the burden of work while improving the performance of the system.

Making such changes in an integrated manner is the essence of systems engineering. Recent policies, deriving from the Affordable Care Act and the American Recovery and Reinvestment Act, 6 have laid the groundwork for wider use of systems engineering through new care models that promote integrated care and rapid adoption of electronic health records. The National Quality Strategy identifies areas for improvement in health-care quality and outcomes that systems-engineering initiatives need to address. 7 The current policy environment and advances in technical capabilities combine to make this the right time to focus on expanding systems methods and tools throughout health care.

Successful Use of Systems Engineering in Other Industries

Other industries have used a range of approaches, known collectively as systems engineering, to improve productivity, efficiency, reliability, and quality. For example, by using tools such as alerts, redundancies, checklists, and systems that adjust for the human factor, 8 U.S. commercial airlines have reduced fatalities from hundreds in the 1960s to approaching zero now, with the risk of dying from flying now at 1 in 45 million flights. They have also been used in fields as diverse as manufacturing, space stations and satellites, and education.

Systems tools and methods draw on many fields of expertise, including multiple types of engineering, scientific fields, social sciences, and management, as well as the circumstances of different industries. Given the diversity of fields involved, multiple terms are used to describe this concept. For the purposes of this report, we use the term systems engineering to include the full suite of tools and methods that can analyze a system, its elements, and connections between elements; assist with the design of policies and processes; and help manage operations to provide better quality and outcomes at lower cost (see Box 1 and the appendices for further information on systems engineering, including definitions of key terms). 9

Box 1: Overview of Systems Engineering

What is it? An interdisciplinary approach to analyze, design, manage, and measure a complex system with efforts to improve its efficiency, productivity, quality, safety, and other factors. For the purposes of this report, the term systems engineering includes the full suite of tools and methods that can analyze a system, its elements, and connections between elements; assist with the design of policies and processes; and help manage operations to provide better quality and outcomes at lower cost.

How can it be applied? Systems-engineering processes can be applied in multiple ways depending on the specific challenges and the type of system, with the model below highlighting the types of steps taken. Systems engineering is most successful when data are harnessed at each stage in the cycle.

PCASTMay2014Box1.png

What types of systems methods and tools are used now? Multiple strategies are available, although their usefulness depends on the specific type of health care. Some examples include:

  • industrial engineering
  • production-system methods, Lean, and broader process-improvement techniques
  • operations management, queuing theory, and patient-flow variability
  • high-reliability approaches
  • human-factors engineering
  • complexity science
  • statistical process control
  • modeling and simulation
  • supply-chain management
  • systematic management techniques (e.g., total-quality management)
  • safety tools (e.g., root-cause analysis, checklists, health-care failure modes and effect analyses)

Promise of Systems Engineering for Health and Health Care

Health care could benefit from the range of available systems-engineering approaches. In the small number of health-care organizations that have implemented these concepts, systems engineering has often produced dramatically positive results. Systems engineering can help reengineer critical-care environments to improve both the patient experience and the effectiveness of care, such as coordinating the different devices monitoring the patient’s health, reducing false alarms that prevent the patient from resting, and connecting monitors to therapeutic equipment so that action can be taken immediately when a problem is identified. 10 There are successful examples at different scales, ranging from improving the efficiency of a single hospital pharmacy to coordinating operations across an entire hospital system or across a community. Table 1 illustrates the diversity of tools and methods that could be used for different settings or segments of the health-care system, along with the challenges that these approaches could help address, and Box 2 provides an example on taking a systems approach to improve care across a community.

Denver Health, a health system that serves the most vulnerable, safety-net populations in Colorado, is an excellent example of how an organization used the Toyota Production System to redesign its entire operations. It started by mapping out its operations and found significant waste, with one industrial engineer finding that its trauma-surgery resident physicians walked 8 ½ miles during a 24-hour shift. It sought to reduce this waste using Lean techniques, rapidly testing new ideas to improve a high-priority problem. The Lean techniques have helped the organization achieve specific successes—such as reducing two serious conditions (deep-vein thrombosis and pulmonary embolism) by 80 percent and by halving the time needed to prepare a hospital room for the next patient. On a broader scale, Denver Health has saved almost $200 million since it began its work in 2006 and reduced its mortality rate to some of the lowest among its peers in academic health centers. 11 It has achieved these successes while seeing a 60 percent increase in uncompensated care, illustrating the wide range of organizations that could take advantage of these approaches. 12

Table 1. Potential impact of systems engineering on different segments of the health system, showing selected challenges alongside potential systems methods and tools approaches​

Health system stakeholder Selected challenges Example systems methods and tools to address selected challenges
Patients - Uncoordinated care - Inefficient use of their time and effort - Care not centered on their needs, goals, and circumstances Operations management to ensure resources are available when needed - Checklists or dashboards to ensure reliable care delivery - Reengineering processes to incorporate patient input
Small clinical practices - Clinician stress and burnout
- Inefficient workflows for delivering care
- Inconsistent usability of different health-information tools
- Uneven delivery of evidence-based prevention and treatment
- Lean techniques for eliminating waste in workflows and clinical processes
- Human-factors engineering techniques to ensure health-information tools are easily usable
Large health-care organizations - Managing new payment models that reward outcomes vs. process - Errors and gaps in care - Wasted resources from inefficient workflows - Wasted resources from unnecessary administrative processes - Standardized protocols that incorporate new evidence and can be tailored to individual patients - Predictive analytics to identify potential risks before problems occur - Supply-chain management to minimize waste in supplies and pharmaceuticals
Communities - Little coordination among community organizations, local governments, and health-care organizations
- Partnering to address the many factors that affect people’s health
- Modeling how policies can build on community resources
- Operations research to identify at-risk community members and efficiently deliver preventive health services
- Big-data methods for identifying patients who need more intensive coordination of their health care

Another strong example is Kaiser Permanente, one of the Nation’s largest managed-care organizations. Kaiser uses multiple approaches, including systems engineering, to continually update the way it delivers care and to ensure that new scientific evidence is consistently applied. These tools for performance improvement include a web-based data dashboard that tracks performance across medical centers and geographic areas, corps of improvement advisors, enhanced clinical-information systems, staff training in performance improvement, and systems for sharing technical knowledge.13 While these tools have been applied to multiple aspects of care, one illustrative example was their application to improving care for sepsis, a potentially fatal condition brought on by severe infection. This condition is serious as it is often only detected when it is too late to help the patient. After identifying sepsis as an opportunity for improvement, two hospitals began rapid-cycle pilot testing of approaches to detect and treat this difficult condition quickly. The broader organization spread the technical and cultural interventions that were needed to implement this work successfully in other hospitals. As a result of this new approach, Kaiser was able to identify three times as many sepsis cases, treat those patients quickly, and cut mortality from this condition by half. 14

While there are excellent examples, systems methods and tools are still not used on a widespread basis through health care.

Unfortunately, these examples are rare in U.S. health care. Many organizations and communities that could benefit from these tools and methods are not applying them to their operations.

Box 2: Taking a systems approach to improve care across a community 15

Seeking to improve the health of Americans across a large region of Tennessee and Kentucky, Vanderbilt University Medical Center and its affiliates confronted the question of how to scale up a program they knew worked for people with chronic disease. 16 Their challenge was how to help patients across a broad community improve their control of chronic conditions—such as high blood pressure, heart disease, and diabetes—and help coordinate the care for patients discharged from the hospital for serious conditions—such as heart attacks or pneumonia. By improving people’s health, the program could help people stay healthy at home, which would also reduce the overall cost of care, instead of having to return to the hospital or go to the emergency room.

The initiative was built around a model for health-care delivery, called MyHealthTeam, where teams of primary care clinicians, specialists, and care coordinators work together to care for patients using health information technology. The project uses real-time dashboards to track how patients are doing and to ensure care is delivered reliably. The model identifies those in greatest need of health care, so that clinicians can focus their attention on those that need it most. Once identified, those patients at highest risk of health problems are connected with a clinician who rapidly applies evidence-based interventions to find what works for the patient.

This program is based on earlier initiatives that improved hypertension care by educating clinicians about best practices, providing regular feedback to clinicians, providing education tools for patients, and building on technologies that have been successfully used to coordinate clinical care. All of this relies on a significant data infrastructure that includes information about hospital discharges, labs, administrative data, data recorded by the patient, surveys, and Federal and State data. By integrating different data together, the program is able to identify patterns, understand outcomes, and support clinical decisions. MyHealthTeam also applies systems engineering through regular improvement cycles, streamlining inefficient workflows, employing health-care professionals strategically, and using technology.

The project has experienced several challenges in scaling the model to larger populations and additional clinical groups. These include different organizational cultures, trust, concerns about change, dealing with payment-model changes, staff bandwidth and time, and exchanging information across different information systems. To overcome these challenges, the initiative has developed several strategies, such as developing effective working relationships with community partners, providing technical support to assist with data challenges, and always considering efficiencies when asking partners to take on new work. During its expansion phase, MyHealthTeam is tracking 5 outcomes: disease control, reduce hospital admissions, reduce emergency room usage, reduce total cost of care, and reduce the cost per beneficiary per month. It has already seen improvements in the control of chronic diseases, and further work will be needed to understand the other outcomes.

Factors Limiting Dissemination and Spread of Systems-Engineering Principles

Barriers to greater use of systems methods and tools include the lack of quality and performance measures and the misaligned incentive structure of the predominant fee-for-service payment system, which encourages a fragmented delivery system. To support needed change, the Nation needs to move more quickly to payment models that pay for value. 17 These approaches depend on metrics to identify high-value care, which means that strong quality measures are needed, especially about health outcomes. With payment incentives aligned and quality information available, health care can take advantage of an array of approaches using systems engineering to redesign the process of care around the patient and bring community resources, as well as medical resources, together in support of that goal.

Another challenge is an organization’s leadership and culture, which determine people’s commitment to improvement efforts. 18 For example, one systems-engineering initiative achieved some success by using checklists to reduce infections among severely ill patients, but significant improvement did not occur until there was a culture where everyone felt they were able to speak up about potential safety concerns. 19 Other barriers include technical challenges, workforce capabilities, and limited knowledge about what works.

The siloed nature of the health system, in which clinical care is separated in an uncoordinated fashion across multiple specialties and settings, presents another challenge that can limit the use of systems approaches. Clinicians often focus only on the activities in their particular silo, as opposed to considering the broader concerns of the patient. Moving away from the current siloed state requires systematic knowledge of the many processes and providers involved in a given patient’s care, as well as a cultural shift toward team-based care where all work together to address a patient’s needs.

There are additional challenges for clinicians working in small practices. Small practices provide a significant number of Americans with their care—despite trends toward consolidation, as of 2012 nearly 60 percent of physicians were still in practices with 10 or fewer physicians (see Figure 1). 20 The distribution of clinicians is changing rapidly, and there has been a significant increase in the fraction of physician practices owned by hospitals in the last several years. Data are continuing to emerge on the extent of this affiliation and consolidation trend. 21

Figure 1. Distribution of Physicians by Practice Size, 2012. 22

PCASTMay2014Figure1.png

The physicians, nurses, and other personnel in small practices often are juggling many responsibilities to keep the practice operating, have fewer resources to invest in technical infrastructure or new improvement methods, and may not have the resources to hire staff specifically dedicated to implementing systems-engineering techniques. As a result, the clinicians in these practices often have to squeeze any improvement efforts in between seeing patients, documenting their clinical evaluations, coordinating care, and handling administrative paperwork for billing and reimbursement.

Given these barriers, successful spread of systems engineering will depend on multiple strategies that account for the diversity of American health care. 23 PCAST proposes the following overarching goals where the Administration could make a difference in the adoption of these methods and tools:

1. Accelerate alignment of payment systems with desired outcomes,
2. Increase access to relevant health data and analytics,
3. Provide technical assistance in systems-engineering approaches,
4. Involve communities in improving health-care delivery
5. Share lessons learned from successful improvement efforts, and
6. Train health professionals in new skills and approaches.

These recommendations together form a systems approach, with the potential for positive interactions among them. Since progress will depend on collaborations among providers, communities, and others, all recommendations in this report should be viewed through that lens. This report discusses these areas in more detail and provides detailed recommendations to accelerate adoption of systems-engineering approaches across the Nation.

Goal 1: Accelerate Alignment of Payment Systems with Desired Outcomes

The current payment system is a major barrier to progress. The predominant way clinicians and hospitals are paid for health care discourages real improvement as it rewards higher volumes of tests and treatments over whether a patient has a better outcome. At the same time, clinicians are not paid for activities that are known to improve a patient’s health—such as coordinating a patient’s care or talking with a patient about whether a treatment meets his or her needs. Perhaps most irrationally, a hospital is paid more when patients have complications, so that preventing patient harm can actually cause revenues to decline. 24 As the current incentive system limits improvement broadly, systems engineering is not immune from its effects (see Box 3 for one example).

Box 3: Virginia Mason Medical Center back pain clinic example— How payment policies can discourage systems engineering 25

While changing the payment system for health care is important for many reasons, it has specific importance for the use of systems methods and tools. One example of this occurred for Virginia Mason Medical Center in Seattle, Washington, which uses the Toyota Production System to optimize its operations. As a result of its use of that system, the organization has some of the lowest rates of serious hospital complications, such as infections and falls; has reduced its medical-malpractice liability by almost 40 percent; and has been recognized as one of the top hospitals in the country in both quality and efficiency. When Virginia Mason redesigned its back-pain clinic, it reduced patient waiting times, reduced the use of unnecessary tests, lowered costs, and got people back to work and their desired function. In spite of these positive impacts, revenues decreased because Virginia Mason reduced the use of expensive services, such as MRIs, and increased the use of lower-cost services such as physical therapy. It was initially able to keep the program operational by negotiating with local employers to change how they paid for back care, while working on other operational improvements to continue this service lines profitability. This specific experience highlights the unintended consequences that can occur under the current payment system, as well as the importance of engaging more elements from the community in which health care is delivered.

 

To address the perverse incentives now in place, the Affordable Care Act (ACA) included multiple programs that move toward payment that rewards better health outcomes at lower cost. For example, 360 accountable care organizations (ACOs) are now providing care to more than 5 million Medicare beneficiaries,26 and hundreds more ACOs are operating for commercially insured patients. Yet this transition is not complete, as providers may be operating under multiple payment programs at the same time—some focused on health outcomes and value, while others continue to pay solely on quantity of services. As a result, a provider can be rewarded by some programs for improving their patients’ health, while losing money from other programs because those patients are using fewer health-care services. 27 In order to overcome this problem, the Administration should work with the private sector to accelerate the transition of the payment system so that clinicians receive consistent incentives across all public and private health-insurance plans to deliver high-quality and high-value health care. 28

New payment models will require performance measures that assess health outcomes, not just the process of care, which is the primary focus of current metrics. Transitioning performance metrics from processes to patient outcomes will allow benchmarking between systems and providers. Better measurement science can lay the foundation for more effective measures for public and private accountability programs, while eliminating metrics with weak impact on quality or risk of unintended consequences. It will be critical to develop outcomes-based measures and align these “measures that matter” across payers, as the current proliferation of measures frustrates providers and requires significant resources to collect, store, and report. 29

In addition to payment, measurement can help drive improvement by increasing the amount of information available for clinicians, health-care organizations, and patients. Improving the measures available will ensure that initiatives using systems methods and tools will focus their effort on what matters. In some cases, the data may not be available, while in others the challenge is turning existing data into meaningful information.

Recommendation 1: Accelerate the alignment of payment incentives and reported information with better outcomes for individuals and broader populations.

1.1: Health and Human Services (HHS) should convene public and private payers (including Medicare, Medicaid, State programs, and commercial insurers) and employers to discuss how to accelerate the transition to outcomes-based payments, promote transparency, and provide tools and supports for practice transformation. This work could build on current alignment and measurement improvement efforts at the Center for Medicare and Medicaid Services (CMS) and HHS broadly.
1.2: CMS should collaborate with the Agency for Healthcare Research and Quality (AHRQ) to develop the best measures (including outcomes) for patients and populations that can be readily assessed using current and future digital data sources. Such measures would create more meaningful information for providers and for patients.

Goal 2: Increase Access to Relevant Health Data and Analytics

Systems engineering requires multiple types of data to be successful, ranging from clinical health information to information on operational processes to broader benchmarking indicators. As data sets approach the size that can be deemed “big data,” new capabilities emerge that can assist system-improvement efforts. From understanding what treatments work to conveying the multiple factors (system, provider, and environmental) that contribute to health outcomes, big data bears the potential to support predictive medicine--clinicians may anticipate who will develop disease or predict what treatments will be successful for a given patient. While some of the needed data are currently collected and available, greater work is needed to expand the data sets required to reach these capabilities.

Expanding clinical and operational data for improvement initiatives

The amount of electronic clinical data available to clinicians and health-care organizations has been increasing due to the HITECH Act 30 and associated incentives from Medicare and Medicaid for providers to adopt and use electronic health records (EHRs). EHRs are a vital tool to support data-driven systems engineering approaches in health care, yet many organizations still lack a comprehensive EHR system, and others are still learning how to use these digital tools to improve care. These problems are especially acute in smaller practices that may lack the infrastructure that larger organizations possess. Providers need hands-on support to develop the expertise and business processes to improve care using health information technology (IT).

Greater amounts of data are not helpful if they are not of good quality and easily exchangeable among all of the clinicians involved in a patient’s care. Good quality data are accurate, complete, timely, relevant, and consistent; adherence to standards for data quality would ensure the reliability of both data and analytics. Interoperability among EHR systems remains a challenge, and future progress will depend on interoperability among a wide range of digital and mobile data sources. The Office of the National Coordinator for Health Information Technology (ONC) has focused on expanding interoperability, and CMS and ONC have included interoperability as a key requirement for the “meaningful-use” incentive program. Further efforts in these programs will address this challenge.

Another source of data for improving care is patient-generated health data. 31 Incorporating data generated directly by the patient, which is largely unharnessed by the health system today, presents the opportunity not only to improve clinical care and patient engagement, but also gives researchers a more comprehensive view of the patient experience. Given the expected surge of such data in coming years, the Federal Government may be able to help make the data more accessible to patients and clinicians by developing standards and providing incentives for utilizing and integrating this information. 32 Some action is already under way—ONC’s Federal advisory committees are exploring ways to add patient-generated data into Meaningful Use Stage 3 guidelines, 33 while the National Institutes of Health (NIH) supports the Patient Reported Outcomes Measurement Information System to provide reliable and precise measures of patient-reported health status.

Beyond clinical information, many systems-engineering approaches require data on operational processes, from the flow of patients through different units of a hospital to the time it takes clinicians to complete specific tasks. When collected, these data are often in different systems than clinical information, and they may not be collected in a format that can be easily applied to system redesign. Smaller practices may be especially challenged to routinely collect this type of data and have data systems that can store them.
There are several policy options to continue and accelerate the development of a robust health IT infrastructure, such as those described in the 2010 PCAST Health IT report and the 2014 JASON report for ONC (see Box 4 and the appendices for further information). 34 These analyses continue to be relevant as future Federal health IT policies are developed.

Box 4: Key conclusions from 2010 PCAST report and 2014 JASON report on health IT

1. HHS’s vigorous efforts have laid a foundation for progress in the adoption of health IT, with historic increases in the use of electronic health records by clinicians in the last several years.

2. Data interoperability across EHR systems remains a substantial barrier to the development of a robust health IT infrastructure to support new care models and to health information exchange among providers and with patients to support patient care.

3. Both reports called on HHS to advance standards and services to make it easier to pull data from EHRs and exchange it, as well as to build these requirements into meaningful use guidelines. Each report had the same goal, but recommended slightly different technical solutions for achieving the vision:

a. The 2010 PCAST report called for the development of a “universal exchange language” that enables health IT data to be shared across institutions and the creation of the infrastructure that permits physicians and patients to combine patient data across institutional boundaries.

b. By contrast, the 2014 JASON report recommended that EHR vendors be required to develop and publish APIs for medical-records data and demonstrate that data from their EHRs can be exchanged via these APIs and used in a meaningful way by third-party software developers.

EHR interoperability is not merely a feat of technology. Once accomplished, it can help to make more data available for the kinds of analyses that enable systems engineering. It can also help practices (of any size) that have adopted EHRs serve their patients better because it will be easier for them to draw on and use data from the multiple sources where patients have received care.

 

Recommendation 2: Accelerate efforts to develop the Nation’s health data infrastructure.

2.1: Health and Human Services should continue, and accelerate, the creation of a robust health-data infrastructure through widespread adoption of interoperable electronic health records and advances in data exchange. Specific actions in this vein were proposed in the 2010 PCAST report on health information technology and the related 2014 JASON report to the Office of the National Coordinator for Health Information Technology.

Expanding data available for assessing progress

While local clinical and operational data sources are critical, additional data are needed to benchmark performance, understand a community's health, and examine broader regional or national trends. These data are critical for successful systems reengineering, as they can help an organization or community identify opportunities for improvement and assess their progress in real time. Data already collected by HHS could be leveraged to serve many of these purposes, as illustrated in Table 2, and could help foster partnerships that translate these resources into meaningful information for improvement.

Table 2. Example data resources throughout the Department of Health and Human Services
Selected HHS agencies and offices Selected data resources
Administration for Children & Families National Residential Information Systems Project, National Survey of Area Agencies on Aging, National Survey of Older Americans Act Participants
Agency for Healthcare Research and Quality National Healthcare Quality Report, National Healthcare Disparities Report, State Snapshots, Healthcare Cost and Utilization Project; Medical Expenditure Panel Survey [collaboration with CDC and Census Bureau], National Quality Measures Clearinghouse
Agency for Toxic Substances & Disease Registry National Amyotrophic Lateral Sclerosis (ALS) Registry, National Toxic Substance Incidents Program, Rapid Response Registry survey instrument, Toxicological profiles for hazardous substances
Centers for Disease Control and Prevention National Center for Health Statistics, National Vital Statistics System, National Health Interview Survey, National Health and Nutrition Examination Survey, National Health Care Surveys, Behavioral Risk Factor Surveillance System, National Program of Cancer Registries, Health Indicators Warehouse, WONDER online databases
Centers for Medicare & Medicaid Services Hospital Compare, Physician Compare, Office of Information Products and Data Analytics, Hospital Charge Data, Nursing Home Compare, Physician Charge Data, National Health Expenditure Data, Medicaid Statistical Information System, Medicare Current Beneficiary Survey, Chronic Conditions Data Warehouse, Medicare claims data, Medicaid Statistical Information System data
Food and Drug Administration Adverse Event Reporting System, Premarket Approvals, Recalls Database
Health Resources and Services Administration Uniform Data System for health centers, Health Resources Comparison Tool, Health Professional Shortage Areas, National Center for Health Workforce Analysis data
Office of the National Coordinator for Health IT Health IT Dashboard, National Survey on Health Information Exchange in Clinical Laboratories, Regional Extension Center program activity
National Institutes of Health Health Information National Trends Survey; Patient Reported Outcomes Measurement Information System [PROMIS]; Surveillance, Epidemiology, and End Results Program [SEER]
Substance Abuse & Mental Health Services Administration National Registry of Evidence-based Programs and Practices, National Survey on Drug Use and Health, Drug Abuse Warning Network, Behavioral Health Services Information System, Treatment Episode Data Set

HHS has already started sharing these data more broadly though its open-data initiative, which is part of its broader open-government plan. Many of these data are now posted on HealthData.gov, which has catalogued over 1,000 HHS data sets along with data sets from multiple states.35 In addition, the Centers for Medicare and Medicaid Services (CMS) established the Office of Information Products and Data Analytics to maximize the use of CMS data by internal and external users (see Box 5).

Box 5: CMS is Making Medicare Claims Data Available to Enrollees, Researchers, Accountable Care Organizations, Quality Reporting Organizations, and the Public 36
  • Researchers can now access Medicare claims data through CMS’ Virtual Research Data Center (VRDC), a secure and efficient means for researchers to virtually access and analyze CMS’s vast store of health care data, at a much lower cost than traditional data-access mechanisms
  • CMS is providing Accountable Care Organizations (ACOs) with monthly claims feeds covering the almost 3 million beneficiaries being cared for by physicians participating in the ACOs
  • To help States coordinate care, CMS is now providing over 30 States with timely Medicare data for dual-eligible beneficiaries. Medicare data are an essential tool for States as they try to improve quality and control costs for these beneficiaries.
  • The ACA authorized CMS to share Medicare data with approved qualified entities (QEs) for the purposes of provider quality reporting. QEs combine Medicare claims data from CMS with claims data from other payers to create comprehensive reports on the performance of hospitals, physicians, and other health-care providers.
  • Beginning three years ago, Medicare enrollees have access to their own claims information. 37
  • CMS is publicly releasing Medicare data at the provider level to promote transparency and spur innovation.
    • o In May 2013, CMS released detailed information on average hospital charges for the 100 most common Medicare in-patient admissions, followed in June by data on selected out-patient procedures. These data have been downloaded more than 260,000 times, sparking a national debate on observed variation in hospital charges.
    • o In April 2014 CMS released detailed information on services and procedures provided to Medicare beneficiaries by physicians and other health-care professionals. These data included more than 9 million lines of information, collectively covering more than 880,000 unique providers, and provided unprecedented insights into how care is delivered in the Medicare program. Within the first week of posting, more than 150,000 users downloaded these data, which can be used to help consumers and other stakeholders compare the services provided and payments received by individual health-care providers.

 

One example of the transformative impact of open data in another industry is the Energy Information Administration (EIA), which serves as an objective and independent source of energy information on a wide range of issues—imports and exports, supply and demand, and production and inventories—for different energy sources; analyzes the source data to produce actionable information; and disseminates that information broadly. The legislation that created the EIA ensured that its products are released directly without a clearance process from other Department of Energy (DOE) offices, the Secretary, or the Office of Management and Budget (OMB), which has been important for its independence and objectivity. As a result, its products serve as a definitive source of energy information for the Federal government, private sector, and the public; help to inform policy; help businesses understand the energy landscape; and help the public see broader trends and challenges. 38

There are also additional health data sources beyond HHS that could be leveraged—including other Federal sources, such as the Federal Employee Health Benefit Program, Veterans Health Administration (VHA), and the Department of Defense (DoD). Public-private partnerships that produce publicly available reports, such as the Patient-Centered Outcomes Research Institute (PCORI), also serve as useful data sources. PCORI conducts comparative effectiveness and patient-centered outcomes research. Disseminating comparative-effectiveness research and related scientific information to providers at the point of care enables improvement of clinical processes and provides an evidence base for improvement initiatives centered on better health at lower cost.

Given the multiple resources currently available—from the National Center for Health Statistics to National Healthcare Quality Reports to Medicare claims data—HHS does not need to create a centralized data office. Progress would be accelerated, however, by inventorying data from multiple sources (including Federal health and social-support programs, Federal surveys, and public-health and surveillance programs), and building HHS’ capacity to analyze, use and release data across many sources. These rich data can help to reveal the multiple determinants of health, understand how a community’s context may lead to specific health challenges, and evaluate different interventions and strategies to improve health. Technical work would be needed to make these data actionable, and additional data-security and privacy protections would be required before these are broadly distributed.

Recommendation 3: Provide national leadership in systems engineering by increasing the supply of data available to benchmark performance, understand a community's health, and examine broader regional or national trends.

3.1: Health and Human Services should create a senior leadership position, at the Assistant Secretary level, focused on health-care transformation. The duties for this position should include:

  • Inventory existing data sources, identify opportunities for alignment and integration, and increase awareness of their potential;
  • Expand access to existing data through open-data initiatives;
  • Promote collaboration with other Federal partners and private organizations; and
  • Create a more focused and deep data-science capability through advancing data analytics and implementation of systems engineering.

3.2: HHS should work with the private sector to accelerate public and private payer release of provider-level data about quality, safety, and cost to increase transparency and enable patients to make more informed decisions.
(See Appendix G for illustrative examples of ways to build HHS data-science leadership).

Goal 3: Provide Technical Assistance in Systems-Engineering Approaches

Health-care professionals and administrators will need technical support to apply systems-engineering approaches throughout their operations. This is especially true for clinicians working in smaller practices, who tend to have fewer technical capabilities available. Similarly, there are challenges when communities seek to apply systems methods and tools to improving the health of their community, as they, too, may have limited tools at their disposal.

One of the earliest efforts to provide "boots-on-the-ground" support was through the agricultural Cooperative Extension System. 39 As described in recent publications, 40 the Extension System played a critical role in teaching farmers about new farming practices, developing new evidence on what worked, and helping people adapt the research to their particular situation. This concept has been successfully applied to other sectors of the economy, such as through the Hollings Manufacturing Extension Partnership (MEP) at the National Institute of Standards and Technology (NIST) within the Department of Commerce. The MEP consists of regional centers that provide technical, scientific, and managerial assistance to smaller American manufacturing companies to identify and adopt new technologies. Surveys of participating companies have found positive impacts, reporting that companies have had $2.5 billion in new sales, saved $900 million in their costs, and created or retained over 60,000 jobs. 41

Efforts to expand technical assistance in systems engineering can build on several existing efforts. The Veterans Health Administration (VHA) established Veterans Engineering Research Centers in 2009 to develop innovative care delivery models, incorporate engineering principles into health care, create education and training programs to share knowledge between engineering and health-care fields and provide guidance on engineering principles more broadly. Another health-care technical assistance effort is through the Quality Improvement Organizations (QIOs) and Quality Innovation Networks (QINs) supported by the Centers for Medicare and Medicaid Services (CMS), which work directly with Medicare providers to improve the effectiveness, efficiency, and quality of Medicare services. Similarly, the CMS Innovation Center has funded a three-year project, led by the Northeastern University Healthcare Systems Engineering Institute, to test the impact and viability of a network of health-care systems-engineering regional extension centers. And the Agency for Healthcare Research and Quality (AHRQ) recently announced support for a network of centers to assist small and medium-sized primary-care practices in implementing patient-centered outcomes research findings and building the capacity in such practices for incorporating this evidence moving forward. 42

Another example of the extension-service model is offered by the Regional Extension Centers (RECs) overseen by the Office of the National Coordinator for Health Information Technology (ONC), which seek to help providers with the adoption of electronic health records (EHRs) and health IT. These centers are particularly focused on providing technical support to clinicians in small, rural, and underserved areas and helping them become meaningful users of health IT. Several studies have suggested the RECs have been successful in supporting providers to achieve this goal. A Government Accountability Office study found that providers working with RECs were almost twice as likely to use EHR systems meaningfully compared to others. 43 Another recent study found that the RECs recruited over 130,000 primary-care providers, leading to 90 percent of these clinicians using an advanced EHR and almost half using health IT meaningfully. 44

There is also an opportunity to foster partnerships among organizations that operate with a strong, corporate process structure–Six Sigma, Lean, total quality management (TQM), and others–with their local health care systems providing care to the very people who make up those organizations. This type of public-private partnership should be encouraged as it allows “localization and adaptation” of conventional systems engineering in health-care settings. It also creates an environment where the skills of high-performing companies, which have incorporated systems engineering into their processes, can be applied to teach, reengineer, and/or otherwise support a local hospital directly. It should in no way, however, be a substitute for what the market can and should develop, i.e., for-profit organizations that provide training and skills to health-care systems.

Recommendation 4: Increase technical assistance (for a defined period of 3-5 years) to health-care professionals and communities in applying systems approaches.

4.1: Health and Human Services should launch a large-scale initiative to provide hands-on support to small practices to develop the capabilities, skills, and tools to provide better, more coordinated care to their patients. This initiative should build on existing initiatives, such as the Office of the National Coordinator for Health Information Technology Regional Extension Centers and the Department of Commerce’s Manufacturing Extension Partnership.​

Goal 4: Involve Communities in Improving Health-care Delivery

Currently, systems-engineering principles have mostly been applied within health-care organizations, as those organizations have technical capabilities and structures for implementing these methods and tools. Yet, not all clinicians practice in larger organizations, and people spend most of their lives outside of the traditional health-care system. A systems approach that optimizes the contributions of community resources and promotes coordination across various providers and agencies in a community will increase the likelihood of providing better health at lower cost.

Positive results occur when partnering with communities

For example, health-care delivery can improve when reengineering brings together health care and community partners, often using the patient-centered medical home concept as a key element. The work of Jeffrey Brenner in Camden, New Jersey provides a positive example of how clinicians can partner with non-clinical teams to serve the needs of severely ill patients, thereby better managing their condition while saving money. 45 Technical assistance is needed to accomplish this type of reengineering at the community level, such as teaching communities how to review community data, identify opportunities based on maps of health status patterns, and consider potentially relevant evidence-based programs to address those issues. (See Box 6 for an example of community involvement in care).

System-based design can be helpful when rebuilding a community’s health infrastructure after a crisis. Following Hurricane Katrina, the health-care infrastructure was devastated throughout New Orleans, especially the health-care safety net. This natural disaster revealed underlying vulnerabilities, as the New Orleans safety net was geographically and financially consolidated in the Medical Center of Louisiana at New Orleans (Charity Hospital). Charity Hospital was the central hub serving a patient population with complex health needs due to chronic disease, high rates of uninsured individuals, and high poverty rates. The damage from Hurricane Katrina meant that this safety net no longer functioned, and the city had to completely rebuild it. Rather than rebuild a single, centralized, and vulnerable hospital, the city invested in a network of primary-care clinics across the city that provide team-based care and integrate mental health with primary care, addressing the multiple factors affecting a person’s health. This networked approach increases the resilience of the safety net, thereby improving its ability to withstand future disasters, and improves the preparedness of the community overall. Many of the important activities performed by the clinic network were supported by Federal grants and philanthropy, since current payment models do not reward these actions financially. The future of this initiative depends on an improved payment system, or the results will be unsustainable (see Goal 1).46

Box 6: Improving care transitions with the community—CARE Network 47

Many patients return to the hospital shortly after being discharged—almost one-fifth of Medicare patients and one-tenth of privately insured adults return to the hospital within a month, although this rate has declined recently.48 There are multiple reasons why it is a challenge to keep patients healthy when they leave the hospital, from helping patients understand their treatment, to ensuring medication and supplies are available, to arranging transportation to appointments, to accommodating patients’ overall living conditions. Some of these challenges can be met directly by the health-care system, while others require partnerships with the community.

Queen of the Valley Medical Center, in Napa County, California, developed an initiative to help patients stay healthy as they transitioned from the hospital to their home. The effort focused specifically on reducing readmissions to hospitals and emergency-room use for low-income adults and vulnerable older adults with complex health needs, using the CARE Network (Case Management, Advocacy, Resource/Referral, Education) for addressing these challenges. There are specific challenges for implementing this work in Napa County given the diversity of its population, number of languages spoken, and varying socioeconomic status (with one-quarter of the population living below 200 percent of the Federal poverty line).

The CARE network uses a team-based approach to ensure that a patient’s needs are being met, coordinating between medical services and other resources. For example, a team consisting of a social worker and nurse will visit the patient at home to ensure a patient knows how to manage his or her treatment and to discuss the supports needed to make that happen—housing, food, transportation to medical appointments, behavioral health needs, and necessary medications. In some cases, this may involve help in navigating the health-care system; in other cases this may involve coordinating with social services and community organizations. The team continues to visit the home until the patient has the knowledge and support services to manage his or her own care and health.

Early results are promising. During the 2012 fiscal year, the program was associated with a 50 percent reduction in hospitalizations and a 60 percent decrease in using the emergency room, while the patients were 20 percent less likely to be readmitted to the hospital compared to similar patients.

 

Box 7: Assisting communities using systems approaches—ReThink Health 49
One example of using systems approaches at the community level is ReThink Health, which worked with local health leaders in Pueblo, Colorado to model all parts of the health-care system and all factors influencing health in a community. (Pueblo is a small county where 40 percent of residents are poor or unemployed, 1 in 6 is uninsured, and there are poor health outcomes for those with heart disease, diabetes, and other illnesses.) The community leaders used this model to consider the effectiveness of different policy strategies, identify potential bottlenecks or unsustainable funding, and understand the timeline for results. After using the model, community leaders put together a suite of policies to address the many underlying factors affecting problems facing their community, such as obesity and unintended pregnancy. This work is at an early stage, and the evaluation is ongoing. Knowledge has been gained in the process of community-wide decision making, such as the importance of involving groups beyond the traditional health-care system and the need for multiple policies to address the many factors affecting health.

Opportunities exist for expanding community engagement in health-care delivery

New delivery-system models and payment programs offer an opportunity to engage communities and states around systems-engineering approaches for improving health-care delivery. The State Innovation Model grants from CMS have provided a strong platform for improvement and reengineering health-care operations, and the Community-based Care Transitions Program brings together community stakeholders to reduce hospital readmissions for high-risk Medicare patients. 50 These are only examples of the multiple programs currently underway, with more being tested by the CMS Innovation Center that could be leveraged.

Another opportunity is to build upon the infrastructure created by the Beacon Community Program, which sought to demonstrate the potential for population-based health improvement by leveraging health IT and redesigning care delivery processes. 51 For example, the Southeast Minnesota Beacon Community wanted to develop new capabilities for exchanging data across its community. As part of its planning process, it convened a diverse group of stakeholders within the community (public-health departments, school districts, long-term care facilities, a statewide quality-performance-measures consumer organization, 52 and health-care organizations) and was able to adopt a comprehensive strategy. This strategy included expansion of EHR use among providers in public health departments, development of standard ways to capture and exchange continuity-of-care information, and establishment of a network for transferring health information between health-care providers. As a result, these new data capabilities provide tools for multiple organizations across the community to help keep people healthy. 53 The Southeast Minnesota Beacon Community, as well as its peers across the country, demonstrated that expanding health-IT infrastructure requires a strong governance system that incorporates stakeholder perspectives across the community to promote buy-in and coordinate across organizations. 54

Community health needs assessments can generate incentives for partnerships with the community. These assessments help organizations understand the health needs of a community, such as a hospital’s service area, a county, or region. Examples of current programs in this area include:

- The Affordable Care Act (ACA) requires tax-exempt hospitals to conduct a community health-needs assessment every three years and to update every year their implementation strategy to address targeted needs.
- The Centers for Disease Control and Prevention (CDC), in conjunction with the Robert Wood Johnson Foundation, supports the voluntary accreditation of local and State health departments through the Public Health Accreditation Board (PHAB). As part of gaining accreditation, the Board requires that departments conduct community health assessments.
- Community health centers are required to understand and address the health status and medical needs of vulnerable populations in their service areas as a condition for taking part in Federal programs or incentives for community health centers.

These assessments could be leveraged to increase the use of systems methods and tools. For example, requirements and guidelines could be revised so that the community is considered from a systems perspective, systems-engineering initiatives are conducted with partners in their communities, and progress is measured across the entire community in a systematic method. These requirements could be combined with technical assistance and resources to help with capacity-building in systems-engineering processes (see section on technical assistance). Combined with other recommendations, this expansion of needs-assessment activities could catalyze a powerful grassroots set of systems-engineering activities nationally, including hospitals, provider organizations, health departments, local foundations and non-profits, employers, schools, and many other stakeholders at local and regional levels.

Recommendation 5: Support efforts to engage the community in systematic health-care improvement.

5.1: Health and Human Services (HHS) should continue to support State and local efforts to transform health-care systems to provide better care quality and overall value.
5.2: Future Center for Medicare and Medicaid Services (CMS) Innovation Center programs should, as appropriate, incorporate systems-engineering principles at the community level; set, assess, and achieve population-level goals; and encourage grantees to engage stakeholders outside of the traditional health-care system.
5.3: HHS should leverage existing community needs assessment and planning processes, such as the community health-needs assessments for non-profit hospitals, ACO standards, health-department accreditation, and community health-center needs assessments, to promote systems thinking at the community level.

Goal 5: Share Lessons Learned from Successful Improvement Efforts

Some organizations are successfully using systems engineering to improve their operations, but the knowledge they have gained is not widely shared. These organizations have developed new improvement tools, identified the resources and circumstances needed for implementation, and uncovered the barriers that may limit success. Communicating the lessons learned can accelerate the efforts of those just beginning their system improvement efforts.

More research is needed to develop evidence about what works. Several Federal agencies have supported research on systems-engineering approaches—for example, the Agency for Health Research and Quality (AHRQ) has supported research on industrial and systems engineering in health care, and the National Science Foundation (NSF) and AHRQ have supported research on systems modeling to improve health systems. Beyond Federal programs, the Patient-Centered Outcomes Research Institute (PCORI) has announced initiatives aimed at improving health-care systems through engineering principles, and private foundations are also investing in these efforts. Further research could help uncover new knowledge, while expanded communication efforts could ensure the results are applied broadly.

There is another opportunity to learn what works through Federal programs that directly provide clinical care, such as the Veterans Health Administration (VHA) and Defense Health Agency (DHA). The VHA was an early leader in applications of systems engineering, and DHA has similarly leveraged systems methods and tools for serious conditions, such as traumatic brain injury. Greater dissemination of the knowledge gained from these practical experiences could assist more organizations in systems methods and tools.

One important dissemination channel is through convening and learning collaboratives. The Hospital Engagement Networks for the Partnership for Patients provides this type of learning collaborative for sharing best practices,55 while the Center for Medicare and Medicaid Services (CMS) Innovation Centers offer a learning and diffusion group using a wide range of techniques to enable learning on a broad scale. Another example of collaborative approaches is the multi-state collaborative supported by the Milbank Memorial Fund. The goal of the collaborative is to support practices as they transition to Patient-Centered Medical Homes (PCMHs), a model of primary care that seeks to be patient-centered, comprehensive, coordinated, and accessible. The project brings together State-convened multi-payer PCMH efforts to share best practices and promote collaborative learning, encourage alignment in the PCMH programs offered by different payers, and support common evaluation and quality improvement.

Another useful way to share lessons learned is by using awards and prizes. Awards can provide an incentive by improving an organization’s reputation, by a financial incentive attached to the award, or both. Beyond the incentive to participate, prizes and awards also provide an inventory of what works. There are already examples in health care where prizes promote action in important areas, such as the Monroe E. Trout Premier Cares Award to recognize organizations that support people excluded by or underserved by the traditional health-care system or the American Hospital Association NOVA Awards that acknowledge programs improving the health of the community.56 There are opportunities to use awards and prizes to expand systems engineering in health care, building on existing ones—like the Shingo Prize 57 and Baldrige award (see Box 8)—that raise awareness of performance excellence.

Box 8: Recognizing successful use of systems engineering— Baldrige Performance Excellence Program 58

The National Institute of Standards and Technology (NIST) Baldrige Performance Excellence Program is a U.S. public-private partnership program designed to recognize and promote performance excellence. The program was established to identify and recognize high-performing companies, develop criteria for evaluating improvement efforts, and share best practices broadly. The Baldrige program raises awareness about the importance of performance improvement and provides tools and criteria to help organizations undertake that work. The program was expanded to include health-care and education organizations in 1999 and to nonprofit/government organizations in 2005.

There are seven categories of criteria to help organizations identify their strengths and opportunities for improvement: leadership; strategic planning; customer focus; measurement, analysis, and knowledge management; workforce focus; operations focus; and results. The criteria focus on results—not procedures, tools, or organizational structure—in order to encourage creative, adaptive, and flexible approaches. Most importantly, the criteria support a systems perspective both to align goals across an organization and to encourage cycles of improvement with better feedback between improvement initiatives and its results.

Over the past decade, an increasing proportion of these awards has been to health-care organizations. Last year, all of the winners were from the health-care and education sectors, which shows the appetite for improving the ways health care is organized and delivered.

 

Recommendation 6: Establish awards, challenges, and prizes to promote the use of systems methods and tools in health care.

6.1: Health and Human Services and the Department of Commerce should build on the Baldrige awards to recognize health-care providers successfully applying system engineering approaches.

Goal 6: Train Health Professionals in New Skills and Approaches

Given changes in the way health care is delivered and an improved understanding of the many factors affecting a patient’s health, health professionals of the future will need new skills to succeed. They will need effective communication and collaboration skills to work in teams, a commitment to lifelong learning to manage the flow of new evidence, and an appreciation and understanding of routine improvement methods. Expertise in systems engineering is especially critical as such tools can rarely be applied in a cookbook fashion, but rather need to be tailored to local circumstances to have the greatest chance of success.

Because systems science and systems engineering are central to improving health outcomes and health care’s performance, system sciences and systems engineering need to be much more firmly and formally embedded in the training of all health-care professionals. It is crucial that both the knowledge of systems science and the skills of implementing the principles in health care are emphasized. 59 To this end, education must involve opportunities for interprofessional problem-solving and for building capacity for collaboration that facilitates practice change.

At present, clinical education and training falls short of this vision. Most clinicians were not trained in using systems-engineering approaches, and many clinicians may not even recognize that systems methods and tools could be helpful for improving care. Yet there are reasons for optimism. Several universities are leading the way by incorporating systems engineering directly into the curriculum for health professionals of all kinds (see Box 9 for an example of integrating systems engineering in nursing education). In addition to training clinicians about systems engineering tools, there is an opportunity to teach engineers about applying their tools in a health care environment. Some institutions have started internship opportunities for undergraduate and graduate students to work in hospitals and health systems, and others have begun joint classes where engineers and clinicians learn together about applying engineering concepts to care. 60 More broadly, organizations such as the Accreditation Council on Graduate Medical Education (ACGME) have already taken steps under their New Accreditation System and the Clinical Learning Environment Review to spotlight the need for trainees to develop competence in systems-based patient safety and quality improvement related tools. The Association of American Medical Colleges (AAMC) is addressing the need to develop skills related to systems engineering in medical schools; the American Association of Colleges of Nursing (AACN) includes organizational and systems leadership as an essential element of nursing education, particularly at the graduate levels; the American Medical Association (AMA) has launched an Accelerating Change in Medical Education Initiative to expand training in systems based practice and practice based improvement; and multiple clinical certifying boards have included practice-improvement modules in their maintenance-of-certification process. These are all positive developments and lay the groundwork for further improvement.

Box 9: Training nurses in systems engineering

Nurses practice in a variety of roles, and systems engineering informs all of those roles—from providing direct care, to overseeing quality improvement, to leading organizations. Nurses are well-positioned to lead and participate in systems improvement because of the coordinating role they play among the patient, family, and care team, which helps to ensure continuity. From a process-design perspective, nurses contribute to continuity and communication among the team, coordinate care across settings, provide patient and family education and coaching, and collect and evaluate quality data to improve outcomes.

Nursing schools have evolved to teach these important skills. For example, the Gordon and Betty Moore Foundation established the Betty Irene Moore School of Nursing at UC Davis in 2009, with the explicit mission to improve health systems and advance health through nursing leadership. 61 Here, nurses study for graduate degrees (MS and PhD) in Nursing Science and Health Care Leadership, in a core curriculum that emphasizes systems engineering, implementation science, leadership, organizational change theory, quality improvement, interprofessional collaboration, and stakeholder engagement. Master’s degree students complete 1 year of fieldwork in health-care organizations designing and implementing systems improvement projects, applying didactic learning to real-world complex problems. Through this experience, they build skills in problem analysis, stakeholder engagement in defining the problem and designing the solution, and business and sustainability issues to ensure best practices endure. The PhD students frame research questions using principles of systems engineering and implementation science and tackle complex problems in health care and health. Early graduates of this program are assuming leadership positions, and several have successfully designed and now occupy new roles in health-care systems emphasizing quality improvement.

 

There are several policy options that build on existing Federal roles in education and training for physicians, nurses, pharmacists, physical therapists, behavioral health practitioners, health professionals, and health-care administrators. Current Federal education programs are diverse, ranging from loan repayment programs for practicing in medically underserved areas, supporting graduate medical education, and sponsoring continuing education events. The existing education programs could be leveraged to ensure more clinicians and others working in the health-care system have the needed skills and competencies in systems approaches.

Recommendation 7: Build competencies and workforce for redesigning health care.

7.1: Health and Human Services should use a wide range of funding, program, and partnership levers to educate clinicians about systems-engineering competencies for scalable health-care improvement.
7.2: HHS should collect, inventory, and disseminate best practices in curricular and learning activities, as well as encourage knowledge sharing through regional learning communities. These functions could be accomplished through the new extension-center functions.
7.3: HHS should create grant programs for developing innovative health-professional curricula that include systems engineering and implementation science, and HHS should disseminate the grant products broadly.
7.4: HHS should fund systems-engineering centers of excellence to build a robust specialty in Health Improvement Science for physicians, nurses, health professionals, and administrators.

Summary and Conclusions

Given recent successes in expanding access to the health-care system, it is now time to ensure that all patients have access to safe, high quality, affordable care. One important tool for addressing these challenges is through systems engineering, which has improved quality, reliability, and overall value in other industries. These methods and tools have similar potential for health care, as evidenced by a small number of health-care organizations that have applied these principles to their own operations. There are several challenges that are limiting the spread of this concept—including technical and infrastructure, policy, cultural, and organizational barrier. Given the diverse challenges, this report identifies a comprehensive set of recommendations to encourage the use of systems engineering by:

1. Accelerating alignment of payment systems with desired outcomes,

2. Increasing access to relevant health data and analytics,

3. Providing technical assistance in systems-engineering approaches,

4. Involving communities in improving health-care delivery, and

5. Sharing lessons learned from successful improvement efforts,

6. Training health professionals in new skills and approaches.

By implementing these recommendations, which support and reinforce each other, systems approaches can become widely used tools for improving the health of all Americans while ensuring that health care remains affordable for families, businesses, and the Nation.

References

1

Patient Protection and Affordable Care Act, 42 U.S.C. § 18001 (2010).

2

See, for Best Care at Lower cost: The Path to Continuously Learning Health Care in America, Washington, DC: National Academies Press, 2012.

3

Institute of Medicine. Crossing the Quality Chasm: A New Health System for the 21st Century, Washington, DC: The National Academies Press, 2001.

4

(1) Levinson, D. R. “Adverse events in hospitals: National incidence among Medicare beneficiaries,” Washington, D.C.: U.S. Department of Health and Human Services, Office of Inspector General, 2010. (2) Levinson, D.R. “Hospital incident reporting systems do not capture most patient harm,” Washington, D.C.: U.S. Department of Health and Human Services, Office of Inspector General, 2012. (3) Classen, D. C., et al. “‘Global trigger tool’ shows that adverse events in hospitals may be ten times greater than previously measured,” Health Affairs (Millwood) 30(4):581-589, 2011. (4) Landrigan, C. P., et al. “Temporal trends in rates of patient harm resulting from medical care,” New England Journal of Medicine 363(22):2124-2134, 2010.

5

Wallace, C. J., and L. Savitz. “Estimating waste in frontline health care worker activities,”
Journal of Evaluation in Clinical Practice 14(1):178-180, 2008.

6

American Recovery and Reinvestment Act (ARRA) of 2009, Pub. L. No. 111-5, 123 Stat. 115 (2009).

7

The National Quality Strategy is described online at: http://www.ahrq.gov/workingforquality/

8

Lewis, G. H., et al. “Counterheroism, Common Knowledge, and Ergonomics: Concepts from Aviation That Could Improve Patient Safety,” Milbank Quarterly, 89:4–38, 2011.

9

See, for example: Rouse, W.B. and W.D. Compton. “Systems Engineering and Management,” Engineering the Systems of Healthcare Delivery, ed. W.B. Rouse and D.A. Cortese, Amsterdam: IOS Press, 2010.

10

(1) Kaplan, Gary, et al. Bringing a Systems Approach to Health, National Academy of Engineering and Institute of Medicine Systems Approaches to Improving Health Innovation Collaborative, Washington, DC. http://www.iom.edu/~/media/Files/Per...C-Overview.pdf. (2) Schultz, Rebecca and Elena Simoncini. “Combating Hospital Noise and False Alarms Through Clinical Engineering and Nursing Collaboration.” http://www.accenet.org/downloads/ref...ner%202012.pdf

11

According to the Clinical Outcomes Report produced by University HealthSystem Consortium, the observed mortality rate at Denver Health decreased to 1.17%. See: http://www.denverhealth.org/medical-...-denver-health

12

See for example: (1) Meyer, H. “Life in the ‘Lean’ lane: Performance improvement at Denver Health,” Health Affairs 29(11):2054-2060, 2010. (2) Gabow, P.A. and P.S. Mehler. “A broad and structured approach to improving patient safety and quality: lessons from Denver Health,” Health Affairs 30(4):612-618, 2011. (3) Gabow, P. “The promise of lean processes,” IOM Commentary, Washington, DC: Institute of Medicine, 2012.

13

(1) Schilling, L., et al. “Kaiser Permanente’s Performance Improvement System, Part 1: From Benchmarking to Executing on Strategic Priorities,” The Joint Commission Journal on Quality and Patient Safety 36(11): 484-498, 2010. (2) Schilling, L., et al. “Kaiser Permanente’s Performance Improvement System, Part 2: Developing a Value Framework,” The Joint Commission Journal on Quality and Patient Safety 36(12):552-560, 2010.

14

(1) Crawford, B., et al. “Kaiser Permanente Northern California sepsis mortality reduction initiative,” Critical Care, 16(Suppl 3):P12, 2012. (2) Whippy, A., et al. “Kaiser Permanente’s Performance Improvement System, Part 3: Multisite Improvements in Care for Patients with Sepsis,” Joint Commission Journal on Quality and Patient Safety, 37(11):483-493, 2011.

15

Drawn from personal communication with Robert Dittus, Vanderbilt.

16

(1) Roumie, Christianne L., et al. "Improving Blood Pressure Control through Provider Education, Provider Alerts, and Patient Education – A Cluster Randomized Trial," Annals of Internal Medicine 145(3): 165-175, 2006. (2) Choma, Neesha N., et al. "Quality improvement initiatives improve hypertension care among veterans." Circulation: Cardiovascular Quality and Outcomes 2(4): 392-398, 2009.

17

According to a UnitedHealth Group working paper, “No national health policy prescription is complete without the exhortation to move from a health care system that pays for volume to one that pays for value.” http://www.unitedhealthgroup.com/~/m...g-Paper-8.ashx

18

(1) Bagian, J.P. “Patient safety: What is really at issue? Frontiers of Health Services Management.” 22(1):3-16, 2005. (2) Neily, J., et al. “Association Between Implementation of a Medical Team Training Program and Surgical Mortality,” Journal of the American Medical Association, 304(15):1693-1700, 2010.

19

(1) Pronovost, P., et al. “An intervention to decrease catheter-related bloodstream infections in the ICU.” New England Journal of Medicine, 355(26):2725-2732, 2006. (3) Pronovost, P., et al. “Creating high reliability in health care organizations,” Health Services Research 41(4 Pt 2):1599-1617, 2006.

20

2012 American Medical Association (AMA) Physician Practice Benchmark Survey (PPBS).

21

American Medical Association. “AMA Releases New Study of Physician Practice Arrangements,” AMA, September 17, 2013, http://www.ama-assn.org/ama/pub/news...angements.page.

22

2012 American Medical Association (AMA) Physician Practice Benchmark Survey (PPBS).

23

See for instance, McCannon, C.J. and A. McKethan. “How it’s done: Keys to implementation of delivery system reform,” Healthcare, 1(3-4):69-71, 2013.

24

Hsu, E., et al. “Doing Well by Doing Good: Assessing the Cost Savings of an Intervention to Reduce Central Line–Associated Bloodstream Infections in a Hawaii Hospital,” American Journal of Medical Quality, 29(1):13-19, 2014.

25

(1) Pham, H. H., et al. “Redesigning care delivery in response to a high-performance network: The Virginia Mason Medical Center,” Health Affairs, 26(4):w532-w544, 2007. (2) Ginsburg, P.B., et al. "Distorted payment system undermines business case for health quality and efficiency gains," Issue Brief, Center for the Study of Health System Change (112):1-4, 2007. (3) Blackmore, C. C., et al. “At Virginia Mason, collaboration among providers, employers, and health plans to transform care cut costs and improved quality,” Health Affairs 30(9):1680-1687, 2011.

26

Centers for Medicare and Medicaid Services. “More Partnerships between Doctors and Hospitals Strengthen Coordinated Care for Medicare Beneficiaries,” CMS, 23 December 23, 2013. http://www.cms.gov/Newsroom/MediaRel...013-12-23.html.

27

Toussaint, J., et al. “How the Pioneer ACO Model Needs to Change: Lessons from its Best-Performing ACO,” Journal of the American Medical Association, 310(13): 1341-1342, 2013.

28

Rajkumar, R., et al. “CMS—Engaging Multiple Payers in Payment Report.” Journal of the American Medical Association, April 21, 2014.

29

Stanek, Michael. “Quality Measurement to Support Value-Based Purchasing: Aligning Federal and State Efforts,” National Academy for State Health Policy, Washington, DC, 2014. http://www.nashp.org/sites/default/f...Purchasing.pdf

30

Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009, Pub. L. No. 111-5, 123 Stat. 226 (Feb. 17, 2009), codified at 42 U.S.C. §§300jj et seq.; §§17901 et seq.

31

Patient-generated health data are data that are generated by the patient, such as patient satisfaction, health status measures, biometric data, and patient-reported outcomes.

32

The Federal Government does not aspire to be a repository of health data or health-care data from individuals or private providers. It could, however, through its support for standards-setting and/or other steps, foster and develop public-private partnerships to facilitate exchange and analysis of data, thereby providing meaningful information to consumers and to providers for improvement.

33

Stage 3 focuses on meaningful use of EHRs for improved outcomes; see: http://www.healthit.gov/providers-pr...meaningful-use

34

(1) President's Council of Advisors on Science and Technology. Report to the President- Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward. The White House, December 2010. <http://www.whitehouse.gov/sites/defa...-it-report.pdf
(1) JASON. “A Robust Health Data Infrastructure,” prepared for the Agency for Health Care Research and Quality, AHRQ publication number 14-0041-EF, Rockville, MD, 2014. http://healthit.gov/sites/default/fi...0hhs_white.pdf

36

Brennan, Niall. "Virtual Research Data Center Offers Secure Timely Access to Data at Lower Cost," The CMS Blog, Centers for Medicare and Medicaid Services, November 12, 2013. http://blog.cms.gov/2013/11/12/virtu...at-lower-cost/

38

This description was based on personal communication with Richard Newall and draws from: National Research Council. Principles and Practices for a Federal Statistical Agency, 5th edition, Washington, DC: National Academies Press, 2013.

39

Cooperative Extension System offices can be found in every state. See: http://www.csrees.usda.gov/Extension/

40

See for instance: Gawande, A. “Testing, Testing,” The New Yorker, December 14, 2009.

41

Schacht, Wendy. “Manufacturing Extension Partnership Program: An Overview,” Congressional Research Service. November 20, 2013. https://www.fas.org/sgp/crs/misc/97-104.pdf

43

“Electronic Health Records: Number and Characteristics of Providers Awarded Medicare Incentive Payments for 2011-2012,” U.S. Government Accountability Office, October 24, 2013. http://www.gao.gov/products/GAO-14-21R.

44

Lynch, K., et al. “The Health IT Regional Extension Center Program: Evolution and Lessons for Health Care Transformation,” Health Services Research, 49(1.2):421-437

46

(1) DeSalvo, Karen. “Community Health Clinics: Bringing Quality Care Closer to New Orleanians,” The New Orleans index at Five: Reviewing Reforms After Hurricane Katrina, Brookings Institution and Greater New Orleans Community Data Center, August 2010. (2) DeSalvo, K.B., et al. “Community-Based Health Care for ‘The City that Care Forgot,’” Journal of Urban Health, 82(4):520-523, 2005. (3) DeSalvo, K.B. and S. Kertesz. “Creating a More Resilient Safety Net for Persons with Chronic Disease: Beyond the ‘Medical Home,’”Journal of General Internal Medicine 22:1377-1379, 2007.

47

(1) Robert Wood Johnson Foundation. "Coordinating Social and Health Services Improves Care Transition Process," Promising Practices from the Field, February 15, 2013. http://www.rwjf.org/en/about-rwjf/ne...ansitions.html. (2) St. Joseph Health. "Reducing Hospitalizations, Readmissions and Inappropriate Use of Emergency Services," San Francisco.
http://sftest.chausa.org/docs/defaul...a.pdf?sfvrsn=2

48

(1) Gerhardt, Geoffrey, et al. "Evaluating Whether Changes in Utilization of Hospital Outpatient Services Contributed to Lower Medicare Readmission Rate," Medicare and Medicaid Research Review 4:1, 2014. http://www.cms.gov/mmrr/Downloads/MM...004_01_b03.pdf (2) Barrett, Marguerite, et al. “Conditions With the Largest Number of Adult Hospital Readmissions by Payer,” Issue brief No. 172, 2014. http://www.hcup-us.ahrq.gov/reports/...ions-Payer.jsp

49

Hussey, Peter, et al. “From Pilots to Practice: Speeding the Movement of Successful Pilots to Effective Practice,” Discussion Paper, Institute of Medicine, April 23, 2013. http://www.iom.edu/~/media/Files/Per...ILC-Pilots.pdf

51

(1)"Beacon Community Program,” HealthIT.gov, n.d. http://www.healthit.gov/policy-resea...munity-program (2) Rein, Alison, et al. “Beacon Policy Brief 1.0: The Beacon Community Program, Three Pillars of Pursuit,” HealthIT.gov, June 3, 2012. http://www.healthit.gov/sites/defaul...ief-061912.pdf (3) “The Beacon Community Experience: Illuminating the Path Forward,” HealthIT.gov, May 22, 2013. http://www.healthit.gov/policy-resea...g-path-forward (4) Rein, Alison, et al. “Beacon Policy Brief: Building a Foundation of Electronic Data to Measure and Drive Improvement,” HealthIT.gov, August 2013. http://www.healthit.gov/sites/defaul...al_14aug13.pdf

52

See: Minnesota Community Measurement at http://mncm.org/
 

53

McKethan, A., et al. “An Early Status Report On The Beacon Communities’ Plans For Transformation Via Health Information Technology,” Health Affairs 30(4): 782-788, 2011. Also, see references at footnote 48.

54

Ibid.

55

"Hospital Engagement Networks," Centers for Medicare and Medicaid Services. http://partnershipforpatients.cms.go...tnetworks.html

56

(1) "AHA NOVA Award," Association for Community Health Improvement. American Hospital Association, 2013. http://www.aha.org/about/awards/NOVA.shtml (2) "Premier Cares Award: Spotlighting Innovative Programs to Help the Medically Underserved," Premier, Inc. https://www.premierinc.com/wps/porta...ity/caresaward

57

"Shingo Prize Recipients," The Shingo Institute, Utah State University, 2008. http://www.shingoprize.org/shingo-recipients.html

58

U.S. Department of Commerce. "Baldridge Performance Excellence Program," The National Institute of Standards and Technology, March 25, 2010. http://www.nist.gov/baldrige/

59

Some institutions, e.g., Arizona State University and Dartmouth College, offer programs in the science of health care delivery. See: https://chs.asu.edu/shcd/academic-programs and http://tdchcds.dartmouth.edu/

62

The diagram and related information were provided by the Oregon Health & Science University (OHSU). http://www.ohsu.edu/xd/

63

Smith-Bernardin, Shannon, et al. "Safe Sobering: San Francisco’s Approach to Chronic Public Inebriation." Journal of Health Care for the Poor and Underserved (Project Muse )23, 2012: 265-70. https://www.sfdph.org/dph/files/huh/...-Bernardin.pdf

64

(1) Bielaszka-DuVernay, C. “Vermont’s Blueprint for medical homes, community health teams, and better health at lower cost,” Health Affairs (Millwood) 30(3):383-386, 2011. http://hcr.vermont.gov/sites/hcr/fil...Report2013.pdf (2) Institute of Medicine. “Best Care at Lower Cost: The path to continuously learning health care in America,” Washington, DC: National Academies Press, 2012.

65

President's Council of Advisors on Science and Technology. Report to the President- Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward. The White House, December 2010. <http://www.whitehouse.gov/sites/defa...-it-report.pdf

66

JASON. “A Robust Health Data Infrastructure,” prepared for the Agency for Health Care Research and Quality, AHRQ publication number 14-0041-EF, Rockville, MD, 2014. http://healthit.gov/sites/default/fi...0hhs_white.pdf

Appendices

Appendix A: Systems Engineering Overview

What is it?

An interdisciplinary approach to analyze, design, manage, and/or measure a complex system with efforts to improve it (through increased efficiency, productivity, quality, safety, and other factors).

How are systems formed?

In the context of systems engineering, systems are interconnected elements (processes, people, products) that, when connected, form an entity (an organization, a finished good, a completed service).

  • Systems need boundaries. System boundaries can be designed to include the entire system’s life cycle (cradle to grave) or just single components (vehicle assembly line, patient-clinician in-office interaction).
  • Systems should be stakeholder-focused. Systems should be developed by concentrating on (internal and/or external) stakeholder needs. System improvements should enhance (add value) to the impacted stakeholders.
  • Systems are data-driven. Systems have clear measurable goals defined to assist with the analysis of the problem as well as impact of implemented solution. The outcomes of these goals are measured with data collected.
How is it operationalized?

System engineering processes typically include several sequential steps, leading from problem investigation to solution evaluation. Depending on the strategy taken to analyze the system, steps to operationalize can include:

  • Problem/Needs Definition
  • Modeling the System
  • Analysis of Alternatives
  • Implementation of Selected Alternative
  • Assessment of Performance of Improved System
What strategies are used for improvement?

Different and multiple strategies can be used depending on the system characteristics (type, size, boundaries, etc.).

Appendix B: Selected Examples of Systems Engineering in Health Care

There are many examples where systems engineering has been applied to improve health care. This appendix describes some of these examples to illustrate the potential range and impact from these methods and tools.

Redesigning a hospital pharmacy with systems engineering

Impacts can be similarly significant at a smaller scale. Figure B-1 illustrates the change in workflow that occurred after a systems-engineering intervention in one clinical pharmacy. Before, different people would go to the same place to search for filled prescriptions and materials, unbeknownst to each other, which led to waste in terms of motion and overprocessing. The systems-engineering effort identified several specific challenges, for which targeted changes were made, leading to a streamlined process, less overproduction waste, and reduced unnecessary motion.

Figure B-1. Workflow in one pharmacy unit before (left) and after (right) systems-engineering methods were used. 62
Addressing alcohol abuse in San Francisco

The City and County of San Francisco saw very high rates of individuals coming to the emergency room with alcohol abuse events. To deal with this problem, the localities sought to re-engineer how the community handled alcohol abuse events, with the goal of reducing the frequency that alcohol-dependent people were treated by hospital emergency departments. To do so, they created “The Sobering Center,” which serves as a physical place where inebriated individuals can rest while they are under the influence of alcohol. These individuals are referred to the Sobering Center by emergency services, police, social workers, and emergency departments, which requires collaboration among many different organizations to reconsider their processes. In terms of results, the Sobering Center has provided services to over 8,000 people, has prevented over 29,000 unnecessary emergency department visits and ambulance transports, and thereby has saved costs. Furthermore, it provides additional supports for the people using the Center by connecting them to other social-support services. 63

Coordinating care across the community: Vermont Blueprint for Health

The Vermont Blueprint for Health was created to improve health care delivery across the State and thereby improve people’s health. This Statewide public-private initiative is organized around advanced primary care practices, which are recognized as patient centered medical homes by the National Committee for Quality Assurance (NCQA). Recognizing that most practices in the State are small, the Blueprint supports each practice with robust health information technology and multi-disciplinary community health teams. These locally-based teams bring together professionals from social work, nursing, and behavioral health help to coordinate care for all patients, identify those with the greatest health needs, and ensure that all are able to manage their health. This project is supported by all payers in Vermont—including Medicaid, Medicare, and private payers—to ensure funding remains sustainable. The Blueprint has seen favorable outcomes for patients helped by both the medical homes and community health teams. In 2012, those patients had lower health care expenditures (20 percent less for children, 10 percent less for adults younger than age 65), were more likely to receive evidence-based preventive services, and were less likely to be hospitalized. The Blueprint continues its work and is expanding further in the State. 64

Appendix C: Glossary

Agile Management

flexible approach focused on understanding stakeholder needs through incremental, iterative changes in the system; changes are evaluated after each implementation to determine next steps. Common tools include wikis and project-management software.

Business Process Management

cross-functional, iterative approach to optimize processes and knowledge transfers as changes occur in the system. Most common tools are software packages (vendors include IBM, Oracle) implemented to manage workflows, documents, and processes.

Complexity Science

study of how “Complex Adaptive Systems” perform and what influences their behavior. Because some parts of the system are “animate” – or respond on their own to inputs and the environment – human systems tend to be “complex” and “adaptive,” which has implications for how they are managed.

Human Factors

study of the cognitive and environmental influences on human performance.

Lean Enterprise System

holistic approach focused on removal of “wastes” in the entire product life cycle; emphasizes continuous improvement, organizational learning, and dynamic process flows. Common tools include kaizen “improve for better” events and value-stream mapping. Also known as Toyota Production System, just-in-time (JIT) manufacturing.

Lean Six Sigma

combination of Lean Enterprise System and Six Sigma best practices; emphasizes using problem-solving Six Sigma tools to remove wastes identified in Lean.

Microsystem

system nested within a larger system. In health care, this could include a critical care unit, emergency response network, or blood bank inside a larger health care organization. A challenge is that a microsystem may be optimally functioning for its own purposes, but the larger organization may have poorer performance because it does not consider how the individual microsystems work together.

Performance Improvement

measurable improvement (intent) of functioning systems (context) of care. It is frequently not possible to “control” the environment of or multiple inputs into these functional systems or understand the impact of all the combinations and permutations of the inputs.

Process Improvement

sciences of improving system performance including methods such as Lean and Six-Sigma.

Quality Management

see performance improvement.

Queuing Theory Flow, and the Theory of Constraints

study of how people and materials move or flow through a system.

Reliability And Maintainability

study of high reliability in system design and performance and its determinants and requirements.

Six Sigma

formalized approach to reduce variation with defined operational steps to problem-solving (using the DMAIC model – Define, Measure, Analyze, Improve, Control). Popularized by Motorola and GE. Common tools include cause and effect “fishbone” diagrams, sigma calculations, and control charts.

Statistical Process Control

science of measuring system performance over time.

System

set of interdependent parts that share a common purpose. There are 3 key aspects of this definition. First, a system shares a common purpose or goals. Second, the system is made up of several parts. Third, the parts are interdependent. There are systems, often termed systems of systems, where the component systems have conflicting goals. Health care delivery is such a system.

Systems engineering

interdisciplinary field that designs and manages complex projects (systems) over their life cycles. It consider issues such as system purpose, architecture, environment, materials reliability, logistics, work-processes, optimization methods, risk management, coordination of different teams, evaluation measurements, cost, schedule, and much more, all of which gains complexity when dealing with large, complex projects or systems.

Systems science

study of system performance with the objective of system performance improvement. In health care, this would mean achieving better results for patients. System science is an interdisciplinary field incorporating systems engineering; social sciences; complexity science; queuing theory, flow, and the theory of constraints; human factors; reliability and maintainability; process improvement; and statistical process control.

Appendix D: Abbreviations

AAMC–Association of American Medical Colleges
ACA–Patient Protection and Affordable Care Act
ACGME–Accreditation Council for Graduate Medical Education
ACO–Accountable Care Organization
AHA- American Hospital Association
AHRQ–Agency for Healthcare Research and Quality
AMA–American Medical Association
ARRA–American Recovery and Reinvestment Act
CDC–Centers for Disease Control & Prevention
CMS–Centers for Medicare & Medicaid Services
DoD–Department of Defense
DOE– Department of Energy
EHR–Electronic Health Record
EIA–Energy Information Administration
FDA–Food and Drug Administration
GAO–Government Accountability Office
HIE–Health Information Exchange
HITECH–Health Information Technology for Economic and Clinical Health Act
HHS–U.S. Department of Health and Human Services
HRSA–Health Resources and Services Administration
IOM–Institute of Medicine JASON–An independent scientific advisory group that provides consulting services to the U.S. government on matters of defense science and technology. It was established in 1960. The name of the group is not an acronym.
MEP–Hollings Manufacturing Extension Partnership
NIH–National Institutes of Health
NIST–National Institute of Standards and Technology
NSF–National Science Foundation
ONC–Office of the National Coordinator for Health Information Technology
PCORI–Patient Centered Outcomes Research Institute
PCMH–Patient Centered Medical Home
PHAB–Public Health Accreditation Board
QIO–Quality Improvement Organization
REC–Regional Extension Center
TQM– Total Quality Management
VHA–Veterans Health Administration

Appendix E: 2010 PCAST Report on Health Information Technology

This report describes several recommendations to support an operational national health IT infrastructure. Those recommendations for Federal agencies are listed below. 65

Chief Technology Officer of the United States should:

  • In coordination with the Office of Management and Budget (OMB) and the Secretary of HHS, and using technical expertise within ONC, develop within 12 months a set of metrics that measure progress toward an operational, universal, national health IT infrastructure. Research, prototype, and pilot efforts should not be included in this metric of operational progress.
  • Annually, assess the Nation’s progress in health IT by the metrics developed, and make recommendations to OMB and the Secretary of HHS on how to make more rapid progress.

The Office of the National Coordinator should:

  • Move more boldly to ensure that the Nation has electronic health systems that are able to exchange health data in a universal manner based on metadata-tagged data elements. In particular, ONC should signal now that systems will need to have this capability by 2013 in order to be deemed as making “meaningful use” of electronic health information under the HITECH Act.
  • Act to establish initial minimal standards for the metadata associated with tagged data elements, and develop a roadmap for more complete standards over time.
  • Facilitate the rapid mapping of existing semantic taxonomies into tagged data elements, while continuing to encourage the longer-term harmonization of these taxonomies by vendors and other stakeholders.
  • Support the development of reference implementations for the use of tagged data elements in products. Certification of individual products should focus on interoperability with the reference implementations.
  • Set standards for the necessary data element access services (specifically, indexing and access control) and formulate a strategic plan for bringing such services into operation in an interoperable and intercommunicating manner. Immediate priority should be given to those services needed to locate data relating to an individual patient.
  • Facilitate, with the Small Business Administration, the emergence of competitive companies that would provide small or under-resourced physician practices, community-based long-term care facilities, and hospitals with a range of cloud-based services.
  • Ensure that research funded through the SHARP (Strategic Health IT Advanced Research Projects) program on data security include the use of metadata to enable data security.

The Centers for Medicare & Medicaid Services should:

  • Redirect the focus of meaningful use measures as rapidly as possible from data collection of specified lists of health measures to higher levels of data exchange and the increased use of clinical decision supports.
  • Direct its efforts under the Patient Protection and Affordable Care Act toward the ability to receive and use data from multiple sources and formats.
  • In parallel with (i.e., without waiting for) the NRC study on IT modernization, begin to develop options for the modernization and full integration of its information systems platforms using modern technologies, and with the necessary transparency to build confidence with Congress and other stakeholders.
  • When informed by the preliminary and final NRC study reports, move rapidly to implement one or more of the options already formulated, or formulate new options as appropriate, with the goal of making substantial progress by 2013 and completing implementation by 2014. CMS must transition into a modern information technology organization, allowing integration of multiple components and consistent use of standards and processes across all the provider sectors and programs it manages.
  • Exercise its influence as the Nation’s largest healthcare payer to accelerate the implementation of health information exchange using tagged data elements. By 2013, meaningful use criteria should include data submitted through reference implementation processes, either directly to CMS or (if CMS modernization is not sufficiently advanced) through private entities authorized to serve this purpose.
  • By 2013, provide incentives for hospitals and eligible professionals to submit meaningful use clinical measures that are calculated from computable data. By 2015, encourage or require that quality measures under all of its reporting programs (the Physician Quality Reporting Initiative, hospitals, Medicare Advantage plans, nursing homes, etc.) be able to be collected in a tagged data element model.

The Department of Health and Human Services should:

  • Develop a strategic plan for rapid action that integrates and aligns information systems through the government’s public health agencies (including FDA, CDC, NIH, and AHRQ) and benefits payment systems (CMS and VA).
  • Convene a high-level task force to align data standards, and population research data, between private and public sector payers.
  • Convene a high-level task force to develop specific recommendations on national standards that enable patient access, data exchange, and de-identified data aggregation for research purposes, in a model based on tagged data elements that embed privacy rules, policies and applicable patient preferences in the metadata traveling with each data element.
  • As the necessary counterpart to technical security measures, propose an appropriate structure of administrative, civil, and criminal penalties for the misuse of a national health IT infrastructure and individual patient records, wherever such data may reside.
  • Appoint a working group of diverse expert stakeholders to develop policies and standards for the appropriate secondary uses of healthcare data. This could be tasked to the Interagency Coordinating Council for Comparative Effectiveness Research.
  • With FDA, bring about the creation of a trusted third-party notification service that would identify and implement methods for re-identification of individuals when data analysis produces important new findings.

Other or multiple agencies:

  • AHRQ should be funded to develop a test network for comparative effectiveness research. The FDA, and also other HHS public health agencies, should enable medical researchers to gain access to de-identified, aggregated, near-real-time medical data by using data element access services.
  • HHS should coordinate ONC activities with CDC, FDA, and any other entities developing adverse event and syndromic surveillance networks.
  • The Department of Defense and the Department of Veteran Affairs should engage with ONC and help to drive the development of standards for universal data exchange of which they can become early adopters.

Appendix F: 2014 JASON Report on Health Data Infrastructure

This report discusses benefits of and challenges to enhancing health-data infrastructure. Findings and recommendations are presented below. 66

Findings

1. The current lack of interoperability among data resources for EHRs is a major impediment to the unencumbered exchange of health information and the development of a robust health data infrastructure. Interoperability issues can be resolved only by establishing a comprehensive, transparent, and overarching software architecture for health information.
2. The twin goals of improved health care and lowered health care costs will be realized only if health- related data can be explored and exploited in the public interest, for both clinical practice and biomedical research. That will require implementing technical solutions that both protect patient privacy and enable data integration across patients.
3. The criteria for Stage 1 and Stage 2 Meaningful Use, while surpassing the 2013 goals set forth by HHS for EHR adoption, fall short of achieving meaningful use in any practical sense. At present, large-scale interoperability amounts to little more than replacing fax machines with the electronic delivery of page-formatted medical records. Most patients still cannot gain electronic access to their health information. Rational access to EHRs for clinical care and biomedical research does not exist outside the boundaries of individual organizations.
4. Although current efforts to define standards for EHRs and to certify HIT systems are useful, they lack a unifying software architecture to support broad interoperability. Interoperability is best achieved through the development of a comprehensive, open architecture.
5. Current approaches for structuring EHRs and achieving interoperability have largely failed to open up new opportunities for entrepreneurship and innovation that can lead to products and services that enhance health care provider workflow and strengthen the connection between the patient and the health care system, thus impeding progress toward improved health outcomes.
6. HHS has the opportunity to drive adoption and interoperability of electronic health records by defining successive stages of Meaningful Use criteria that move progressively from the current closed box systems to an open software architecture.
7. The biomedical research community will be a major consumer of data from an interoperable health data infrastructure. At present, access to health data is mostly limited to proprietary datasets of selected patients. Broad access to health data for research purposes is essential to realizing the long-term benefits of a robust health data infrastructure.
8. The data contained in EHRs will increase tremendously, both in volume and in the diversity of input sources. It will include genomic and other “omic” data, self-reported data from embedded and wireless sensors, and data gleaned from open sources. Some types of personal health data, especially when combined, will make it possible to decipher the identity of the individual, even when the data are stripped of explicit identifying information, thus raising challenges for maintaining patient privacy.
9. The US population is highly diverse, reflecting much of the diversity of the global population. Therefore, important research findings applicable to Americans are likely to come from shared access to international health data. Currently there is no coherent mechanism for accessing such data for research.
10. Electronic access to health data will make it easier to identify fraudulent activity, but at present there is little effort to do so using EHRs.

Recommendations

1. CMS should embrace Stage 3 Meaningful Use as an opportunity to break free from the status quo and embark upon the creation of a truly interoperable health data infrastructure.
2. An immediate goal, to be sought within 12 months (including time for consultation with stakeholders), should be for ONC to define an overarching software architecture for the health data infrastructure.

2.1. The architecture should provide a logical organization of functions that allow interoperability, protect patient privacy, and facilitate access for clinical care and biomedical research. JASON has provided an example of what such an architecture might look like.
2.2. The architecture should identify the small set of necessary interfaces between functions, recognizing that the purpose of a software architecture is to provide structure, while avoiding having “everything talking to everything.”
2.3. The architecture should be defined, but not necessarily implemented, within the 12 month period. During that time, ONC should create (or redirect) appropriate committees to carry out, continuing beyond the 12 month horizon, the detailed development of requirements for the functions and interfaces that comprise the architecture.

3. To achieve the goal of improving health outcomes, Stage 3 Meaningful Use requirements should be defined such that they enable the creation of an entrepreneurial space across the entire health data enterprise.

3.1. EHR software vendors should be required to develop and publish APIs for medical records data, search and indexing, semantic harmonization and vocabulary translation, and user interface applications. In addition, they should be required to demonstrate that data from their EHRs can be exchanged through the use of these APIs and used in a meaningful way by third-party software developers.
3.2. The APIs should be certified through vetting by multiple third-party developers in regularly scheduled “code-a-thons.”
3.3. Commercial system acquisition by the VA and DOD should adhere to the requirements for creating public APIs, publishing and vetting them, and demonstrating meaningful data exchange by third-party software developers.

4. The ONC should solicit input from the biomedical research community to ensure that the health data infrastructure meets the needs of researchers. This would be best accomplished by convening a meeting of representative researchers within the immediate (12 month) time frame for architecture definition.
5. The adopted software architecture must have the flexibility to accommodate new data types that will be generated by emerging technologies, the capacity to expand greatly in size, and the ability to balance the privacy implications of new data types with the societal benefits of biomedical research.
6. The ONC should exert leadership in facilitating international interoperability for health data sharing for research purposes. The genomics community is already engaged in such efforts for the sharing of sequence data, and the ONC should consider adopting a similar process.
7. Large-scale data mining techniques and predictive analytics should be employed to uncover signatures of fraud. A data enclave should be established to support the ongoing development and validation of fraud detection tools to maintain their effectiveness as fraud strategies evolve.

Appendix G: Illustrative Examples on Ways to Build HHS Data Leadership

Infrastructure and Governance

  • Appoint chief data officers for key agencies, reporting to agency executive.
  • Treat data on health system performance as a core national business asset including better data governance and strategic investments in data analysis, methods, tools, partnerships and staff.
  • Have direct hiring authority to bring on key staff (data science, technology).

Data Innovation and Engagement

  • Continue and accelerate HHS open data activities (dissemination, engagement with private sector, user-friendly tools).
  • Develop user-friendly data products and tools targeted to groups driving health system improvement (providers, consumer groups, employers, state leaders, health plans, companies)
  • Accelerate release of data on health system performance (quality, safety, cost) at the provider, regional and state level, including appropriate benchmarks.
  • Expand access to Medicare claims and other high-value data sets beyond currently defined research and quality-reporting purposes and at an affordable cost.
  • Invest in data methods, tools and standards that permit linking and analysis of identifiable data sets without exposing personal health information (PHI).
  • Hire data scientists and engineers to create internal HHS resources and infrastructure.
  • Demonstrate how HHS data are fueling new innovations, entrepreneurship and low-cost technologies to improve HHS’ efficiency, effectiveness and performance.
  • Invite data insights and discovery from across HHS and public (challenges, crowd-sourcing discovery).
  • Develop data partnerships to support developing and sharing data sets with linked government and private sector data.

Data-Driven Performance

  • Increase investments in analysis, management and dissemination of data relative to data collection in support of systems engineering.
  • Link and compile data from across HHS and from outside sources to better track health care delivery system performance.
  • Develop business intelligence tools which mine existing data to provide real-time tracking of health care delivery system performance, identify areas of improvement that should be tapped to figure out and disseminate what’s working and pinpoint areas of lagging performance that need to be explored and addressed. These data should drive HHS business decisions, budgets and dissemination activities.

Appendix H: Additional Experts Providing Input

Scott Anderson
Director of Quality
GE Healthcare

Anne-Marie J. Audet
Vice President, Delivery System Reform and Breakthrough Opportunities
The Commonwealth Fund

Richard Baron
President and CEO
American Board of Internal Medicine

John Beasley
Faculty
University of Wisconsin School of Medicine and Public Health

Maureen Bisognano
CEO
Institute for Healthcare Improvement

George Wong Bo-Linn
Chief Program Officer, Patient Care Program
Gordon and Betty Moore Foundation

Jason Boehm
Director, Program Coordination Office
Chief of Staff
U.S. Department of Commerce

Albert Bonnema
Chief Medical Information Officer
Air Force Medical Services

Franklin E. Bragg
Physician
Bangor Beacon Community Medical Center and Eastern Main Medical Center

Jennifer L. Brull
Physician and Owner
Prairie Star Family Practice

Sean Cavanaugh
Deputy Director of Programs and Policy, Center for Medicare and Medicaid Innovation
Centers for Medicare and Medicaid Services (CMS)

Patrick H. Conway
Chief Medical Officer, Centers for Medicare and Medicaid Services (CMS)
Director, Center for Clinical Standards and Quality

Theresa A. Cullen
Director, Health Informatics
U.S. Department of Veterans Affairs

Samuel Cykert
Clinical Director, North Carolina Regional Extension center and Interim Director
University of North Carolina School of Medicine Health Informatics Program

Ivor Douglas
Chief, Pulmonary Sciences & Critical Care
Medicine Director, Medical Intensive Care
Denver Health Medical Center

James Doyle
Vice President of 300mm Operations, Systems and Technology Group, Packaging, Assembly and Test
IBM

William Ike Eisenhaur
National Director of Veterans Engineering Resource Centers
Veteran’s Health Administration

Yul D. Ejnes
Private Practice Internist, Coastal Medical Inc.
Chair-Emeritus, Board of Regents, American College of Physicians

Susan Dentzer
Senior Policy Adviser
Robert Wood Johnson Foundation

Robert Fangmeyer
Acting Director
Baldrige Performance Excellence Program
National Institute of Standards and Technology

Bruce Goldberg
Director
Oregon Health Authority

Donald Goldmann
Chief Medical and Scientific Officer
Institute for Healthcare Improvement

Patrick Gordon
Associate Vice President, Community Integration
Rocky Mountain Health Plans

Oren Grad
Consultant
IDA Science and Technology Policy Institute

Judith A. Hautala
Research Staff Member
IDA Science and Technology Policy Institute

Robin Hemphill
Doctor of Emergency Medicine
Vanderbilt University Medical Center

Carlos Roberto Jaen
Professor and Chairman, Department of Family and Community Medicine
University of Texas Health Science Center at San Antonio

Brent James
Executive Director, Institute for Health Care Delivery and Research
Vice President of Medical Research and Continuing Medical Education, Intermountain Healthcare

Robert L. Jesse
Principal Deputy Under Secretary for Health Department of Veterans Affairs

Craig A. Jones
Director, Vermont Blueprint for Health
State of Vermont

Michael Kanter
Medical Director of Quality and Clinical Analysis
Southern California Kaiser Permanente Medical Group

Anita Karcz
Chief Medical officer
Institute for Health Metrics

Neva Kaye
Managing Director for Health System Performance
National Academy for Sate Health Policy (NASHP)

Sallie Ann Keller
Director and Professor of Statistics, Virginia Bioinformatics Institute
Virginia Tech University

Janhavia Kirtain
Director of Clinical Transformation
Beacon Community Cooperative Agreement Program

Paul Kleeberg
Chief Medical Informatics Officer, Stratis Health
Clinical Director for REACH, the Regional Extension Assistance Center for HIT

Shari M. Ling
Deputy Chief Medical Officer, Center for Clinical Standards and Quality
Centers for Medicare and Medicaid Services (CMS)

Mark McClellan
Director and Senior Fellow, Health Care Innovation and Value Initiative
Engelberg Center for Health Care Reform, Brookings Institution

Terry McGeeney
Director
BDC Advisors

Elizabeth McGlynn
Director
Kaiser Permanente Center for Effectiveness & Safety Research (CESR)

Bobby Milstein
Director
ReThink Health

Mark Monroe
Senior Director of Risk Management
Kaiser Permanente

Farzad Mostashari
Visiting Fellow
Engelberg Center for Health Care Reform, Brookings Institution

Richard Newall
Gendell Professor of Energy and Environment Economics and Director
Duke University Energy Initiative

Sean Nolan
Chief Architect and General Manager
Health Solutions Group, Microsoft Corporation

Samuel R. Nussbaum
Executive Vice President for Clinical Health Policy and Chief Medical Officer
WellPoint, Inc.

Margaret E. O’Kane
President
National Committee for Quality Assurance

James C. Puffer
President and Chief Executive Officer
American Board of Family Medicine

Proctor Reid
Director of Programs
National Academic of Engineering

Lewis G. Sandy
Executive Vice President for Clinical Advancement
UnitedHealth Group

Judy Schilz
Director of Care Delivery Transformation
WellPoint, Inc.

Bryan T. Scott
Director of Quality, St. Louis Site
Boeing Defense Space and Security

Martin Sepulveda
Vice President of Integrated Health Services
IBM Corporation

Phillip Singerman
Acting Director
Hollings Manufacturing Extension Partnership
National Institute of Standards and Technology

Christine A. Sinsky
Internal Medicine Physician
Medical Associates Clinic and Health Plans

Ida Sim
Professor
University of California at San Francisco School of Medicine

William W. Stead
McKesson Foundation Professor of Biomedical Informatics
Vanderbilt University

Jonathan R. Sugarman
President and CEO
Qualis Health

Margaret Van Amringe
Executive Vice President of Public Policy and Government Relations
The Joint Commission

Henry Wei
Presidential Innovation Fellow
Senior Medical Director, Clinical Innovation
Aetna

Jonathan Woodson
Assistant Secretary of Defense (Health Affairs) and Director
Tricare Management Activity

Scott Young
Associate Executive Director for Clinical Care and Innovation, The Permanente Federation, LLC
Senior Medical Director and Executive Director, Care Management Institute

Teresa Zayas Caban
Chief of Health IT Research
Agency for Healthcare Research

Press Release on PCAST Report on Health Information Technology

Source: http://www.whitehouse.gov/sites/defa...it-release.pdf (pcast-health-it-release.pdf)

President’s Council of Advisors on Science and Technology Releases Report on Health Information Technology

Calls for Adoption of Universal Exchange Language to Mobilize Data, Improve Healthcare, Enhance Privacy, and Cut Costs

Information technology has the potential to revolutionize healthcare in the United States by increasing quality of care and reducing costs, and the Federal government has made good progress laying the foundation for widespread adoption of electronic health records, according to a report released today by the President’s Council of Advisors on Science and Technology (PCAST), a group of presidentially appointed experts from academia, non-governmental organizations, and industry.

But achieving the full potential of health information technology will require the development and adoption of a robust information-sharing infrastructure to facilitate the exchange of data among institutions, the report concludes. Unlike conventional electronic health records, which are effectively digital versions of paper charts that are trapped in the offices where they are created, such a system would allow health data to follow patients wherever they are, with appropriate privacy protection and patient control, while giving patients’ various doctors a more complete picture of those patients’ medical conditions and needs.

The report, “Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward,” calls upon the Federal government to facilitate the widespread adoption of a “universal exchange language” that allows for the transfer of relevant pieces of health data while maximizing privacy. Reflecting input from industry and IT experts, privacy groups, healthcare professionals, and others, the report provides specific recommendations for cultivating an information technology (IT) ecosystem that facilitates the real-time exchange of patient information in order to modernize diagnosis and treatment, improve public health, enhance the privacy and security of personal data, and create new high-technology markets and jobs while catalyzing healthcare-related economic reforms needed to address our Nation’s long-term fiscal challenges.

“The United States spends more on healthcare as a fraction of gross domestic product than any other industrialized nation, yet we lag on critical measures such as life expectancy and infant mortality,” said Eric Lander, Co-chair of PCAST. “Information technology has the potential to vastly improve patient care and create new markets based on health care innovation—but only if we make wise decisions now. This report outlines a path to achieving these aims.”

The report finds that the technology for creating the necessary infrastructure and exchange language is already proven and available. But since the development of those systems is not likely to be a profitable venture in itself, the Federal government should facilitate their creation and then leave the private sector to develop products that build on them.

Specifically, PCAST recommends that the Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare and Medicaid Services (CMS) within the Department of Health and Human Services develop guidelines to spur adoption of an exchange language for use by health information technology systems. That would facilitate a transition from traditional electronic health records—whose usefulness is largely limited to a single physician’s office—to a more medically useful and secure system in which individual bits of healthcare data are tagged with privacy and security specifications.

Importantly, implementation of PCAST’s recommendation to designate a universal exchange language for health information would not require physicians to replace their existing electronic health records systems, virtually all of which could be made compatible through “apps” and other “middleware.”

“Health information technology can allow clinicians to have real-time access to complete patient data and help them make the best possible decisions,” said PCAST member Christine Cassel. “It can help patients become more involved in their own care, which is especially important in managing chronic conditions like diabetes, asthma, or heart disease. It can help public health officials detect developing epidemics, health risks in the environment, or unexpected side effects caused by medications. It can streamline processes and reduce overhead, as it has in other industries, and lead to innovations to advance patient-centered care.”

The report finds that the best way to manage and store data for advanced data-analytical techniques is to break them down into the smallest individual pieces that make sense to exchange or aggregate. These individual pieces are called “tagged data elements,” because each unit of data is accompanied by a mandatory “metadata tag” that describes the attributes, provenance, and required security and privacy protections of the data. Universal exchange languages for metadata description, called “extensible markup languages,” are widely and successfully used.

A key advantage of the tagged data element approach is that it allows a more sophisticated privacy model—one in which privacy rules, policies, and applicable patient preferences are innately bound to each separate tagged data element and are enforced both by technology and by law. For example, a patient with diabetes may decide that her blood sugar information should be available to any of her doctors and to emergency physicians requesting that information should she have a problem while traveling in another state—but that details about her past treatment for cancer should remain private and not be shared.

Also addressing a widespread privacy concern, such a system would not require the creation or assignment of universal patient identifiers, nor would it require the creation of any centralized Federal database of patients’ health information.

The report calls upon ONC and CMS to move rapidly to implement its recommendations by creating appropriate definitions in its “meaningful use” standards for health information technology, which under law must be achieved in stages by 2013 and 2015. It also calls upon CMS to accelerate the modernization and restructuring of its IT platforms and staff expertise.

For more about PCAST, and to view the full report, please visit: http://www.whitehouse.gov/ostp/pcast

Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward

Source: http://www.whitehouse.gov/sites/defa...-it-report.pdf  (PDF)

About the President’s Council of Advisors on Science and Technology

The President’s Council of Advisors on Science and Technology (PCAST) is an advisory group of the nation’s leading scientists and engineers, appointed by the President to augment the science and technology advice available to him from inside the White House and from cabinet departments and other Federal agencies. PCAST is consulted about and often makes policy recommendations concerning the full range of issues where understandings from the domains of science, technology, and innovation bear potentially on the policy choices before the President. PCAST is administered by the White House Office of Science and Technology Policy (OSTP).

For more information about PCAST, see http://www.whitehouse.gov/ostp/pcast

Co-Chairs

John P. Holdren
Assistant to the President
for Science and Technology
Director, Office of Science and Technology Policy

Eric Lander
President, Broad Institute of Harvard and MIT

Harold Varmus*
President, Memorial Sloan-
Kettering Cancer Center

* Dr. Varmus resigned from PCAST on July 9, 2010 and subsequently became Director of the National Cancer Institute (NCI).

Members

Rosina Bierbaum
Dean, School of Natural Resources and
Environment
University of Michigan

Christine Cassel
President and CEO, American Board of Internal
Medicine

Christopher Chyba
Professor, Astrophysical Sciences and
International Affairs
Director, Program on Science and Global Security
Princeton University

S. James Gates, Jr.
John S. Toll Professor of Physics
Director, Center for String and Particle Theory
University of Maryland

Shirley Ann Jackson
President, Rensselaer Polytechnic Institute

Richard C. Levin
President
Yale University

Chad Mirkin
Rathmann Professor, Chemistry, Materials
Science and Engineering, Chemical and
Biological Engineering and Medicine
Director, International Institute of
Nanotechnology
Northwestern University

Mario Molina
Professor, Chemistry and Biochemistry
University of California, San Diego
Professor, Center for Atmospheric Sciences
Scripps Institution of Oceanography
Director, Mario Molina Center for Energy and
Environment, Mexico City

Ernest J. Moniz
Cecil and Ida Green Professor of Physics and
Engineering Systems
Director, MIT’s Energy Initiative
Massachusetts Institute of Technology

Craig Mundie
Chief Research and Strategy Officer
Microsoft Corporation

Ed Penhoet
Director, Alta Partners
Professor Emeritus of Biochemistry
and of Public Health
University of California, Berkeley

William Press
Raymer Professor in Computer Science and Integrative Biology
University of Texas at Austin

Maxine Savitz
Vice President
National Academy of Engineering

Barbara Schaal
Chilton Professor of Biology
Washington University
Vice President, National Academy of Sciences

Eric Schmidt
Chairman and CEO
Google, Inc.

Daniel Schrag
Sturgis Hooper Professor of Geology
Professor, Environmental Science and Engineering
Director, Harvard University-wide Center for Environment
Harvard University

David E. Shaw
Chief Scientist, D.E. Shaw Research
Senior Research Fellow, Center for Computational Biology and Bioinformatics
Columbia University

Ahmed Zewail
Linus Pauling Professor of Chemistry and Physics
Director, Physical Biology Center
California Institute of Technology

Staff

Deborah Stine
Executive Director, PCAST

Mary Maxon
Deputy Executive Director, PCAST

Gera Jochum
Policy Analyst

Transmittal Letter

President Barack Obama

The White House

Washington, DC 20502

Dear Mr. President,

We are pleased to send you this report, Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward, prepared by your President’s Council of Advisors on Science and Technology (PCAST). This report examines how health information technology could improve the quality of healthcare and reduce its cost, and whether existing Federal efforts in health information technology are optimized for these goals.

To provide a solid scientific and economic basis for our recommendations, the Council assembled a Working Group of nongovernmental experts and also met with government officials, industry representatives, information technology experts, and healthcare professionals. PCAST has concluded that information technology can help catalyze a number of important benefits including improved access to patient data, which can help clinicians as they diagnose and treat patients and patients themselves as they strive to take more control over their health; streamlined monitoring of public health patterns and trends; an enhanced ability to conduct clinical trials of new diagnostic methods and treatments; and the creation of new high-technology markets and jobs. Health information technology can also help support a range of healthcare-related economic reforms needed to address our Nation’s long-term fiscal challenges.

PCAST has also concluded that to achieve these objectives it is crucial that the Federal Government facilitate the nationwide adoption of a universal exchange language for healthcare information and a digital infrastructure for locating patient records while strictly ensuring patient privacy. More specifically, PCAST recommends that the Office of the National Coordinator for Health Information Technology and the Centers for Medicare and Medicaid Services develop guidelines to spur adoption of such a language and to facilitate a transition from traditional electronic health records to the use of healthcare data tagged with privacy and security specifications.

PCAST hopes that its report will help lay a foundation for the decisions that you and others in the Federal Government must make. We are grateful for the opportunity to serve you and the country in this way and would be pleased to brief you or your staff if you have questions about our recommendations.

Sincerely,

John P. Holdren

Co-Chair

Eric Lander

Co-Chair 

Executive Summary

Information technology (IT) has the potential to transform healthcare as it has transformed many parts of our economy and society in recent decades. Properly implemented, health IT can:

  • Integrate technology into the flow of clinical practice as an asset, while minimizing unproductive data entry work.
  • Give clinicians real-time access to complete patient data, and provide them with information support to make the best decisions.
  • Help patients become more involved in their own care.
  • Enable a range of population-level public health monitoring and real-time research.
  • Improve clinical trials, leading to more rapid advances in personalized medicine.
  • Streamline processes, increase their transparency, and reduce administrative overhead, as it has in other industries.
  • Lead to the creation of new high-technology markets and jobs.
  • Help support a range of economic reforms in the healthcare system that will be needed to address our Nation’s long-term fiscal challenges.

Despite this great promise, the impact of IT on healthcare over the past decade has so far been modest. Currently, almost 80 percent of physicians—the majority in small, independent practices—lack even rudimentary digital records. Where electronic records do exist, they are typically limited in functionality and poor in interoperability. As a result, the ability to integrate electronic health information about a patient and exchange it among clinical providers remains the exception rather than the rule. Compared to other industrialized nations, the United States lags far behind in the use of electronic health records.

As we will describe, the Administration and the Congress have recently made major investments to ensure that Americans soon enjoy the benefits of electronic health records. The Administration has been moving rapidly to promote the adoption by physicians and hospitals of electronic health systems, including through recent, important rule-making for 2011. The President’s Council of Advisors on Science and Technology has undertaken this report to examine the critical issues for the next phase, which has just begun, and to make specific recommendations to the Administration to ensure that the full promise of health IT is realized.

In other sectors in which IT has had a transforming effect, rapid progress has been catalyzed by wise technology choices that open up markets to competition and innovation. Such technology choices include the standardization of simple universal methods for the exchange of information across multiple platforms and organizations. In other sectors, universal exchange standards have resulted in new products that knit together fragmented systems into a unified infrastructure. The resulting “network effect” 1 then increases the value of the infrastructure for all, and spurs rapid adoption. By contrast, health IT has not made this transition. The market for new products and services based on health IT remains relatively small and undeveloped compared with corresponding markets in most other sectors of the economy, and there is little or no network effect to spur adoption.

Several identifiable barriers in the healthcare system currently discourage innovation and vigorous competition in the market to create effective health IT systems. First, most current health IT systems are proprietary applications that are not easily adopted into the workflow of a clinician’s day, and whose proprietary data formats are not directly exchangeable from one system to another. It is difficult for data to be disaggregated, indexed, searched, and assembled to provide accurate information to treat a patient, because the context for individual entries in a record is often implicit at best. Second, most healthcare organizations that utilize electronic health records (EHRs) view them as purely internal resources, and have little incentive for investment in secondary or external uses, such as making them accessible in appropriate form to patients, to a patient’s healthcare providers at other organizations, and in de-identified or aggregated form to public health agencies and researchers. Third, legitimate patient concerns about privacy and security make patients uneasy about participating in health IT systems or granting consent for their information to be used in research. Fourth, health IT has historically been oriented toward administrative functions, not better care. This is in part because, under the current fee-for-service payment model, the economic benefits of investing in health IT can rarely be realized by the provider or organization that makes the investment.

Some healthcare organizations have overcome at least some of these barriers and successfully adopted electronic systems that measurably improve care within their own organization. Kaiser Permanente and the Veterans Health Administration are notable examples. Other leading hospitals and clinics also employ electronic record systems that allow them to consolidate patient health data generated within their organizations. However, even these successes, upon closer examination, highlight the limitations of current approaches. They are usually “one offs,” designed for the particular organization, not for a wide range of other types of practices. They are generally closed, and not designed for the exchange of data with a heterogeneous and geographically diverse set of other organizations that may serve the patient now or in the future. They typically require capital investments that are beyond the reach of most small clinical practices. And, they are too limited in scope, and few in number, to drive a vigorous market in technological innovation.

Recent Federal legislation has charted a new path forward. The Health Information Technology for Economic and Clinical Health (HITECH) Act, a part of the American Recovery and Reinvestment Act (ARRA) of 2009, authorized expenditures of at least $20 billion to promote the adoption and use of EHR technologies that would ideally be connected through a national health information network. Hospitals and physicians who make “meaningful use” of interoperable EHRs can qualify for extra payments through Medicare and Medicaid.

Responsibility for developing policies that implement the overall HITECH Act lies primarily with the Office of the National Coordinator for Health Information Technology (ONC). In this role, ONC works closely with the Center for Medicare and Medicaid Services (CMS), which is responsible for promulgating policies that relate to Medicare and Medicaid payment for meaningful use of EHRs under HITECH. ONC and CMS recently released final rules to implement the first phase of the HITECH Act, which begins in 2011. The​ ONC rule specifies the standards, implementation specifications and other criteria for EHR systems and technologies to be certified under HITECH and thus eligible for the Acts incentive programs while the CMS rule specifies how hospitals, physicians, and other eligible professionals must demonstrate their meaningful use of these technologies in order to receive Medicare and Medicaid payment incentives. Both sets of rules strongly indicate that standards and criteria for achieving meaningful use of EHRs will grow more rigorous in subsequent phases (2013 and 2015) as the technology continues to evolve and providers gain experience and sophistication in its use.

Given the national priority of health care reform, President Obama asked PCAST how health IT could improve the quality of healthcare and reduce its cost, and whether existing Federal efforts in health IT are optimized for these goals. In response, PCAST formed a working group consisting of PCAST members and prominent experts in both healthcare and information technology. Based on input from the working group, additional expert reviewers, and its own discussions, PCAST has reached six major conclusions.

1. HHS’s vigorous efforts have laid a foundation for progress in the adoption of electonic health records, including through projects launched by ONC, and through the issuance of the 2011 “meaningful use” rules under HITECH. ONC has shown itself to be a technologically sophisticated agency, with outstanding outreach into the clinical community and good liaison with incumbent EHR system vendors. The Nationwide Health Information Network (NHIN) project has convened stakeholders and created an appropriate forum for the discussion of options. Strategic Health IT Advanced Research Projects (SHARP) in areas including network architectures and data use will produce important practical advances, as will work resulting from the establishment of a Federal “collaboratory” in clinical decision support. Importantly, the 2011 “meaningful use” rules recently released by ONC and CMS provide necessary first steps, and we endorse these rules.

2. In analyzing the path forward, we conclude that achievement of the President’s goals requires significantly accelerated progress toward the robust exchange of health information. The initial approach to meaningful use has focused on driving physicians to adopt EHR systems that perform important quality-improving functions within the practice and, to a lesser extent, on developing capabilities for broader sharing. Though the rule expresses an intent to require more robust exchange of health information among providers at later stages of meaningful use, its initial requirements that EHR systems communicate with each other are very modest. This creates a danger that EHR adoption during early stages of meaningful use may exacerbate the problem of incompatible legacy systems. What is needed is a simultaneous focus on the capability for universal data exchange, able to unleash the power of the competitive market, to produce increasingly better and less expensive systems, and to create the “network effect” that spurs further adoption. While useful as an initial step, the adopted standards for data vocabulary and messaging will not be sufficient to advance the state of the art either of clinical practice or of a robust health IT infrastructure. Going forward, the critical issue is to facilitate progress by healthcare organizations by ensuring the creation and dissemination of a universal exchange language for healthcare information and an infrastructure for locating patient records, while rigorously protecting privacy and security. This would allow patient outcomes to become a larger part of meaningful use much more quickly, and make it less onerous for clinicians to generate and report a wide range of different kinds of information about the outcomes of their practice.

3. National decisions can and should be made soon to establish a “universal exchange language” that enables health IT data to be shared across institutions; and also to create the infrastructure that allows physicians and patients to assemble a patient’s data across institutional boundaries, subject to strong, persistent, privacy safeguards and consistent with applicable patient privacy preferences. Federal leadership is needed to create this infrastructure. While the ability to exchange and integrate health data offers great advantages to patients, the economic benefits of these capabilities do not accrue directly to specific providers, or to providers’ incumbent EHR system vendor (if any). As a result, market forces are unlikely to generate appropriate incentives for the necessary coordination to occur spontaneously. The nature of this coordination as a public good requires Federal leadership in ensuring the creation of the capabilities. The development of EHRs themselves should of course be left to the private sector.

4. Creating the required capabilities is technically feasible, as demonstrated by technology frameworks with demonstrated success in other sectors of the economy. The best way to manage and store data for advanced data-analytical techniques is to break data down into the smallest individual pieces that make sense to exchange or aggregate. These individual pieces are called “tagged data elements,” because each unit of data is accompanied by a mandatory “metadata tag” that describes the attributes, provenance, and required security protections of the data. Universal exchange languages for metadata-tagged data, called “extensible markup languages” are widely and successfully used. Indeed, ONC’s clinical document architecture standard (CDA) is such a markup language, and is an important step in the right direction. The indexing and retrieval of metadata-tagged data, across large numbers of geographically diverse locations, is an established, highly developed, technology—the basis of web search engines, for example. With ONC leadership, these technologies could rapidly be adapted and standardized for universal use in health IT. Innate, strong, privacy protection on all data, both at rest and in transit, with persistent patient-controlled privacy preferences, is likewise achievable, and must be designed in from the start.

5. ONC should move rapidly to ensure the development of these capabilities; and ONC and CMS should focus meaningful use guidelines for 2013 and 2015 on the more comprehensive ability to exchange healthcare information. ONC should act boldly to articulate a clear, common framework that will ensure that its various efforts converge into an effective healthcare IT ecosystem that serves patients and providers. The steps that must be taken can be accomplished within the required time frame. It can be accomplished via an evolutionary transition from traditional EHRs to a tagged data element model, along with a more rapid transition for the more limited purpose of data exchange by means of a universal exchange language. We note that these steps are not intended as an alternative to ONC’s important work in promoting the adoption of electronic health records. Rather they are complementary to that work and will accelerate adoption.

6. Finally, as CMS leadership already understands, CMS will require major modernization and restructuring of its IT platforms and staff expertise to be able to engage in sophisticated exchange of health information and to drive major progress in health IT. This process has begun, but needs to be a more urgent priority for the Administration and Congress and should be funded as appropriate for an essential component of the Nation’s healthcare quality and afford ability agenda. A recently initiated National Research Council study of CMS’s IT capabilities should result in recommendations that will avoid replacing one inflexible architecture with another (a common trap in Federal IT acquisitions), but a successful outcome is at best several years away.

The approach that we describe requires that there be a common infrastructure for locating and assembling individual elements of a patient’s records, via secure “data element access services” (DEAS). Importantly, this approach does not require any national database of healthcare records; the records themselves can remain in their original locations. Distinct DEAS could be operated by care delivery networks, by states or voluntary grouping of states, with possibly a national DEAS for use by Medicare providers. All DEAS will be interoperable and intercommunicating, so that a single authorized query can locate a patient’s records, across multiple DEAS.

Advantages of focusing on a universal exchange language

Briefly, the approach described in this report, focused on the technical ability to exchange data in uniform ways, has multiple advantages:

  • It will improve healthcare quality, by making it possible for a physician to integrate accurately all of a patient’s medical information.
  • It will improve healthcare quality and decrease costs, by making it possible for third-party innovators to compete to create widely applicable services and tools serving patients, providers, payers, public health officials, and researchers.
  • It will provide much stronger privacy protection than available under current approaches, allowing persistent privacy assurances (including applicable patient preferences) to be attached to different kinds of information and using data-level encryption to prevent access of data by unauthorized persons.
  • It will not require universal patient identifiers, nor will it require the creation of Federal databases of patients’ health information.
  • It will simplify the regulatory burden on providers, by decreasing the focus of meaningful use regulations on ad hoc list of data items.
  • It will help U.S. industry leapfrog to the front of the pack internationally in health IT, by providing exchange standards that can be more broadly adopted by others.
  • It will facilitate public health and medical research, by providing a secure way to de-identify data.
  • It will not require that existing systems be replaced, but only be modestly upgraded or augmented by “middleware.”

In short, the approach is designed to create robust ecosystem to support the needs of patients, providers, payer, researchers and the Nation.

Creating the ability for uniform exchange in an existing marketplace is a coordination problem; it is a public good that calls for Federal leadership in coordinating standards for health metadata and in creating economic incentives to adopt the standard. The definition of meaningful use and the rewards for being a meaningful user (and penalties for not being one) can be, if properly implemented, powerful mechanisms for doing this.

Finally, one must keep in mind that achieving the truly transformative effect of modern health IT infrastructure on the healthcare sector will also require that economic incentives are in place to improve the quality of care and reduce costs.

Recommendations

The final chapter of this report offers guidance to ONC and CMS and also makes an itemized set of specific recommendations. We urge ONC to augment its current “bottom-up” approach with a process that can generate “top-down” design choices that are carefully balanced between the goals of convergence and diversity. This is an appropriate government role and requires a more aggressive approach than has been taken in the early stages. We also discuss how ONC might, by standardizing a universal exchange language whose semantics is intrinsically extensible, unburden itself of a potentially never-ending and intrusive government role in the harmonization of health record meanings across all private sector products. An open, extensible language will allow products to compete, balanced with other competitive features, on the basis of the breadth of their abilities to understand multiple semantic realms. ONC’s clinical document architecture standard (CDA) is an important step in the right direction, but needs more focus on data transmission, on innate privacy features, and on the enabling requirements of a more robust marketplace in new and innovative health IT products.

As regards CMS, we suggest specific ways in which the meaningful use process could be used to better advance more strategic national goals in health IT. Apropos of the much-needed overhaul of CMS’s antiquated IT infrastructure, we emphasize the importance of not replacing one inflexible architecture with another and briefly suggest what a modernized, versatile infrastructure might look like. Fortunately, CMS now has new leadership, with the appointment of an administrator. A solid technical plan, with the necessary resources, will be now required for success.

Although ONC and CMS both lie organizationally within U.S. Health and Human Services (HHS), the dimensions of health IT are broadly consequential across multiple Federal departments, including Veterans Affairs (VA) and Department of Defense (DoD). Among our recommendations, we therefore suggest that the Chief Technology Officer of the United States in coordination with the Office of Management and Budget and HHS, develop within 12 months a set of metrics that measure progress toward an a operational, universal, national health IT infrastructure that has the desirable features that we have discussed. Focusing these metrics on operational progress, as distinct from research, prototype, and pilot efforts, will enable a more accurate continuing assessment of whether Federal efforts in health IT, including both executive initiatives and legislative mandates, are in fact supportive of the President’s goal of increasing the quality, and decreasing the cost, of healthcare.

PCAST Health Information Technology Working Group

Working Group members participated in the preparation of an initial draft of this report. They are not responsible for, nor necessarily endorse, the final version of this report as modified and approved by PCAST.Co-Chairs

Co-Chairs

Christine Cassel*
President and CEO
American Board of Internal Medicine

Craig Mundie*
Chief Research and Strategy Officer
Microsoft Corporation

Members

Peter B. Bach
Attending Physician and Full Member
Memorial Sloan-Kettering Cancer Center

Basit Chaudhry
Consultant, physician

Molly Joel Coye
Senior Advisor
Public Health Institute

John Halamka
Chief Information Officer
Beth Israel Deaconess Medical Center
Chief Information Officer
Harvard Medical School

Staff

Mary Maxon
Deputy Executive Director, PCAST

Eric Lander*
President
Broad Institute of MIT and Harvard

Jonathan Levin
Professor of Economics
Stanford University

Louise Liang
Retired Senior Vice President
Quality and Clinical Systems Support
Kaiser Permanente

William Press*
Professor of Computer Science and
Integrative Biology
University of Texas at Austin

Stephanie L. Reel
Vice President and Chief Information
Officer
Johns Hopkins University and Johns
Hopkins Health System

Harold Varmus* 2
President
Memorial Sloan-Kettering Cancer Center

* PCAST member

I. Introduction and Overview

Introduction

Improving the quality and decreasing the costs of healthcare are among the Nation’s highest priorities. In 1960, healthcare expenditures represented about 5 percent of the United States’ gross domestic product (GDP). 3 Today they represent about 16 percent—the largest share of GDP spent on healthcare among all major industrialized countries. Yet on critical measures of healthcare outcomes, such as life expectancy, infant mortality, and the number of physicians per capita, the United States ranks behind many other countries. 4 Our expenditures are not producing the results we should expect.

Information technology has the potential to transform healthcare as it has transformed many parts of our economy and society in recent decades. Health information technology 5 can allow clinicians to have real-time access to complete patient data, and provide them with support to make the best possible decisions. 6 It can help patients become more involved in their own care, which is especially important in managing chronic conditions like diabetes, asthma, or heart disease. It can enable a range of population-level monitoring and real-time research such as the detection of developing epidemics, health risks in the environment, or adverse events caused by medications. It can improve clinical trials, leading to more rapid advances in personalized medicine. It can streamline processes and reduce administrative overhead, as it has in other industries. It can lead to the creation of new, high-tech markets and jobs. Finally, it can help support a range of economic reforms in the healthcare system that will be needed to address our country’s long-term fiscal challenges. As David Blumenthal, the National Coordinator for Health Information Technology, has written, “Information is the lifeblood of modern medicine, [and] health information technology is destined to be its circulatory system.” 7

Despite this great promise, however, the impact of IT on healthcare has so far been modest. Currently, almost 80 percent of physicians—the majority in small, independent practices—lack even rudimentary digital records. 8 Of those who do use electronic systems, most do not make full use of their potential functionality. The sharing of health information electronically remains the exception rather than the rule. The market for new products and services based on health IT remains relatively small and undeveloped compared with corresponding markets in most other sectors of the economy. While recent Federal initiatives have made some important advances toward changing this situation, healthcare has taken only the first few steps toward an electronic future.

The Origins of This Study

Given the importance of healthcare to the Nation’s future, the President asked his Council of Advisors on Science and Technology how health IT could improve the quality of healthcare and reduce its cost, and whether existing Federal efforts in health IT are optimized for these goals. In response, PCAST formed a working group consisting of PCAST members and prominent experts in both healthcare and information technology. 9

The working group held meetings in Washington, D.C., on December 18, 2009, and in Irvine, California, on January 14-15, 2010, as well as additional meetings by teleconference. The viewpoints of researchers, policy analysts, and administrators from government, healthcare organizations, and universities were presented and discussed. Additional analysis of the current state of health IT implementation among the 80 percent of physicians who practice outside of large integrated healthcare organizations was performed by the Science and Technology Policy Institute (STPI).

A draft report developed by the working group was submitted to the Health and Life Sciences committee of PCAST. That committee submitted the draft to several outside reviewers, who made valuable suggestions for improvements. From the working group draft, the additional input, and its own discussions, the Health and Life Sciences committee produced the present report, which was discussed and endorsed (with some modifications) by the full PCAST in public session on July 16, 2010.

Analysis of the Problem

Several identifiable barriers in the healthcare system currently discourage innovation and vigorous competition in the market to create effective health IT systems.

First, the diffusion of IT within healthcare has been slow and oriented toward administrative functions. Electronic health records that contain patient information captured in clinical visits, through lab and imaging studies, and likely in the future from genetic tests, are a cornerstone of health information technology. Many healthcare providers, however, do not have the economic incentives and technical expertise to purchase and use EHRs. Physicians who do adopt EHRs often find they are spending extra hours each day to type in orders, notes from patient visits, or measures to be reported to CMS without receiving commensurate benefits. In addition, the fee-for-service payment model prevalent in U.S. healthcare does not create strong incentives to coordinate care, share information, or avoid unnecessary treatments, all of which are potential advantages of using EHR systems.

Second, the current structure of health IT systems makes it difficult to extract the full value of the data generated in the process of healthcare. Most electronic health records resemble digital renditions of paper records. This means that physicians can have trouble finding the information they need, and patients often wind up with poor access to their own health data and little ability to use it for their own purposes. Electronic records often do not include links to relevant information such as recent research findings or data on best practices that physicians and patients could use to make the best possible decisions. For reasons we discuss below, market innovation has not yet adequately addressed these challenges to the usability of electronic health records.

Third, standards and infrastructure are lacking that would allow information to be easily shared across organizations. Relevant information does not seamlessly move with patients who receive care from multiple providers. This leads to duplication and hinders coordination of care. The lack of data exchange also means that researchers and public health agencies have limited access to data that could be used to improve health systems and advance biomedical research. Present Federal initiatives, described below, have the effect of encouraging the development of local and regional health information exchanges (HIEs) that involve agreements to exchange data among clusters of organizations. These exchanges are hampered by the administrative burdens of developing agreements and by a lack of financial incentives to increase coordination and efficiency. It is also unclear how these exchanges might scale to a national level.

Fourth, patients are concerned that the storage of their health information in electronic form will make it easier for employers, insurers, government, or malicious electronic intruders to improperly access their records. This concern may make them unwilling to participate in health IT systems or grant consent for their information to be used in research, even though the aggregation of patient data to compare treatments and providers is a major benefit of health IT. Data can be anonymized by removing all personal identifiers from the data. But patients also may want to be re-contacted if analysis of their data reveals a problem with a medication they are taking or a treatment that could benefit them.

Some large healthcare organizations have overcome at least some of these barriers and successfully adopted EHR systems. The VistA system adopted by the Veterans Health Administration (VHA) has helped the Nation’s largest integrated health system provide a highly regarded level of information technology supporting better care. Kaiser Permanente’s HealthConnect system links all of Kaiser’s nearly 9 million members to all of its more than 14,000 physicians and their hospitals, rehabilitation centers and long-term-care facilities, so that Kaiser physicians can retrieve data on any patient who has received services anywhere in its network. Other leading hospitals and clinics also employ electronic record systems that allow them to consolidate patient health data generated within their organization.

These successes, however, also illuminate the limitations mentioned above. Even the most sophisticated organizations generally do not have efficient means to exchange health information with other providers. When exchanges occur, they often take place through limited or pre-formatted messages, such as electronic prescription information, or through comprehensive patient care summary documents, which cannot easily be searched for timely information such as that needed in an emergency. In addition, the systems employed by these large organizations are engineered to meet the specific needs of the organization that owns them, so they do not provide an open and accessible platform for market innovation that might lead to improvements in usability or functionality.

The main objective of this report is to argue that if health information technology is to have a truly transformative effect, the Federal Government should push ambitiously toward a national health data infrastructure in which patient data are readily available to providers in real time, can be accessed in de-identified form by researchers and public health agencies, and in which a market for applications that enhance EHR usability and patient involvement can flourish, enabling a “network effect” that can spur further adoption. The report describes a technological approach that could lead to this vision being realized, while at the same time strongly protecting privacy (including, where applicable, respecting the persistent privacy preferences of patients), and also describes some of the accompanying economic and regulatory steps that are required.

The Present Federal Landscape

Recent Federal legislation offers a promising start toward these objectives. The Health Information Technology for Economic and Clinical Health Act, a part of the American Recovery and Reinvestment Act of 2009, 10 authorized expenditures on the order of $20 billion (with estimates ranging from $9 billion to $27 billion) to promote the adoption and use of EHR technologies connected through a national health information network. Under HITECH, hospitals and physicians who make “meaningful use” of interoperable EHRs can qualify for extra payments through Medicare and Medicaid.

Responsibility for developing policies that implement the overall HITECH Act lies primarily with the Office of the National Coordinator for Health Information Technology; however, ONC also works closely with the Center for Medicare and Medicaid Services which is responsible for promulgating policies that relate to Medicare and Medicaid payment for meaningful use of EHRs under HITECH. Both ONC and CMS recently released final rules to implement the first phase of the HITECH Act, which begins in 2011. The ONC rule specifies the standards, implementation specifications and other criteria for EHR systems and technologies to be certified under HITECH and thus eligible for the Act’s incentive programs while the CMS rule specifies how hospitals, physicians, and other eligible professionals must demonstrate their meaningful use of these technologies in order to receive Medicare and Medicaid payment incentives. Both sets of rules strongly indicate that standards and criteria for achieving meaningful use of EHRs will grow more rigorous in subsequent phases (2013 and 2015) as the technology continues to evolve and providers gain experience and sophistication in its use. For example, to qualify for meaningful use incentive payments in 2011, CMS will require providers to be able to electronically transmit medication orders, record patient information and problem lists, demonstrate use of decision support tools, test systems to exchange health information with other providers, and submit a small number of clinical quality measures; by 2015, CMS expects that to qualify for meaningful use of EHRs, providers will need to demonstrate greater use of decision support tools, higher levels of information exchange, and actual improvement in care coordination and patient outcomes. The ONC also has moved to take a number of other useful actions in the short time since passage of HITECH. The ONC director and his staff have sparked needed awareness in the provider community, galvanized the experts and industry stakeholders, and created a momentum for change through open policy committee processes, several pilot frameworks, and the support of research in key areas. In addition, they have directly funded regionally based support systems for physicians and other providers, and supported several new programs and research initiatives designed to promote the use of health IT and the exchange of health information. ONC has distributed over $564 million to states and state- designated entities to enlist their leadership in facilitating health information exchange within their jurisdictions and across state lines. Moreover, ONC is sponsoring many demonstration projects that build useful momentum and develop valuable experience and buy-in. These have helped to create the prerequisite conditions where Federal leadership, leading to rapid progress, is now possible. Further discussion of ONC’s initiatives and successes is in Chapter Three.

Despite this progress, a major finding of this report is that achieving the President’s goals depends on accelerating and redirecting current Federal work laying the groundwork for health information exchange. While the 2011 rules are an appropriate initial step, the approach underlying these rules will not suffice to ensure that the various activities and experiments being supported by ONC will converge into an effective healthcare IT ecosystem that serves patients and providers. Going forward, the critical issue will be to ensure the creation, dissemination, and use of a universal exchange language for healthcare information that enables health IT data to be shared across institutions, along with network infrastructure that enables a patient’s data to be located and accessed across institutional boundaries, subject to strong, persistent, privacy preferences 11. ONC should move rapidly to ensure the development of these capabilities; and ONC and CMS should focus meaningful use guidelines for 2013 and 2015 on the more comprehensive ability to exchange healthcare information.

We also have an important concern about CMS. CMS is the largest recipient of electronic health information (including data quality measures and measure sets) from hospitals and providers documenting their use and the effects of health IT. CMS will require major modernization and restructuring of its IT platforms and staff expertise to be able to engage in sophisticated exchange of health information and to drive major progress in health IT. This should be a major priority for CMS’s new leadership, and should be funded as appropriate for an essential component of the Nation’s healthcare quality and affordability agenda. A recently initiated National Research Council study of CMS’s IT capabilities should result in recommendations that will avoid replacing one inflexible architecture with another (a common trap in Federal IT acquisitions), but a successful outcome is at best several years away.

Several other agencies within HHS have potentially important roles in health IT. The Agency for Health Care Research and Quality (AHRQ) is a small but increasingly important research agency supporting health services and delivery system research. Approximately 80 percent of its FY 2009 budget of $372 million is invested in grants and contracts focused on improving healthcare. 12 The Food and Drug Administration (FDA), while not currently regulating EHRs, currently does receive voluntary reports of death and injury associated with EHR malfunctions. FDA officials have suggested possible future regulatory strategies that could include mandatory adverse event reporting, or even classifying EHRs as medical devices, which would make them subject to pre-market regulation. 13 Other agencies with operational experience, such as the Centers for Disease Control & Prevention (CDC), or individuals in the Commissioned Corps of U.S. Public Health Service, might have roles to play in the management or operation of a future national health IT infrastructure.

Structure of This Report

Chapter Two gives a more thorough description of the benefits that could be realized by developing electronic health records to their full potential and integrating health information technology more completely into the healthcare system. The main features of the data-centric approach that we recommend are introduced with an initial discussion of metadata-tagged data elements. Chapter Three describes in more detail the current state of health information technology, starting with the historical adoption and use of electronic records, and emphasizing the barriers that have arisen. The discussion focuses on specific cases that yield “lessons learned,” both positive and negative. Also discussed are the successes and challenges facing the two key agencies ONC and CMS. The chapter concludes with a list of technical and market-related criteria against which to test proposed solutions. Chapter Four outlines a technological approach based on the use of tagged data elements that could achieve many, if not all, of the key objectives. This chapter is somewhat more technical, although its general argument should be understandable by all readers. The deficiencies of solutions that require standardized records, or which rely on service-oriented architectures, are also noted. Chapter Five summarizes today’s privacy framework and indicates the ways in which it is inadequate for the future. Technologies are discussed that can be combined to achieve best-practice security along with persistent privacy protections. Chapter Six discusses economic and regulatory issues, in particular how to reconcile the “public good” aspects of a national health IT infrastructure with the need to create vibrant, competitive markets. This chapter describes some of the main steps that are needed to complement the technological approach described in Chapters Four and Five, and relates health IT initiatives to the broader economics of healthcare. Chapter Seven outlines some of the research opportunities that will be enabled by future health IT, and what are the requirements on that infrastructure so that the maximum benefits of that research can be achieved. Chapter Eight brings together this report’s recommendations and guidance to key Federal agencies. We offer guidance of both a general and specific nature to ONC and CMS, and also suggest what a longer term roadmap should look like. Among our key recommendations is that the Chief Technology Officer of the United States should oversee the development of a set of metrics that measure progress toward a national health IT infrastructure that is operational and universal (as distinct from experimental and pilot programs). This chapter’s bottom line: Health information technology has the potential to improve the healthcare system in numerous ways. Yet Federal efforts are not optimized to achieve the President’s goals of improving the quality of healthcare and reducing its cost. Challenges differ by agency, but they include the need for more focus on the convergence of plans and the modernization of existing Federal IT infrastructure.

Despite this progress, a major finding of this report is that achieving the President’s goals depends on accelerating and redirecting current Federal work laying the groundwork for health information exchange. While the 2011 rules are an appropriate initial step, the approach underlying these rules will not suffice to ensure that the various activities and experiments being supported by ONC will converge into an effective healthcare IT ecosystem that serves patients and providers. Going forward, the critical issue will be to ensure the creation, dissemination, and use of a universal exchange language for healthcare information that enables health IT data to be shared across institutions, along with network infrastructure that enables a patient’s data to be located and accessed across institutional boundaries, subject to strong, persistent, privacy preferences11. ONC should move rapidly to ensure the development of these capabilities; and ONC and CMS should focus meaningful use guidelines for 2013 and 2015 on the more comprehensive ability to exchange healthcare information. We also have an important concern about CMS. CMS is the largest recipient of electronic health information (including data quality measures and measure sets) from hospitals and providers documenting their use and the effects of health IT. CMS will require major modernization and restructuring of its IT platforms and staff expertise to be able to engage in sophisticated exchange of health information and to drive major progress in health IT. This should be a major priority for CMS’s new leadership, and should be funded as appropriate for an essential component of the Nation’s healthcare quality and affordability agenda. A recently initiated National Research Council study of CMS’s IT capabilities should result in recommendations that will avoid replacing one inflexible architecture with another (a common trap in Federal IT acquisitions), but a successful outcome is at best several years away. Several other agencies within HHS have potentially important roles in health IT. The Agency for Health Care Research and Quality (AHRQ) is a small but increasingly important research agency supporting health services and delivery system research. Approximately 80 percent of its FY 2009 budget of $372 million is invested in grants and contracts focused on improving healthcare.12 The Food and Drug Administration (FDA), while not currently regulating EHRs, currently does receive voluntary reports of death and injury associated with EHR malfunctions. FDA officials have suggested possible future regulatory strategies that could include mandatory adverse event reporting, or even classifying EHRs as medical devices, which would make them subject to pre-market regulation.13 Other agencies with operational experience, such as the Centers for Disease Control & Prevention (CDC), or individuals in the Commissioned Corps of U.S. Public Health Service, might have roles to play in the management or operation of a future national health IT infrastructure.

II. The Potential of Health IT

Introduction

In this chapter, we describe some of the potential benefits that could be realized from developing EHRs to their full potential and integrating health information technology more completely into the healthcare system. The benefits we describe might accrue at the level of individual clinical visits, at the level of healthcare organizations, at a broader regional and national level, and finally to patients wishing to have more information and more control over their own health and interactions with the healthcare system. We provide a series of “use cases” that illustrate the various levels at which information technology can improve healthcare delivery and the healthcare system.

We also note that formidable hurdles need to be overcome if these benefits are to be realized. The hurdles are both technological and economic. A key point is that current electronic health records, which are based on traditional paper records and exist largely within closed health organizations, cannot realize many of the potential benefits we have described. In order for health data to be broken down, indexed, transmitted across organizations, re-assembled, and aggregated, a more flexible technological approach is desirable. This approach is sketched below and described more fully in Chapter Four.

Later chapters expand on some of the other challenges that must be overcome to realize the potential benefits of health IT. Some early applications of IT in healthcare have had unexpected costs and consequences, and, despite the existence of commercial products and innovative demonstrations and pilot systems, the movement to electronic health records has been slow. The economic incentives to adopt and effectively utilize health IT have been weak, and the organizational structure of the healthcare system is itself highly fragmented. Current privacy regulation also creates complications for providers wishing to adopt and utilize IT. In short, there remain many barriers to achieving the potential of widespread and secure access to accurate, personalized, and comprehensive health data.

Potential Benefits of Health IT: An Overview

As medical practices and technologies have advanced, the delivery of sophisticated, high-quality medical care has come to require teams of healthcare providers, including primary care physicians, specialists, hospitalists, nurses, and technicians. Each member of the team tends to have specific but inevitably limited direct interactions with the patient. Every health provider has a somewhat different view of a patient, depending on the expertise the particular specialist brings to the medical team, and no one provider knows everything. In effect, the patient has fragmented into disconnected facts and clusters of symptoms. To prevent the most basic medical errors, some facts are elicited over and over again, to the frustration of patients and healthcare providers alike: “Do you have any drug allergies?” “Have you had any surgeries?” “Are you taking aspirin or blood thinners?” This frustrating repetition works, albeit inefficiently, if the patient is cognitively intact and well informed, but not all patients fit that description, especially in the event of a serious or acute illness.

Health providers need views of the patient that are less fragmented than at present. A cardiologist, for example, needs immediate access to a patient’s most recent and significant cardiograms, cardiac imaging studies, and lab tests. He or she also needs to know about a family history of heart disease, concurrent illnesses being cared for by other specialists, past medical events, recent medications, and activity and nutrition changes. A nutritionist needs to know about a patient’s serum cholesterol and also about life changes, such as a new job or the illness of a spouse, that may have caused a sudden change in the patient’s diet. Health IT can integrate and organize patient information, and facilitate its instantaneous distribution among all participants in the healthcare system, so that providers and patients can obtain complete up-to-date views of each patient. In simple terms, health IT has the potential to put the patient back together again to allow more coordinated care.

Health IT also has the potential to generate valuable new information to improve workflow, safety, and efficiency within healthcare organizations. In industries such as manufacturing, retailing, and financial services, the efficiency gains from information technology were realized only when companies made complementary organizational changes. Today, some health organizations already use IT to track quality metrics, deploy reminder systems and checklists for physicians and other caretakers, and provide rapid feedback for the organization when changes are made. The widespread adoption of health information technology could allow these efforts to spread throughout the healthcare system.

The aggregation of data across organizations offers further possibilities. If the data gathered by healthcare providers and the decisions made at the point of care by providers and patients were gathered and aggregated, they could reveal patterns of illness in a community or nationally, identify potential epidemics at very early stages, enable comparisons of different treatments or medical devices in large and diverse populations, and evaluate the effectiveness of specific treatments and make information about hospitals, physicians, and other providers more comprehensive and accurate. Healthcare providers could use the information generated from these data to provide up-to-date and accurate guidance for patients, while healthcare recipients could draw on the data to prevent illness and obtain the best possible treatments. Data used to be an incidental byproduct of healthcare. In the future, timely information derived from high-quality data should be at the center of efforts to analyze, understand, and improve the healthcare system.

The next sections expand on these potential benefits of health IT, in part through simple “use cases.” Readers may, and probably should, find some of these cases rather easy or obvious. Indeed, what is surprising is that today they are generally not possible in most care delivery environments.

Table 1. The Potential Benefits of Health IT

The ability to capture, store, exchange, and analyze medical information in electronic form could improve U.S. healthcare in many ways.

  • Quality of care for individual patients. Patients will receive better medical care if they and their healthcare providers have access to complete and accurate electronic health records that aggregate information across time and organizations. Given the fragmented nature of the U.S. healthcare system, such integrated health records are now often not available. Such records could improve diagnoses, prevent errors, and save time.
  • Engagement of patients in healthcare. The participation of patients in their own healthcare could substantially improve their care, especially in the management and treatment of chronic conditions such as obesity and diabetes. Access to electronic personal health information and interfaces that make it easy for public and private clinical organizations to share health information with each other and with patients could enable healthcare providers and patients to collaborate in informed decision-making.
  • Clinical studies of medical interventions. Sound medicine needs to be based on empirical evidence of how well particular interventions work for patients. While some questions can only be answered through randomized clinical trials, a tremendous amount could be learned through the ability to integrate the combined experience of millions of patients. Aggregated de-identified information could enable a wide range of studies on such topics as the efficacy of prevention strategies, the frequency of particular complications in particular settings, and the response of individuals to specific drugs as a function of genotype.
  • Improved population-based knowledge. Aggregated health information can provide invaluable tools for identifying and tracking medical events such as epidemics and adverse events related to treatment.
  • Development of new tools for medicine. In most industries (such as retail consumer goods, shipping, and financial services), the availability of electronic information has led to an outpouring of creative tools that have increased quality and enabled new kinds of services. Healthcare could benefit greatly from such tools. Examples include home-based monitoring devices that could directly transmit data to physicians, systems that could help increase patient compliance with drug regimens, and computerized decision support systems able to incorporate the most up-to-date clinical knowledge.
  • Increased administrative efficiency. In most industries, electronic information also has led to a decrease in administrative costs as many processes became automated. In healthcare, administrative tasks (such as filling out forms and processing billing requests) represent a significant fraction of healthcare costs. Health IT could streamline these tasks and significantly decrease costs.

 

The Value of Patient-Specific Data to Patients

Electronic health information should enable patients to have full and accurate information about all medical evaluations, to track the management of their own conditions, to schedule and change appointments as appropriate, and to exchange email with providers. This would give patients and families more direct engagement with their care, create an avenue for communication with healthcare providers, and identify treatable symptoms early to avoid unnecessary emergency room visits or hospitalizations.

Use Case 1
A patient on warfarin, a blood thinner, strains his calf muscle during a tennis match and cannot remember whether it is safe to take Advil or Motrin. He types “Advil” into his personal health record list to see if there are any potential interactions with the list of medications in his record. Indeed, taking either Advil or Motrin would significantly increase his risk for serious bleeding. He emails his physician, who recommends cold packs and acetaminophen. The next day a discoloration and increased swelling occurs. He sends another email to the physician’s office, where he is connected to a nurse practitioner who recommends a blood coagulation test. He is able to select times online for the test, for follow-up with the physician, and for possible further tests and physical therapy.

 

Electronic health information also can improve coordination of care by ensuring that every specialist, in every setting, has the same accurate and up-to-date information about a patient. This is especially important with patients who are seeing multiple specialists, with patients making transitions between care settings, and especially in emergency settings. This kind of data availability will reduce medical errors, reduce unnecessary tests, and reduce the chance that a patient’s physician would not know about an unrelated but relevant condition being managed by another specialist.

Use Case 2
A 70-year-old woman with a newly diagnosed lung mass suspicious for lung cancer discovered on a CAT scan in a small community hospital is referred to a large academic center in a metropolitan area two hours away. The patient’s local hospital automatically makes available her electronic health record, enabling the cancer surgeon to pull up the CAT scan images and radiologist report at the patient’s consultation. She doesn’t remember all her medications, but her electronic record has recently been updated and verified. She may need a lung biopsy, and her record notes that she has an unusual cardiac arrhythmia that has been treated by a cardiologist in the past but that she is no longer taking medication. The biopsy is positive for lung cancer, and she will need both surgery and radiation. She is able to receive some of this treatment closer to one of her children, who lives in another state 1,200 miles away, with real-time communication electronically between her oncology team and her primary care physician. During this time, she is weakened and falls, sustaining a hip fracture. She is taken to the emergency room, where all her information is immediately available to sort out the otherwise confusing picture of cardiac arrhythmia, anemia from cancer treatment, and recent surgical scars.

 

The Value of Patient-Specific and Aggregated Data to Physicians

For the majority of U.S. physicians, electronic health information will for the first time enable them to query and analyze the “denominator” of their patient population—the full range of patients for whom they and their colleagues are responsible. This will make it possible for the physician to identify areas where patients are receiving less than optimal care—for example, how many patients with hypertension have their blood pressure under control, or how many patients with diabetes have their blood sugar measurements in the target range and have had appropriate screening tests.

This same clinical information is also essential to meet the growing number of demands for reporting of clinical quality measures for accountability and payment purposes. These demands are currently both expensive and cumbersome for most physicians, and to the degree that most of these data come from insurance companies, the data are limited to claims-linked information and are inevitably delayed and incomplete. Most physicians are very interested in and responsive to accurate evidence. Being able to interrogate one’s own data for rates of performance on quality measures could lead to significant healthcare improvements.

Use Case 3
A general internist decides to seek approval for her practice to be designated a patient-centered medical home (PCMH) under Medicare because she cares for a large number of patients with chronic illness, including diabetes, heart disease, and hypertension. This requires her to submit a large number of data entry forms and quality measures, including descriptions of her patients, their disease profiles, and their demographics. Her office staff is able to do this easily by extracting the information from her EHR system, and she receives the designation. Her office is also able to file quality of care and utilization reports on a regular basis to 10 other payers apart from Medicare, and create reports that aggregate her patient population across all payers. This allows her to identify gaps in preventive measures or diabetes and hypertension control and create reports to maintain specialty board certification and hospital privileges. When she identifies areas for improvement, she implements changes in her practice and later re-measures. For example, she and her partners have increased the rate of elderly patients who received preventive falls assessments, and were able to do the follow-up measures electronically because they share EHR data with the two retirement homes and several nursing homes in the region. In doing this, they drew on patient-specific risk profiles and guidelines available electronically from the National Institutes of Health and the American Geriatric Society decision support programs.

 

Payers and consumers are increasingly including the results of patient surveys in performance measures used for payment, public reporting, and improvement. A fully functional electronic healthcare information system would enable physicians to contact patients directly, to solicit patient feedback related to specific conditions, and to compile actionable feedback to the practice.

Use Case 4
A small group practice provides online access to each patient’s medical record and communicates regularly with its patients via email. The practice has recently implemented an open access scheduling system and is curious to learn how patients feel about the change, so they email all patients with a recent office visit a web link to complete a focused satisfaction survey. They also participate in the Consumer Assessment of Healthcare Providers and Systems (CAHPS) survey authorized by Medicare but would like to add more specific questions related to patient’s own conditions such as: “Did the nurse follow up with you about managing your new glucometer?” “Did your questions get answered?” They are able to personalize aspects of this survey and at the same time have only the needed aggregate data reported to payers.

 

As the use of quality measures increases, a question looms about how much real impact these measures will have on outcomes that are meaningful to patients. The combination of more efficient and accurate physician reporting with population-based outcome data could dramatically enhance critically important research about which of the measures link with desired patient outcomes, which of them lead most directly to improvement, and how to streamline the measurement and reporting process to reduce the time and financial burden on physician practices and still produce measures relevant to patient values.

Use Case 5
A group of cardiology clinics in the Southwest, separated by significant distance, decides to work together to improve the care of patients who recently experienced a myocardial infarction (heart attack). They link information from each clinic’s electronic medical records to track progress, learn what quality interventions work best, and create composite measures that help to distinguish what constitutes the best overall care. They are able to identify which sites have the best outcomes in certain areas, and they learn from each other how to apply these findings through webinars engaging all the staff in each clinic.

 

Having electronic health information about the entire population of patients served by a given practice or provider enables queries about groups of patients who suffer from a specific condition, are eligible for spec ific preventive measures, or are currently taking specific medications. Among other things, this population-based view enhances the ability of the practice to identify and work with patients to manage specific risk factors or combinations of risk factors. It also can detect patterns of potentially related adverse events and enable patients at risk to be quickly and correctly notified. For example, when a previously unidentified medication risk comes to light (as in the case of Vioxx), it is easy for the practice to identify all the patients taking that medication and to contact them immediately. If fully linked to the patient’s personal health record, this function would also apply to over the counter medications. Similarly, when a needed vaccine (such as H1N1) is available, the practice can identify the patients at greatest risk and communicate with them efficiently. Outreach, patient education, and notification about particular risks are made possible by this kind of system.

Use Case 6
A family physician embeds electronic reminders that alert her when the patient she is seeing during an office visit needs preventive care. Each fall, the clinic queries the electronic record to see which patients will need an influenza vaccine and to automatically generate a reminder email and/or text message sent to the patient. When an unusual pandemic strain appears, with different risk groups, the database can be queried to identify and communicate with those patients who are at highest risk.

 

The Value of Population Data for Research and Public Health

If real-time concurrent clinical data about every healthcare encounter were stored electronically, such data could be combined, without personal identifiers, from a regional or national population to allow enormous improvements in the ability to track public health issues and to develop prevention and amelioration strategies in a timely manner.

For example, natural epidemics such as H1N1 influenza are currently tracked through a combination of voluntary reporting by physicians and emergency rooms to various public health authorities and to the Centers for Disease Control and Prevention. Social networking and use of the Internet recently have been shown to add significantly to this capability.14 But neither of these methods is impeccably accurate and truly comprehensive or able to pick up nuances of epidemics from current clinical data. A fully functional health information network that was widely used, interoperable, and able to be aggregated with a reasonable degree of accuracy and reliability would dramatically improve the ability to track known epidemics, to identify new ones, and to identify at an early stage other threats to public health such as bioterrorism or environmental exposures.

With sophisticated modeling expertise, this same database would enable comparative effectiveness research by tracking groups of patients taking comparable treatments for similar conditions. The results of these virtual clinical trials would be more representative of real-life patient populations, far less costly to conduct, and quicker to identify information relevant to the care of specific patient groups. Furthermore, as medicine is connected more closely to genetically linked traits and susceptibilities, this kind of tracking will accelerate the ability to provide patient-specific information to physicians and patients to individualize treatment decisions.

Use Case 7
A physician treating a patient with rheumatoid arthritis using TNF (tumor necrosis factor) inhibitors enters the patient into the database of a national clinical study. Because the patient’s clinical and genetic information are both known, the physician is able to use specific characteristics to predict outcomes and reduce toxicity without relying on the traditional trial and error process. This information is available to all physicians and patients and is continually updated.

 

This de-identified but clinically rich database would also enable post-marketing surveillance for FDA-approved medications, which now depend on voluntary reporting by physicians and healthcare organizations. An efficient way to track patient populations taking new medications, including other prescribed or over-the-counter medications simultaneously being administered, adds tremendous power to the ability to pick up adverse events or medication interactions as early as possible. As genetic information becomes more routinely available, this kind of post-marketing research capability will enable more accurate prescribing. This is especially important for medications such as biological (or cell-based) therapies and cancer chemotherapies where potential toxicities are significant and current research methods necessitate exposing large numbers of people to toxic side effects when they might not benefit from the treatment.

Use Case 8
An FDA Commissioner is able to launch a real-time assessment of every patient taking newly approved drugs and aggregate clinical patterns to identify adverse side effects of medications. A robust post-marketing electronic registry allows much earlier detection of important adverse events for discrete subpopulations of patients and at negligible additional cost to FDA.

 

Population-based clinical data will enable communities, states, and regions to track their own health statistics in a more timely, reliable, and credible manner. As we consider the potential of setting health goals for communities as well as for the Nation, these data would provide a continuous measure against which all stakeholders (healthcare providers, community groups, consumer and workforce advocates, businesses, and government) could engage around setting targets and tracking progress. Congress has established a process to develop national priorities for improving healthcare in the United States, engaging all the relevant Federal agencies plus multi-stakeholder public-private collaborations.

Use Case 9
For a particular year, ambitious new goals are set to improve health measures. Communities, regions, and states are able to provide comprehensive and accurate annual reports on each of these goals, identifying gaps where special focus is needed and key areas for focus in coming years. This process does not require extensive additional data gathering by state and local public health entities. Rather, it uses the flow of de-identified information generated by regular population health and healthcare activities.

 

Realizing the Potential of IT: A Data-Centric Approach

The use cases above only scratch the surface of what might be possible if market innovation in information technology were to take off. A number of barriers, however, stand in the way. First, current electronic health records largely employ proprietary formats that are not directly exchangeable from one system to another. Second, it is difficult for data to be disaggregated, searched, and indexed because the context (what we will refer to as the metadata) for individual entries in an EHR is often implicit at best. 15 Third, current EHRs generally exist institutionally within closed healthcare organizations or disconnected small practices rather than being accessible in appropriate form to patients, to other healthcare providers, and in de-identified or aggregated form to public health agencies and researchers. Strong economic incentives and regulatory initiatives are needed to overcome these obstacles. The new economic and regulatory programs launched by HITECH may not be sufficient.

In order to foreshadow later chapters of the report, it is useful to engage in a brief discussion of the EHR itself. A first point to convey is that in virtually all of our use cases, the “user” of the data does not need to be, and indeed should not be, scanning through the entire health record. Instead, the user needs to be looking at an application layer that accesses and presents a limited amount of information from a given health record or set of records. We refer to the ability of applications to access and utilize data relevant to a variety of specific tasks as a data-centric approach. Fortunately, data mining and presentation is something that computers, augmented by communications networks and distributed data storage, are very good at. Unfortunately, it is not something that current EHR systems are optimized for. Instead, many of them function as something closer to an electronic version of the paper record, and communication across systems is sorely lacking.

We will argue in this report that to achieve even the more modest goals set out in this chapter will require an infrastructure and a “universal exchange language” that allow data to be shared and communicated for different purposes among diverse EHRs and other applications. We also believe that there is a natural technological approach which will facilitate a move in this direction and which, over time, will also lead to beneficial changes in the way that EHRs are structured. This approach begins with the observation that the best way to manage and store data for advanced data-mining techniques is to break it down into the smallest individual pieces that make sense to exchange or aggregate. We will refer to these kinds of data as “tagged data elements,” because each unit of data is accompanied by a mandatory “metadata tag” that describes the attributes, provenance, 16 and required privacy protections of the data. Modern, networked computers are particularly good at indexing, finding, and retrieving data that are discrete and “close to the surface,” even when the pieces are distributed widely over many computer systems and data-stores. So storing data in this fashion can create an environment in which clinicians can access a patient-centric record tailored for each medical encounter, and in which health organizations, researchers and public health agencies can aggregate data for a broad variety of uses.

We expand on these points in Chapter Four by arguing for an evolutionary transition from traditional EHRs to a tagged data-element model, and a more rapid transition for the more limited purpose of data exchange. In the model we will propose, data can easily be aggregated and de-identified, and data do not depend on a single provider or a single vendor for use. The entities needed to facilitate this type of information-rich environment could be viewed as part of the national health infrastructure, like hospitals and clinical laboratories, regulated, but typically not operated by government entities , allowing data to be drawn safely for uses in multiple arenas. Embracing this outcome is an important and essential step toward leveraging the true power of information technology to improve healthcare.

Conclusion

Information technology, along with associated managerial and organizational changes, has brought substantial productivity gains to manufacturing, retailing, and many other industries.17 Healthcare is poised to make a similar transition, but some basic changes in approach are needed to realize the potential of healthcare IT.

The most significant change is that all healthcare should be organized around the needs and specific characteristics of the patient, not around those of the hospital, doctor’s office, insurance company, or EHR vendor. Medicine has become an information-rich enterprise, and a larger and more seamless flow of information will result in a transformation of care, organized around the patient, wherever he or she may be. The healthcare system will be driven by information and at the same time will generate information that can be used to improve healthcare. The potential for individualized care, higher quality, lower costs, and enhanced safety is immense.

The best way to give clinicians a unified, patient-centric record tailored for each medical encounter is to store, maintain, update, and exchange the data as small, distributed, metadata-tagged elements. The data element indexing and access services needed to facilitate this type of information-rich environment can be viewed as part of the national health infrastructure, like hospitals and clinical laboratories. Embracing and promoting this outcome is an essential step toward leveraging the true power of information technology to improve healthcare.

This chapter’s bottom line

Improved health IT can directly affect, and improve, clinical encounters between doctor and patient, healthcare organizations, clinical research, and the monitoring of public health. For this to happen, we must be able to “disassemble” the information in electronic health records and then “reassemble” it in various ways.

III. Health IT Today

Introduction

Traditionally, electronic records and information technology have played a limited role in healthcare delivery. There are a number of reasons for this, both economic and technological. In this chapter, we describe some of the historical barriers to health IT adoption, and the current Federal initiatives that are beginning to change the health IT landscape. In doing this, we touch on some of the lessons that can be drawn from the experience of early IT adopters, predominantly large integrated healthcare organizations, as well as the historical and current state of EHR technology.

The final part of this chapter discusses nascent attempts to promote data sharing through local and regional health information exchanges. Data sharing and exchange through a national health IT infrastructure is essential to realize many of the potential benefits described in the current chapter. This requires the ability to access, assemble, and present data that are potentially being generated across a range of organizations. This capability is by and large lacking in the current environment. Moreover, current approaches to data exchange and aggregation, which are often bilateral or document-based, do not, in our view, present a clear path to scalable national solutions that would trigger transformative innovation and use of health IT. In this sense, there is potentially a large gap between the current path and the potential for IT to improve health and healthcare.

Historical Barriers to EHR Adoption

Although the promise of EHR systems was recognized decades ago, 18 even today the great majority of physicians rely on paper records and use electronic data mainly for billing purposes. According to the CDC’s National Ambulatory Medical Care Survey (NAMCS, 2009) only 6.9 percent of physicians reported having an extensive, fully functional electronic record system. Only 20 percent reported having even a basic electronic record system. 19 At first glance, this is surprising given that computers and information technology are so completely embedded in most industries. One would be shocked to hear of a leading manufacturer using paper records to track production or inventories, or of a financial services firm relying primarily on faxes and ordinary mail to exchange information with clients and partner firms. Indeed, healthcare providers have long used computers and IT for billing and communication with payers. Why has the broader adoption and utilization of information technology in healthcare been so slow?

At least part of the explanation lies in the organizational and economic structure of healthcare. Most physicians practice in small groups and are reimbursed for care on a fee-for-service basis. Physicians operating in this type of environment cannot easily internalize many of the potential benefits of electronic records and health IT, such as improved sharing of patient information, greater coordination of care, and aggregation of data. 20 They also have little incentive to undertake the substantial investment or money and time to install and adapt to electronic records, particularly when this involves a large fixed cost that cannot be spread across a large number of patients or physicians.

The situation has been compounded by a number of additional factors. Lacking demand from providers, the market has been slow to provide IT products geared toward small organizations. As we discuss below, even the advanced systems geared toward hospitals and large healthcare providers lack capabilities that seem rather obvious, such as extensive clinical decision support, or the ability to easily exchange data with other providers who share responsibility for the same patients. In addition, privacy and liability concerns may be a deterrent for some organizations, or at least for data-sharing initiatives.

Not surprisingly, the healthcare organizations that have adopted electronic health records tend to be large organizations that can shoulder the financial burden of installing customized systems and can internalize the benefits associated with such systems. These systems also tend to have different financial incentives than are prevalent in the broader healthcare system. Some are paid on a capitated basis (a fixed amount per patient per year), so they have an incentive to provide care efficiently and reduce duplication or extraneous services when possible. However, some tens of thousands of small physician practices have also adopted electronic health records. These physician adopters tend to be younger and more technologically savvy than their peers. Below we discuss some of the lessons that can be gleaned from the experiences of these early adopters.

Limitations of Present-Day EHRs

The most commonly cited reasons for not adopting EHRs include the cost of installing and maintaining a system (including both financial and workflow disruption costs) and the lack of perceived benefits in terms of enabling higher quality, more efficient care. A frequent complaint is that electronic health records do not make the physician’s job easier. In particular, few EHRs deliver the intelligent cognitive or decision support that one might hope for. Even where decision support is available, physicians often do not take advantage of it. This section describes some of the cost and “usability” concerns around current EHR systems, and how a robust technology market could alter the situation.

Workflow Disruption and Documentation Burden: Present-day EHRs often require a substantial increase in physician time devoted to documentation. Physicians may complain that they are spending extra hours to type in orders and notes from patient visits. Healthcare systems can hire staff to enter data into the EHR during the office visit, but this is cumbersome and not economically feasible for small practices. Speech-to-text transcription systems exist, but so far they are useful only for specialties with circumscribed and highly specific vocabularies. Physicians often are left to design their own “templates” to reduce the data entry burden. Streamlined data entry via checklists, customizable templates, and other structured means is an area of opportunity for software and systems designers.

Lack of Decision Support Functionality: Many EHRs were developed as electronic facsimiles of existing paper records. They were created largely without the assistance of experts in human factors and design and they do not fully leverage the ability of computers to retrieve and analyze data to provide useful guidance, safety checks, and decision support. There have been some useful advances in this area, such as modules that cross-check for drug interactions, provide warnings about allergies, or generate reminders for preventive services. Nevertheless, this is an area ripe for innovation. Recently, the National Research Council proposed a comprehensive research agenda for the development of new approaches to EHRs that would provide cognitive support for clinicians and draw on human factors engineering. 21 As just one example of the potential, research over the past decade has raised the possibility that diagnostic errors may be far more extensive than therapeutic errors. As much as 15 percent of all diagnoses may represent clinically significant errors. 22 Clinical decision support that could assist physicians in making effective diagnoses might represent a significant opportunity if it could be integrated with the electronic record.

Technology-Enabled Diagnoses
Imagine a patient with the history of hepatitis C who presents to a primary care physician complaining of an itchy rash. When the physician dictates or types the words “new rash” into the record, the record instantly reminds the physician that hepatitis C has associations with certain diseases, including a condition known as lichen planus that triggers an itchy rash. The decision support system can remember all of the associations between patient clues and medical diagnoses. It then becomes the job of the clinician to navigate the evidence and assess the situation with the richer information that is instantly available. In another example, imagine a veterinarian presenting with new symptoms. The decision support engine would immediately display diseases associated with veterinarian exposures. Such functionality is feasible today, but the burden and costs of deploying the record, and the use of “first generation” decision support by vendors, have hindered critical innovations needed to reduce diagnostic and therapeutic errors.

 

Lack of a Platform for Innovative Applications: Many healthcare systems use enterprise systems customized to fit the needs of the particular provider. Other organizations rely on idiosyncratic “legacy” systems that often were initially used primarily for billing or pharmacy refills. Neither type of system provides an open and robust platform for software developers to build applications to improve data entry processes, provide decision support, or other functionality. The fact that existing systems often use record formats based on messages and page formats also makes it harder to access, retrieve, and analyze individual data elements. In addition, existing systems typically are not interoperable, so that data cannot easily be shared or aggregated across organizations. Although we discuss below some new technologies that may improve this situation, these limitations stand in the way of innovation that could help to alleviate some of the usability problems described above.

Concerns about Security and Privacy: Finally, a major concern with healthcare information, as with financial and other highly sensitive personal data, involves security and privacy. The Privacy and Security Rules issued under the Health Insurance Portability and Accountability Act (HIPAA) of 1996 provided the first broadly applicable Federal protections for health information. These Rules, along with multiple state laws, create a complex network of laws and regulations that address patient privacy and consent for the use of identifiable personal health information. The resulting regulatory framework, in current implementations, imposes significant costs on healthcare providers. Moreover, although HIPAA has usefully raised awareness of the need to protect health information, the Rule has become obsolete in many ways given advances in technology. A recent Institute of Medicine (IOM) report concluded that the law needs to be fundamentally reconsidered to reflect new information technologies and to enhance personalization and the quality of care. 23 Chapter Five expands on this point and discusses how emerging capabilities in metadata, encryption, and identity systems enable promising new ways to protect Internet-based information that were not envisioned when HIPAA was passed.

Lessons from Early Adopters

The healthcare organizations that have adopted electronic health records are mainly large integrated health systems that can internalize the benefits of EHRs as well as fund the initial investment and ongoing maintenance. Although these organizations are not necessarily representative of the broader healthcare system, their experience provides some important lessons.

The Kaiser and VA Experience

Two of the Nation’s largest healthcare systems—the Veterans Health Administration (VHA) medical system and Kaiser Permanente—were among the earliest adopters of integrated EHR systems.

The VHA’s adoption of its VistA system is credited with playing a major role in enabling the Nation’s largest integrated health system to provide a highly regarded level of information technology supporting better care. 24 For example, the use of electronic reminders and performance measurement to improve pneumonia vaccination rates probably saved the lives of 6,000 veterans with emphysema. 25 VHA’s vaccination rate became the national benchmark as pneumonia hospitalizations were halved even while VHA’s patient population doubled—all while reducing taxpayer costs by $40 million. 26 VistA also has enabled the VHA to reduce medication errors to a rate of 7 per million prescriptions written, well below the national average of 1 error in 20. 27 VistA has been made available in open source but lacks the flexibility of other commercial systems, so it is not widely adopted except by some safety net organizations. It currently does not connect easily with other systems or with personal health records (PHRs, discussed below). Nor is it strong at creating searchable databases that web-based models promise. A descendent of VistA, the Armed Forces Health Longitudinal Technology Application (AHLTA), contains medical records of nearly 10 million military service personnel and their families. However, VistA and AHLTA have diverged to the extent that they are no longer cross-compatible.

Kaiser Permanente’s HealthConnect system is based on the Epic EHR, the most widely used of current vendors. Kaiser’s implementation connects all 8.6 million Kaiser Permanente members, over nine states and the District of Columbia, to 14,000 physicians 28 in Kaiser’s 431 medical offices and 36 hospitals. 29 Physicians can retrieve data on any patient who has received services within their network. Kaiser has used the system to improve preventive care and the management of chronic conditions. Specialists are alerted if a patient is overdue for preventive screening (such as mammography), and often the test can be scheduled for that same day. Kaiser’s system also produces quality measures and feedback for physicians, medical centers, and hospitals, 30 and is able to aggregate population-level data to track adverse events and trends. It was the first to identify the link between Vioxx and increased risk of heart attack and to remove the drug from its formulary.31 It can also track early cases, predicting epidemics, such as influenza, across its offices.

An additional feature of Kaiser’s IT system is that it allows patients to access online data and communicate with their physicians using secure messaging. More than 3 million Kaiser patients are registered for this feature, and over 100,000 access the system on a given day. 32 Kaiser attributes this part of the system with improving both quality and efficiency of care delivery. Findings from a 2009 study showed that patients’ use of secure messaging and scheduled phone “visits” enabled by HealthConnect led to a 26.2 percent decrease in total office visits over four years. 33 Over the same four years, most measures of healthcare effectiveness and patient satisfaction improved significantly. Despite this useful functionality, however, Kaiser’s system is a closed one that does not communicate easily with other systems or networks. Only recently have Kaiser and the VA begun to collaborate to share data about patients who use both systems, and efforts so far are limited to one geographic area (San Diego). Kaiser also is exploring further interactions with health information exchanges in some regions.

Experiences at Other Organizations

The experiences of some other health systems help to illustrate the use of EHRs and the variety of issues involved in deploying IT in very different organizational and economic environments. In each of them, one can see the advantages to the patients within that system, but also the limits to models that are enterprise based rather than based on Internet technology.

The Palo Alto Medical Foundation (PAMF) is a highly-regarded multi-specialty group in Northern California that is affiliated with Sutter Health. In 1999, it deployed an Epic electronic record system similar to Kaiser’s. 34 Physicians can pull up notes written by other PAMF physicians, access lab and imaging results, and send messages to patients. Physicians and administrators also have access to population-level quality measures. PAMF has used IT to alter the scheduling system so that many routine visits are scheduled just one or two days in advance. Because PAMF does not own its own hospitals and recently merged with two other large groups in the Sutter system, it has been attempting to make its systems compatible with its partners and integrate data fully across its component groups. Even today, however, it has not achieved full integration.

Geisinger Health System is a prominent health system in central Pennsylvania that encompasses both Geisinger’s own health plan and affiliated clinicians. Geisinger has extended its EHR to include the private practice physicians in the community, allowing them to access information about their patients hospitalized at Geisinger Hospitals, and allowing hospital-based physicians to get access to records from the community practitioners. Geisinger maintains a corporate research center that aggregates data from all the providers in the system to produce clinically based measures of quality of care, help physicians establish benchmarks, and monitor quality for external reporting. The distributed aspect of Geisinger’s system involves additional challenges such as the standardization of data elements and data systems that are integrated into central data repositories. It has been easier for Geisinger to do this because they it is essentially the sole hospital provider in a large geographic area, and it does not face the competitive forces that might deter community physicians from signing onto a EHR system that only provided information from one hospital system and not others where their patients might receive care. 35

Lessons and Challenges

The experiences described above demonstrate how health IT can be successfully deployed and used, but they also reveal some of the challenges that remain.

A first point is that each of the organizations above has developed a system specifically tailored to its own needs. Each system has been expensive to deploy and requires substantial resources to maintain, as well as a significant and sustained effort to extract and utilize the information for organizational and care process improvements. While the organizations we have described also realize corresponding benefits, this kind of enterprise solution is inappropriate for small physician groups. Also, the patchwork nature of organizational solutions does not provide a scalable model for the effective flow of information centered around a patient, wherever that patient may be, or for a market for innovative electronic information solutions to everything from patient empowerment, to patient specific clinical decision support, to real time aggregated clinical data for robust quality assessment and public health purposes.

Second, the systems we have discussed are not mutually interoperable, meaning that patient information cannot easily be shared between providers with different systems or in different networks without a significant up-front investment to make this possible. Interoperability is important to improve and coordinate care delivery. Currently in the United States, most patients receive care from a variety of providers. One recent study found that the typical Medicare patient receives care from seven physicians spread across four organizations in a single year. 36 The lack of interoperability at the network level means that physicians do not easily have access to complete records for patients, nor does there exist a “master record” that is complete at any point in time. Chapter Six goes into more detail about the economic incentives for interoperability and how they can be better structured in the future.

Health Information Exchanges

Data exchange and aggregation are central to realizing the potential benefits of health IT. We have already seen the limitations of current systems in this regard. In this section, we describe some nascent efforts to create health information exchanges that allow for a degree of local and regional data sharing. We also discuss why these exchanges do not provide an obvious or immediate path toward a national health IT infrastructure.

Health Information Exchanges are entities often built on a series of often bilateral legal agreements between different, often proprietary information systems to be able to share certain kinds of data. Many HIEs were developed for the purpose of aggregating health measures at the community level, such as those supported by the Robert Wood Johnson Foundation (RWJF) in its Aligning Forces for Quality initiative. 37 Within this RWJF-funded group and in other instances, these HIEs have been termed regional health information organizations (RHIOs). Originally conceived in response to the fact that physicians, hospitals, insurers, and other healthcare entities have been reluctant to share data beyond their corporate boundaries, they are typically state or regional entities set up to facilitate health information exchange in a region or market area. Their primary responsibility historically has been to establish “trust relationships” among these entities in order to enable the broadest possible health data exchange. They also facilitate the governance, data-sharing agreements, scope, technology, and financial models needed to support that exchange.

Conceptually, HIEs might be considered the mirror image of the enterprise EHR model. Their purpose is to locate all currently available electronic information on a patient from any source, in that community or region, and present it in an integrated format to any physician who is authorized to view it. Current electronic sources for these data are national and regional laboratories, pharmacies, and clinical claims data. The physician sees, therefore, information from other physicians caring for their patient, records on medications, lab test results, and, as it is made available, copies of hospital discharge summaries and eligibility and claims status. However, HIEs have been limited by the administrative burdens of obtaining data-sharing agreements at every practice and every hospital or nursing home. They also have been hampered by a lack of financial incentives to develop more coordinated and efficient use of resources (including information resources), as described later in this chapter. In addition, the level of clinical detail in these contractual agreements does not match the richness of information available from a clinical record. Nevertheless, they do provide the treating physician with the information that generally is most important to know about a patient, which can make a very big difference in patient outcomes. As regards privacy and security, HIEs demonstrate the reluctance of providers to share data with users they do not know—generally, users outside the communities in which providers reside.

It is important to note that participation in an HIE does not require the physician to participate in any proprietary system or to invest in a fully functional EHR. The information summary for a patient can be presented through a browser or computer screen “dashboard” in the physician’s office, faxed, or deposited into an EHR if the physician has one. Most HIEs provide a portal through which physicians can “plug into” an EHR to view information. While ultimately physicians would be expected to exchange, not simply view, patient health information, some have argued that HIEs provide an important “on ramp” for small practices and independent physicians and their staff to integrate the use of health IT into their practices prior to full EHR implementation.

Nevertheless, HIEs have drawbacks that make them ill-suited as the basis for a national health information architecture. One major concern is their durability. As a Federal strategy to support health information exchange, HIEs began in 2005-2007 with a small amount of Federal demonstration funding to states; a few also received private grant support. Barriers to their success were substantial, including complex governance, the lack of a sustainable business model, continuing provider reluctance to share data, the lack of readiness to accept and use data in many organizations and practices, and technical limitations in knitting together the many disparate IT systems within most medical communities. As a result, only a handful of the original HIEs have managed to establish exchanges that functioned beyond the initial funding and limited scope of their initial pilots. Recent legislative support for new state-designated HIEs and requirements for information exchange and reporting will clear away a few of these hurdles, but the lack of a clear business case for communities to sustain HIEs over time remains a daunting challenge.

Interoperability also remains a concern. HIEs are subject to differing regional and state-based governance frameworks. Also, limitations result from a lack of standards to connect multiple proprietary systems. There is no guarantee that a patient who has received care in two or three hospitals, has recuperated in a nursing home, and is now receiving home care and seeing several different specialists will necessarily have all her data available to a treating physician during an office visit or at an emergency event such as a fall and hip fracture.

New and Emerging Technologies

A number of new technologies offer significant potential for addressing the challenges described in the preceding sections. In this section, we describe three of them: cloud-based EHR products that are suitable for small providers, personal health records aimed at patients, and middleware products designed to make legacy systems interoperable. This discussion provides background for the next chapter of the report, which explains the technology issues associated with creating a health data platform that can facilitate innovation and broader transformation in healthcare.

“Cloud-Based” Technologies for Small Providers

As discussed above, the enterprise solutions used by early adopters are not obvious solutions for the smaller healthcare organizations that still make up a large fraction of the U.S. healthcare system. Small organizations need low-cost off-the-shelf products and services that can allow them to capture the benefits of health IT without having to undergo a costly customization and maintenance process. The incentives created by HITECH have already led to substantial innovation and competition in this area.

The new products often rely on cloud-based technology that allows software to be run and data to be stored on remote servers. The cloud model reduces individual maintenance responsibilities and allows even small organizations to benefit from the scale economies in data storage and processing. In this model, much of the responsibility for maintaining security is shifted from the small health care organization to the cloud-based service provider. It is also advantageous from the perspective of promoting data exchange because data from many organizations are stored and processed in a more uniform way. In the future, more extensive cloud-based solutions and services are likely to provide small or under-resourced practices with everything from general practice management to advanced decision support to analytical tools for public health reporting and basic clinical research.

Personal Health Records

PHRs are patient-controlled repositories of individual health data. They may contain excerpts or summaries of physician records generated from clinical encounters, claims data, lab and imaging results, prescription information, and (importantly) patient-entered data. Some PHRs, such as those offered by Dossia, Google, and Microsoft are available via the web, while others are software packages that allow consumers to store and maintain data on personal computers, mobile phones, or other digital devices. PHRs can include functions such as decisions support, appointment making, referral requests, medication refills, and bill paying. Patients also can contribute their own data to the PHR and can determine what data will be accessible to clinicians and others.

To date, most PHRs are not standards based, and few support an easy way to transport records among different EHR products. However, Google and Microsoft, the two largest vendors of web-based PHRs, recently agreed on mechanisms to enable the free exchange of information between their respective PHR systems, and others may follow.

An important feature of PHRs is that they are patient controlled and “travel with” the patient. In this sense, they represent a route to interoperability. A patient could schedule a visit with a new physician, or a specialist, and allow access to his or her PHR. PHRs can also allow increased patient involvement in their own healthcare by enabling them to input their own data, research health issues, and potentially meet and share information with patients who have similar conditions. Of course, one question about this type of technology is how much interest patients will actually have in utilizing these capabilities. They seem to have particular promise for patients with chronic conditions.

Data Aggregation “Middleware”

An important feature of today’s environment is that there is relatively little standardization in the health data captured and stored by different providers of healthcare services. Although a great deal of data already exist in the form of claims data, prescribing information, lab and imaging results, and clinical records, much of this data is trapped in different, incompatible databases. The last few years have seen the emergence of new middleware products designed to extract data from disparate legacy systems and put them in a compatible format. Examples include products and companies such as dbMotion, ICA CareAlign, Medicity MediTrust, Microsoft Amalga, Oracle HTB, and Orion Health. These technologies can play a role in making the transition from the current environment with little interoperability and document-based data exchange to an environment where data can be easily accessed and queried and assembled for a broad variety of uses.

The HITECH Act and Shifting Incentives

The discussion so far has highlighted barriers to the effective use of information technology in healthcare. Recent legislation, however, has started the Nation on what is potentially a new trajectory. In 2009, the HITECH Act (part of the American Recovery and Reinvestment Act, or ARRA) authorized expenditures on the order of $20 billion (with estimates in the range $9 billion to $27 billion) over five years to promote the adoption and use of EHR technologies that would be connected through a national health information network. The legislation sets forth a plan for the “meaningful use” of health IT to improve the quality of care and enable changes in delivery systems essential to healthcare reform.

The HITECH Act attempts to create incentives for all hospitals and eligible providers, not just those associated with large systems, to adopt and use electronic information. A centerpiece of the Act is to put in place strong financial incentives for hospitals and physicians to adopt and meaningfully use electronic health records. Physicians who adopt electronic records by 2014 can qualify for Medicare bonus payments of up to $44,000. Beginning in 2016, physicians who have not adopted electronic records will be penalized in the form of reduced Medicare reimbursements. Similarly, Medicaid providers can receive up to $63,750 over the five years. These payments and penalties depend on the provider meeting the requirements for meaningful use.

The definition of meaningful use under HITECH involves both ONC and CMS, but CMS is the principal rule-making body since payment will be linked to the reporting of meaningful use measures. The statute leaves CMS broad discretion, requiring only that the definition include e-prescribing, the ability to exchange information with other healthcare providers to improve care, and the reporting of clinical quality measures to CMS. With input from several Federal advisory committees, CMS has proposed to phase in meaningful use criteria in three stages. Stage 1 criteria, to take effect in 2011, focus on electronically capturing health information in a coded format, implementing decision support, sharing information with patients, testing the ability to exchange information, and initiating the reporting of clinical quality measures to CMS. Stage 2 criteria, to take effect in 2013, would require more robust exchange of information and other high value uses of EHRs. Stage 3 criteria, to take effect in 2015, would require physicians to demonstrate the use of EHR technology in ways that improve the outcomes of care. The broad goal is to gradually acclimate providers to workflow changes and practice improvement opportunities that, ideally, will accompany the adoption of technology.

Responsibility for implementing many other parts of the HITECH Act resides with the Office of the National Coordinator, discussed in the introductory chapter. In particular, ONC is responsible for developing policy guidance and a broader future vision for health IT. As we discuss below, it has already begun a series of important initiatives to further IT innovation and standards in a variety of areas. It also must work together with CMS and other Federal agencies. Indeed, as we now discuss, the division of authorities and responsibilities poses significant challenges.

Opportunities and Challenges for ONC and CMS

In the short time since the HITECH Act was signed, ONC has moved forward on several important initiatives. Perhaps the closest to this report is ONC’s recasting of the Nationwide Health Information Network project. The NHIN is composed of standards and services that enable secure exchange of health information over the Internet, combined with a strong policy and trust framework that enables organizations to share health information with strong consent and governance to improve healthcare delivery while strongly protecting privacy and security. As we elaborate in Chapter Four, we believe that this initiative could benefit from a more aggressive focus on a universal, extensible exchange language and the development of associated national infrastructure.

The ONC has also moved forward in the important area of clinical decision support and enhancing usability of electronic record systems. With AHRQ and the Office of the Secretary, it has established a Federal “collaboratory” whose members now number more than 150 across more than 15 Federal agencies. The collaboratory has developed an inventory of federally supported CDS efforts, promoted sharing of best CDS practices, and identified needs and strategies that have resulted in new projects sponsored by ONC, AHRQ, and other agencies. Notable among these new projects is an effort to develop generalized representations of important medical logic (rules) that enables these rules to execute in the same way even if installed in different vendor systems. The ONC also has awarded a contract to the RAND Corporation to advance CDS. Work performed under the contract will advance the Nation toward a CDS knowledge repository, including the implementation of best practices and tools for sharing CDS interventions. It also will address the “alert fatigue” problem (the problem of too many inessential “pop-ups”) by, for example, identifying those drug-drug interactions that are of highest priority. Another ONC initiative aimed at improving EHR usability is a collaboration with the National Institute of Standards and Technology (NIST) to develop usability testing programs that may become a part of EHR certification.

In addition to these efforts, ONC administers HITECH funding for Strategic Health IT Advanced Research Projects and has awarded four cooperative agreements totaling $60 million. An award to the University of Illinois at Urbana-Champaign addresses the challenges of developing security and risk mitigation policies and the technologies necessary to build and preserve the public trust as health IT systems become ubiquitous. An award to the University of Texas Health Science Center at Houston addresses the challenge of harnessing the power of health IT to integrate with, enhance, and support clinicians’ reasoning and decision-making, rather than forcing them into a mode of thinking that is natural to machines but not to people. An award to Harvard University focuses on the development of a platform architecture that will facilitate substitutable applications—enabling the equivalent of the iTunes App Store for health—as well as supporting the electronic exchange and use of health information in a secure, private, and accurate manner. And an award to the Mayo Clinic College of Medicine focuses on strategies to make use of data that will be stored in EHRs for improving the overall quality of healthcare, while maintaining privacy and the security of the data.

CMS plays a rather different, yet pivotal, role in the national health IT effort, in large part due to its broader centrality in the Nation’s healthcare system. As the Nation’s largest payer, CMS has substantial leverage over healthcare providers. For example, it is often argued that the fee-for-service payment system used by CMS tends to reward volume over patient-centered goals like coordination and personalization. As noted above, some of the leading adopters of health IT, such as Kaiser and the VA, are systems with very different financial structures. Recent healthcare legislation (the Patient Protection and Affordable Care Act, or PPACA) supports many initiatives to reform healthcare payment and to advance CMS projects such as Medical Homes and Accountable Care Organizations, which aim to create incentives for coordination and more efficient care. As we discuss in Chapter Six these types of innovations can significantly complement health IT efforts.

Even more directly related to EHR adoption and use, CMS exercises substantial influence over the type of data that providers must collect. For instance, payment reforms based on quality of care measures require providers to collect and report these measures. This type of data plays a key role in current attempts to define meaningful use, where the idea is to create consensus “measures of quality,” the collection of which can be translated into requirements for “meaningful use” incentive payments.

One concern with this approach, however, is that most quality measures depend on strict specifications that limit the flexibility to describe complex care coordination and functional outcome goals. Indeed, at this point, most are related only to individual specific conditions. The reason for this is that many of the validated, existing quality measures reflect medicine’s traditional focus on treating particular illnesses, rather than on care coordination and health maintenance. Furthermore, most EHRs were designed around billing codes, not around rich clinical information that would give a more patient-centered view of the context and the true outcomes of care, especially as it occurs over longer periods of time. Legislation allows the Secretary of HHS to approve alternative pathways for these CMS payments. Thus, if more robust clinical data were available and easier for a sophisticated system to gather and report, the use of these data ought to be encouraged.

A second concern is the ability of CMS to receive and process any complex forms of clinical data. The historically underfunded IT infrastructure of CMS has not kept up with the constant new legislative demands for new programs, especially those requiring quality-of-care data for numerous value-based purchasing programs. The culture and structure of CMS, and the demanding time frames of each legislative mandate, have led to multiple separate data platforms and different administrative approaches to each of them. Thus, even within CMS, it is not currently possible to aggregate data, and (for example) physicians are required to double-enter specific codes to be eligible for quality incentive payments. Through certification standards for EHRs, ONC is trying to require that EHR vendors supply a short cut for physicians to do this, but even if this occurs, the specific data elements will not provide a full clinical picture of patient care, and will therefore provide limited constructive feedback to providers about areas for improvement and about the value of the aggregated data.

CMS has not been able to invest in the infrastructure needed for the enormous scope of its growing database and quality-of-care requirements. For example, a 2002-2003 data modernization plan that would integrate data across CMS programs was not funded until 2006, and now proceeds only slowly and incrementally. CMS recognizes that this work is far from complete. In planning stages, CMS has high level concepts for a transformed and modern payment system and an Enterprise Data Environment that could, if appropriately implemented, contribute to the goals of this report. However, lacking funding, implementation work has been stalled. Congress now recognizes that CMS must upgrade its own IT systems in order to handle clinical and other performance information and to ensure program integrity, and it has begun to authorize these important upgrades. Notably, PPACA charges CMS to accelerate work on the CMS Integrated Data Repository to incorporate into the model data from all Federal health programs. It also directs CMS to enter into data sharing agreements with the Department of Defense, the VHA, and the Social Security Administration.

While we have not investigated these issues further, it seems likely to us that a complete overhaul of CMS’s IT infrastructure will be needed in the foreseeable future, not because of future health IT requirements but simply for it to comply with existing legislative mandates. The National Research Council has recently begun work on a study of the CMS information system capability, with a preliminary report due by December 2010 and a final report due at the end of 2011. Because CMS’s operational mission of payment processing must proceed without interruption, and because it is starting from a technologically outmoded base, it seems likely that any rebuilding of CMS’s infrastructure will be a difficult and lengthy process.

This is an ideal time for the leadership of CMS to assess the overall capability of CMS to take advantage of modern computing and to set in place a plan to upgrade systems, break down silos, and reduce unnecessary barriers to state-of-the-art computing capability. Federal IT projects frequently incur cost overruns and schedule slippages, 38 and it will be a significant management challenge for CMS to avoid the fate of other government IT modernization and software development projects.39, 40 There is clearly a danger that rapid and otherwise achievable progress in health IT, as envisioned by ONC and (even more aggressively) by this report, could be forestalled or derailed if it becomes tied to CMS’s formidable IT challenges. 41 This must be avoided.

Conclusion

The state of health IT today can be summed up as a mix of “the good, the bad, and the ugly.” This diversity, and especially the fact that perhaps 80 percent of physicians still do not use electronic records at all, except possibly for billing functions, creates a dilemma. Given the difficulty of bringing the healthcare system forward into the computer age, should we focus on small incremental steps? Or, having seen the remarkable adoption rates and advances of Internet-based technologies in other sectors, should we push for a more radical advance that risks leaving some providers behind?

Fortunately, there is a bridge between these two extremes. It is the fact that the Internet-based technologies create a platform for “disruptive innovation,” meaning innovations that upset the status quo and can broadly expand markets. Cloud-based technologies and PHRs are potential examples of disruptive technologies in health IT. These types of technologies might allow the 80 percent of physicians who are non-digital to leapfrog some of the existing limitations of EHR systems directly into more modern technologies. Indeed this is precisely what we want to happen, and it is a direction in which ONC and CMS could concentrate their efforts.

In setting up a roadmap for how we might move in this direction, it is useful to specify a clear set of mid-term goals. These should include:

1. Universal access by clinicians and patients to the current frontier of EHR functionality.

2. A robust platform for developers to create user interfaces, decision support, storage, and archiving services that will be broadly available to end-users and will not require major capital investments.

3. Seamless, user-transparent, cross-organizational data exchange.

4. Innate, strong privacy protection on all data, both at rest and in transit.

5. Efficient means for the aggregation of de-identified data for public health and research purposes.

As already indicated in Chapter Two, we believe that there is at least one technical approach that can achieve all of these requirements. The approach that we favor, based on the exchange of metadata-tagged data elements, is described in detail in the next chapter.

This chapter’s bottom line

Despite success stories from some early adopters, the current level of IT use in healthcare is uninspiring. 42 Recent initiatives, particularly by ONC, are shifting the incentives and may stimulate substantial EHR adoption. But a substantial advance and concentrated focus are needed to develop a scalable, national health IT infrastructure. New technologies can assist in taking the required steps.

IV. Technology for an Integrated Health IT Ecosystem

Introduction

The current health IT landscape is dominated by enterprise systems based on proprietary formats. These systems lack ability to communicate and aggregate health information in the ways needed to serve patients, doctors, and researchers. The systems have been designed primarily to enable point-to-point communication of administrative information rather than clinical data. Importantly, the nature of current systems makes it difficult for innovators to develop new tools to improve the use of health information. There are few policies or governance models to drive innovations, such as research, advanced clinical decision support, or benchmarking. In short, there is no fuel for an ecosystem of economically self-sustaining healthcare innovation.

The overarching goal is to have a national health IT ecosystem in which every consumer, doctor, researcher, and institution has appropriate access to the information they need, and in which these groups are served by a vibrant market of innovators. At the end of the previous chapter, we listed a set of technical and market-related requirements for enabling this overarching goal. Here, we look at several possible technological approaches and describe in some detail an approach that, we think, has the greatest likelihood of rapid forward progress.

Earlier Models for Enabling Data Exchange

Over the last 20 years or so, an era dominated by vertically integrated, proprietary EHRs, one approach has been to seek to create standardized health records. Because the medical system has long relied on filling in paper records, it was natural to assume that exchange or reuse of data would be impossible without establishing standardized record formats that would be comparable across providers. However, we believe that any attempt to create a national health IT ecosystem based on standardized record formats is doomed to failure. First, there is too much diversity and incompatibility for any kind of a priori standard to emerge. With so many vested interests behind each historical system of recording health data, achieving a natural consolidation around one record format for any particular subset of data would be difficult, if not impossible. Second, systems based on fixed records are inherently limited in their functionality. Consider, for example, a health record in which all types of blood test information are always stored. When a new type of blood test is developed, it is difficult to expand the record to include it. Moreover, it is difficult to exchange only parts of such an electronic record according to a patient’s choice (for example, blood glucose measures but not HIV status).

A second approach to health IT, spurred by the emergence of the Internet, has focused on serviceoriented architecture (SOA) as a way to solve the problems inherent in standardized record formats. SOA essentially involves using software policies, practices, and frameworks to enable one user to access sets of “services” on another party’s computers and data. 43 For example, two hospitals, using two different systems, might create bilateral arrangements that enable them to run “services” on each other’s systems to execute transactions or access data. The approach could be expanded to small networks, and even to networks of networks.

As an analogy, one might consider two libraries with completely different systems for filing books. Each library’s users have no idea how to find books in the other library. But if each library sets up a “service desk” with an actual librarian, then the other library’s users can get what they need by lining up at the service desk for assistance. This analogy also makes clear one of the big limitations of SOAs, namely scalability. A library’s own users can all be looking for books on the shelves at the same time; but users from the other library must queue for the librarian “service.”

There have been extensive efforts to implement the above approaches in local and regional HIEs that seek to connect multiple organizations. By 2009, there were more than 190 HIE initiatives in the United States—although only about one-third were fully operational. 44 These HIEs report lower costs, improved outcomes, reduced staff time spent on process-oriented work, and increased data exchange—demonstrating the benefit of health information exchange. But despite these benefits, these approaches fall far short of what is needed. Most HIEs are based on standardized record formats or integrated care systems that cannot readily scale. Others link a range of proprietary systems. If a patient moves between two hospitals even within an HIE, critical tests done at the first hospital must often be repeated.

Most HIEs face the administrative burden of requiring adoption of legal agreements at each provider organization to share data. In addition, HIEs that began as pilot projects do not appear to be spreading or scaling up beyond their initial scope because they were launched without significant attention to long-term business models, a problem that the meaningful use incentives may not overcome. Most HIEs, moreover, are not currently interoperable across regions and markets to other HIEs, and thus remained closed and proprietary even as patients seek and require care outside their confines. 45 Because each HIE system is different, there is little incentive for entrepreneurs who make middleware and other innovative tools to serve this marketplace.

While such systems can surely be incrementally improved, we believe that such approaches will not solve the fundamental need for data to be universally accessed, integrated, and understood while also being protected. In a sector as fragmented and rapidly evolving as healthcare, we believe it is impossible to build a national implementation of SOA solutions and directories that could be used and scaled indefinitely into the future. (To draw a loose analogy, the approach is like trying to enable free trade among hundreds of entities by negotiating a huge number of bilateral trade agreements. Or it is like trying to promote dialog among speakers of a thousand different languages by training one million translators, each knowing a pair of tongues, instead of enabling them to speak a common language. The idea is laudable but impractical.) Moreover, the approaches will not overcome the barriers to entry for innovators wishing to develop new solutions. We believe that a steady supply of such innovators in the ecosystem is essential for increasing quality and decreasing cost.

Universal Exchange Using Metadata-Tagged Data Elements

The best way to achieve a national health IT ecosystem is to ensure that all electronic health systems can exchange data in a universal exchange language. The systems themselves could be designed in any manner desired — they could accommodate legacy systems that prevail or new recordkeeping systems and formats. The only requirement would be that the systems be able to send and receive data in the universal exchange language.

We believe that the natural syntax for such a universal exchange language will be some kind of extensible markup language (an XML variant, for example) capable of exchanging data from an unspecified number of (not necessarily harmonized) semantic realms. Such languages are structured as individual data elements, together with metadata that provide an annotation for each data element.

With some risk of oversimplifying, let us give an example. Imagine that an elderly patient has lived in several different cities and, over the years, has had mammograms done at various hospitals and clinics. Her physician now needs to retrieve images of her breast tissue over the previous decades to determine whether a current lump is of concern. In a health IT ecosystem where tagged data elements make up a universal language, the data elements the doctor could retrieve about this patient would include the mammograms themselves from all of the various places the patient has sought treatment regardless of provider network, geographic location, or whether the patient remembers them. The physician would be able to securely search for, retrieve, and display these privacy-protected data elements in much the way that web surfers retrieve results from a search engine when they type in a simple query.

What enables this result is the metadata attached to each of these data elements (mammograms), which would include (i) enough identifying information about the patient to allow the data to be located (not necessarily a universal patient identifier), (ii) privacy protection information—who may access the mammograms, either identified or de-identified, and for what purposes, (iii) the provenance of the data—the date, time, type of equipment used, personnel (physician, nurse, or technician), and so forth.

Most of the time, the metadata will not be needed by the physician; this information will be invisibly in the background. Occasionally, as in the case of a false positive or false negative in a particular image, the physician may want to dig deeper: The metadata will be there.

The metadata will also be important for researchers who may have access only to de-identified data. They might use it, for example, to determine whether a certain type of imaging equipment for breast cancer is yielding excessive numbers of wrong diagnoses. This could result in improvements or recalls of particular devices and improvements in software.

Data Element Access Services

In the example above about retrieving multiple mammograms, we assumed more than simply a universal exchange language. We also assumed the existence of certain national infrastructure for finding health data, and for controlling access to it. (Importantly, though, we have not assumed a national repository for storing health data, which would be a more difficult and politically problematic issue.) We call this infrastructure, collectively, data-element access services. The services would include those associated with crawling, indexing, security, identity, authentication, authorization, and privacy. As proposed, these DEAS and their components would have no right to use the data being exchanged; in fact, they would probably not even see the data. 46 Rather, they would act much like today’s web search engines, but with additional levels of responsibility for exposing only those data elements authorized by applicable privacy rules and policies (including a patient’s persistent privacy choices) and only to authorized, authenticated users. A patient would have the right to restrict the types of data elements indexed at all, or could opt out of the DEAS completely (although such a choice might negatively impact that patient’s future care). We discuss privacy protection and security in more detail in Chapter Five.

Today, when a user views a web page, the data that make up the various parts of the page (text, images, ads, audio, video, etc.) are dynamically aggregated in real time from numerous computers in a range of physical locations and are then presented to the user as a single logical entity: the web page being viewed. The individual elements are not routed through any central server or repository. Rather, a set of access services enables the browser to query many distant computers simultaneously. Similarly, for health IT, a query submitted to the data-element access services would result in the seamless, dynamic aggregation of all the data requested. For example, a doctor’s request for patient information could involve an indexing system identifying all the physical locations on the network of the data; real-time aggregation of the data; and analysis, translation, and presentation by the software application that the doctor is using.

The health IT ecosystem we envision does not require the existence of a uniform patient identifier. Instead, it could use associations of intrinsic patient-related information to link the appropriate data to specific patients. This method is used now to create patient record locators within local closed systems and regional health exchanges, but as employed today, it can be plagued by human error. 47 Since an automated system can use many more than the two factors (such as name and birthdate) now often used, it can be correspondingly more accurate. 48 Indeed, “identity resolution” is an established technology, with commercial offerings available. 49 For greater accuracy and convenience in the record-keeping associations, some patients (e.g., those named “John Smith”) might elect to index their records by an email address or a reference to a personal health record account, but this would be optional.

How should DEAS be brought into existence and operated? There are several viable options: Individual states (or self-formed groups of states) could establish and operate DEAS. Federal funds might be used in the manner of a “race to the top,” to support the best state’s proposals, or to create an additional interoperating and intercommunicating DEAS for use by Medicare providers. DEAS could be established in large health delivery networks (including those operated by the Federal Government, such as the Veterans Administration). They could emerge from a more aggressive push toward achieving interoperability among existing HIEs. Or, their growth could be left to the private sector, perhaps seeded by some start-up funds in response to requests for proposals.

As a matter of engineering, fewer DEAS providers is better, since communication between DEAS in response to queries is an additional overhead, but this must be weighed against socio-technical, governance, and policy forces favoring a more distributed network of DEAS.

In any case, all DEAS would need to be interoperable and intercommunicating in conformance to a single Federal standard, and would need to be audited for compliance with privacy and security policies. In response to a HITECH mandate, ONC has already begun a process for establishing governance of the NHIN. 50 This process might also explore how best to operate DEAS.

Advantages of the Tagged Data Element Approach

Because of its multiple advantages, we advocate a universal exchange mechanism for health IT that is based on tagged data elements in an extensible markup language. If there were another equally good solution, it should also be considered; we have collectively been unable to think of one.

Tagged data elements can be combined for a single patient to produce the equivalent of an EHR, and organized around the needs of that patient at the time of care. At the same time, the data can be analyzed and combined with links to other information to provide physicians with clinical decision support, delivering patient-specific information to their fingertips to make the best possible decision for a patient given all of the information available. Tagged data elements from aggregated populations can also be combined to analyze comparative effectiveness of aspects of healthcare and improve efficiency and quality.

Since the language of metadata-tagged data elements is extensible, not fixed, it can itself evolve in response to the development of new applications and new medical knowledge. As already mentioned, extensible exchange languages exist today and are already used within health IT in specialized niches—and are used widely in other sectors. A main finding of this report is that the time is ripe for such a language to be declared as a universal exchange language for health IT, and that doing so will catalyze a large number of immediate and longer term advances.

Tagged data elements can be extracted by special software (known as middleware) from existing clinical systems. Or they can be produced from enhanced versions of those systems, or by completely new and innovative applications. In this way, all data could be exchanged among all systems no matter the origin or internal record formats of the data, and without the necessity of replacing existing legacy software.

A universal data exchange language can scale up to any level. It can allow retrieval by patients and physicians of information from different providers, in different parts of the country, to improve safety and coordination. It can deal with the diversity and complexity of both the underlying business and clinical systems. New types of data and associated metadata can be added at any time, since new data elements do not have to fit into a particular format. Data can be converted to whatever form best supports their intended use, from clinical diagnosis to medical research. This approach can create a fully interoperable, less costly, more effective national health IT ecosystem.

The availability of a universal exchange language can dramatically accelerate the entry of third-party innovators, because they can create applications that rely on uniformly described data elements and can access a larger market. These new applications could include cloud-based subscription services for individual doctors, small healthcare practices, long-term care facilities, large practices, and hospitals to handle practice management (e.g., registration, scheduling, and billing); sophisticated medical systems (e.g., decision support, integrated lab ordering, medication management, allergy tracking); integrated medical-image management; integration engines to facilitate data exchanges with personal health records and other types of EHR in the cloud; and population health management (e.g., analytical tools for public health reporting, clinical research, and outcomes analysis).

The approach that we describe is consistent with existing market trends. Innovative companies are emerging that can access data from existing records and rearrange, store, and exchange the data as desired. Other companies are offering advanced software applications, information, and other services via the Internet. PHRs allow patients to store and monitor all of their health information and research their conditions using the full range of electronic resources.

The approach described does not require the creation of a uniform patient identifier or a national repository for healthcare data. The data, protected by strong encryption, can be stored on existing legacy systems or in the rapidly evolving “cloud” of distributed data stores. 51 Data involving a particular person can be stored in many different places and then aggregated, just as individual web pages are constructed from elements stored on many different computers. Specialized and secure search engines can crawl and index the metadata while actual access to the underlying data remains constrained by privacy protections.

This system can provide much greater security and privacy protection than can the current system. The attached metadata would describe the use and access provisions of the data, in accordance with law, policy, or the patient’s privacy preferences where applicable. For example, in a circumstance where consumers give their consent for particular uses of their data and prohibit other uses, this information would be encoded in the metadata. For example, privacy restrictions embedded in the metadata could permit a physician to send a pharmacist the data required to fill a prescription and permit de-identified data to be used for clinical research, but restrict other uses of the data. Privacy considerations are discussed in greater detail in the following chapter.

This chapter’s bottom line

A universal language for the exchange of health data is needed. An extensible markup language, where individual pieces of data can be tagged with context-setting metadata, is a straightforward solution and is superior to other proposed architectures.

V. Privacy and Security Considerations

Introduction

A key advantage of the tagged data element approach is that it will allow a more sophisticated privacy model, one where privacy rules, policies and applicable patient preferences are innately bound to each separate tagged data element and are enforced both by technology and by law. In this chapter, we briefly review the present situation as regards the privacy protection of medical information, and then explain the technology building blocks that will enable better approaches.

The Present Framework

American ambivalence about integrating health IT into the healthcare system is rooted in significant part to concerns about privacy and security. Even though a large majority of Americans believe that electronic health records will improve the coordination and quality of care, 52 many Americans also believe that there is a reasonable likelihood that unauthorized users will view such records. 53 For example, a 2006 survey for the Markle Foundation found that 88 percent of Americans believe digital records will reduce the number of unnecessary or repeated tests and procedures they undergo. 54 However, this survey also found that 80 percent of respondents were “very concerned” about theft or fraud, 77 percent were equally concerned about use of their records for marketing purposes, 56 percent were worried that employers would see their health records, and 53 percent expressed concerned that insurers would, too. A solution to this perceived privacy problem must underpin any overhaul of the medical-data ecosystem.

Concern about the privacy of medical data is predicated on a range of factors. First is the potential for discrimination—in access or economic terms—that might influence health insurance or employment. Second, for some consumers there is a sense that medical data are “different” than other personal data. From this perspective, financial data involve something an individual has, whereas medical data involve what an individual is. Third, the use of personal medical data by others is potentially exploitative. People may be comfortable with having their de-identified data used for beneficial purposes like disease research, but not if they believe that commercial interests may use such information to try to sell them something or otherwise exploit it. Finally, Americans harbor deep-seated fears about possible government access to any personal data. 55

The HIPAA Privacy and Security Rules, which went into effect in 2003, establish a Federal floor of protections for health information. The Privacy Rule, as amended by HITECH, regulates the use and disclosure of identifiable health information held by health plans, including employer-sponsored; health clearinghouses; and health care providers who engage in certain administrative electronic transactions (such as submitting claims electronically (collectively called “covered entities”) and their business associates. 56 In general terms, the Privacy Rule permits, but does not require, the disclosure of identifiable health information for treatment, payment and various health care operations without the express written permission of the patient. The Rule also permits the disclosure of identifiable health information for research and public health without patient permission, as long as a number of other specific, detailed conditions are met. As a Federal floor of protection, the Privacy Rule does not supersede state laws that are more stringent, such as those that require patient consent to exchange health information for treatment purposes.

The Need for Strong, Persistent Privacy Protections

To build and maintain the public’s trust in health IT requires comprehensive privacy and security protections that are based on fair information practices and set clear rules on how patient data can be accessed, used and disclosed, and that are adequately enforced. An individual’s right to have some meaningful choice in how their information is shared is one important component of a comprehensive set of protections. Where such choices are provided, either in law or by policy, they must be persistently honored.

A patient cannot make meaningful privacy choices unless he or she understands the flows and uses of information and can therefore make informed choices. That is not the reality today. In practice, the current consent model mandated by HIPAA rarely allows fully informed choices. HIPAA allows many common disclosures (for example, for treatment, payment, and healthcare operations) without any consent at all. Some other disclosures are allowed unless the patient specifically opts-out. Some particular transactional flows of data require patient approval, but patients have little real information about those flows or the uses to which they will be put. As seen by the patient, HIPAA protection is often little more than “sign here to acknowledge that you understand your rights under HIPAA,” which, of course, few patients do.

Some provisions of HITECH are intended to remedy this situation and give patients more control over the flow of their health information. For example, patients now have the right to restrict a provider from disclosing identifiable health information to a health plan when the information relates to treatment for which the patient has paid out of pocket. In general, however, patients have limited control over the way their health information is shared.

An exchange language based on tagged data elements allows for privacy rules and policies to be more effectively implemented; it also allows for more finer grained individual privacy preferences to be more persistently honored 57, and it can potentially allow patients to make better informed, persistent privacy choices not just in the rush of a medical encounter but reflectively and in an informed manner. For example, in circumstances where patient consent is required by law, policy, or practice, as part of enrolling with a primary care physician, a new patient might be asked questions like these: Do you want your primary care physician to be able to see your complete medical record, including from other places that you have been treated in the past? Do you want this to be automatic for places where you may be treated in the future? Do you want your physician to be able to consult with other physicians and share relevant records with them at his or her discretion? If you are brought to a hospital emergency room, do you want them to be able to access your medical records without asking you? What if you are unconscious? Do you have a personal health record, and do you want your medical information to be automatically synchronized with it? Are there parts of your health history that you do not want disclosed to another doctor, such as treatment for mental illness? Do you want to be notified (or have your physician notified) when research using your data suggests new options for your own care?

There are pros and cons to the different possible answers to the questions in this example, and patients, in consultation with their physicians or other counselors, must understand these. For example, a physician must be able to know when a patient has chosen to withhold data and may not ethically be able to treat a patient who withholds medically necessary information. As a general principle, the more information that patients consent to make available in clinical situations, the more likely they are to benefit from better diagnosis and treatment options, especially those that may depend on their specific personal histories or genetic makeup. 58 Similarly, in sharing their information for research purposes, patients participate in a social contract that benefits everyone in general, but may also (with the help of an enabling health IT infrastructure) benefit themselves directly. Privacy and security protections need to be seen as enabling population research, not unnecessarily limiting it.

While face-to-face counseling on privacy choices should be available whenever choice is either required by law, policy or practice, most patients will probably educate themselves on the issues and make privacy choices through a web interface, where they will also be able to change their choices at any time. An important point is that, when patients have a meaningful opportunity to choose, a patient’s choices will be persistent, that is, continuing until changed. Most patients ideally will have elected privacy choices at a time when they are healthy and competent. This is truer to the principal of informed consent than is a rushed signature at the time of a medical emergency, or when the patient’s physical or mental competency is compromised.

Deleterious Effects on Medical Research and Care

The HIPAA Privacy and Security Rules, as well as sometimes more stringent state laws and regulations, were intended to enhance the privacy of health information. However, they have had the unintended consequence of freezing its exchangeablity. The complex mandates of both HIPAA and state laws and regulations leads organizations to equate protection to sequestration, with little or no provision for either access based on roles (for example, the needs of an emergency room physician) or for legitimate secondary uses of data (for example, epidemic tracking), although HIPAA itself actually does allow disclosures in many such cases.

Even before HITECH, some organizations’ interpretations of HIPAA had proved detrimental to medical research and, potentially, care. For example, a 2005 study by the University of Michigan found that implementation of the HIPAA Privacy Rule was followed by a drop from 96 percent to 34 percent in the percentage of follow-up surveys completed by patients being monitored after a heart attack. 59 The report concluded that the Privacy Rule “significantly decreases the number of patients available for outcomes research and introduces selection bias in data collection for patient registries.” Similarly, a 2006 study by the U.S. Government Accountability Office found that healthcare providers were “uncertain about their privacy responsibilities and often responded with an overly guarded approach to disclosing information to ensure compliance with the Privacy Rule. 60

It seems likely that the modifications to HIPAA enacted in Subtitle D of the HITECH Act—in particular those that require covered entities to track all disclosures to associates 61—will further stifle innovation in the health IT field while offering little additional real-world privacy protection. The limitations of HIPAA and the HITECH provisions (sometimes referred to as HIPAA II) should be reformulated so that they ensure both patient privacy and patient benefit from medical research, in a world where medical data are increasingly in electronic form and where there is a growing need for real-time or near-real-time aggregated data to improve healthcare. A recent report from the Institute of Medicine suggests that these policies need a major overhaul to enter the electronic age. 62

Data Security: How Good Is Good Enough?

An exchange language based on tagged data elements enables a fine-grained model for addressing privacy, including honoring a patient’s privacy preferences. However, this model is only as good as the level of security applied to the data itself. If an unauthorized user can compromise data security, and not get caught in doing so, then he can also compromise any patient privacy model.

In data security, the perfect is often very much the enemy of the good. It is important that criteria for electronic security measures not be overspecified to the point of impossibility. A useful point of comparison is the degree of security inherent in old-fashioned paper records stored in folders in a medical file room. These paper records are completely secure against large-scale, remote electronic “phishing” to sift through the records to find particular nuggets of information. File rooms seem in practice to be fairly secure against massive compromises even by physical means: breaking and entering to steal large numbers of paper medical files would not be a difficult criminal exploit, but it occurs virtually never. 63

By contrast, paper records provide much less protection against unauthorized compromise (e.g., by copying) of the medical record of a single, targeted individual. We can infer from publicized cases that this happens regularly (for example, in the case of celebrities 64). While private investigators cannot in most cases obtain a third party’s medical records legally, they appear to have a significant ability to do so nonetheless. There is no reason to think that paper records are more secure than electronic records in the scenario of targeted individuals, since the exploit is typically enabled by suborning an insider with access to both paper and electronic records, or by social engineering (e.g., wearing a doctor’s gown and walking into an unattended file room). In fact, paper records lack intrinsic security that is provided by even the most elementary electronic security protections. There is no way to tell if a paper record has been read or copied, for example. By contrast, an electronic system with basic authentication (by username and password) and auditing (of file accesses) preserves a record of who accessed what.

We can draw several conclusions: A health IT infrastructure needs to provide significantly better security than traditional paper records in all respects. It must be designed with very strong technical protection against remote, bulk attacks that compromise large numbers of records, because paper records do not have this vulnerability. The security of a single individual’s information needs both technical protection and also protection by regulation and criminal law. Technical protection alone cannot prevent the suborning of otherwise authorized individuals, but it can greatly raise the bar by making them likely to get caught.

In today’s healthcare sector, there is an astounding range of security practices in handling electronic data, ranging from excellent to poor. Importantly, there is little consistency in security practices. Sloppy practices have led to system failures at multiple levels, such as the massive compromise of personal data in a stolen laptop computer 65 or a burglarized hard disk drive. 66 In a well-designed system, as one example, it should be technically impossible for any individual to aggregate large numbers of records in an exportable format, and there should be multiple layers of real-time auditing to be sure that it is not in fact happening. We next turn to the question of whether it is possible to design appropriate protections for the privacy of electronic health records.

A Health IT Architecture for 21st-Century Privacy and Security

We believe that a universal exchange language based on tagged data elements will allow the design of much better privacy and security protection than currently exists for either paper or electronic systems, for two principal reasons. First, the ability to tag an individual piece of data with privacy-related information, as part of its metadata, enhances privacy safeguards. Second, because tagged data element exchange protocols are designed to be efficient for the rapid exchange of small pieces of data, it is feasible to use security protocols that involve multiple exchanges of challenge and response. We illustrate these points in this and the next subsection.

How would this all work behind the scenes technically? Here we review briefly some of the technologies that can be combined to produce a well-designed system for protecting patient privacy, and indicate some of the design choices that will need to be made in creating such a system.

Encryption is the basic technology of making data completely unreadable unless it is brought into contact with a separate, smaller piece of data called the encryption key. Each piece of data can have its own key, or multiple pieces can have the same key. There can be several different keys that unlock the same data—for example, one for ordinary use and another (kept somewhere else) for rare emergencies.

A likely design decision would be that all patient information should always be encrypted either when stored or transmitted. Encrypting all “data at rest” (stored as on hard disk drives) protects against physical data breaches like misappropriation of hardware from healthcare IT data centers. Encrypting data “on the wire” (transmitted over networks), and authenticating the endpoints of every network connection, help defend against various network attacks, such as eavesdropping and misdirection of sensitive data to unauthorized parties. 67

Another design decision could be to specify that a key for patient information is never stored (or even present) on the same computer system that holds its corresponding patient data. That would enforce technically that there be a transaction whenever data are to be used: the data must come from one computer system, and the key from another. The two computer systems can be physically distant, and managed by different organizations, so as to make insider threats much less likely. Transactions (which can themselves be encrypted) can be monitored and audited by a security infrastructure that is also independently managed.

Crucially, each encrypted datum carries metadata governing its specific use and access. These metadata are inseparable from the data and are inviolable, protected by a digital signature. While metadata are themselves likely encrypted (another design choice), their keys are, by design, known to an authorized set of secure search engines so that, for example, all the records of a particular patient can be located. However, the search engine has no access to the (differently encrypted) actual patient data.

Identity is also a crucial aspect of security. Determining the identity of a principal is commonly called authentication. Except for patient-consumers, all of the principals in the health IT system can be authenticated using physical credentials (such as smartcards), biometrics (such as fingerprints), and a secret such as a password. Requiring two of these three methods, a possible design choice, is termed “two-factor authentication.” Credentials could be issued to healthcare professionals by participating institutions and medical-certification agencies. Whenever data are accessed, an audit mechanism records the actions taken by principals, along with the information used to authorize those actions. Credentials can be revoked when necessary.

An authenticated principal has the right to perform actions in the system. Some rights might come from the identity of the principal (e.g., a patient has the right to see her records), while others might come from the role held by the principal (e.g., an emergency-room doctor has the right to see the medical record of an unconscious patient). Determining the rights of an authenticated principal is commonly called authorization. In the healthcare security system, a range of designated, authorized roles can be pre-consented, and anybody who presents the role credential will get appropriate access for a particular situation. This credential does not attach to the individual; it attaches to each specific role. For example, when an emergency-room doctor leaves for home, his or her role-based authorization is deactivated.

Finally, an audit mechanism records the actions taken by principals in the system along with the information used to authorize those actions. A secure audit mechanism must provide strong protection so that audit records cannot be tampered with or deleted. For example, an audit system must record any access, modification, or deletion of a patient’s health records and any changes to the associated authorization policies. In case of an error in a patient’s health record, the audit mechanism would reveal the principal who introduced the mistake and the authorization information for that access. Strong audit mechanisms can be implemented using cryptographic and other techniques. 68 Patients should have the right to review audit records pertaining to their data.

A well-designed combination of encryption, authentication, authorization, and, for research uses, de-identification can yield a health IT infrastructure that is secure, and where all principals are auditable. It can have strong protection against bulk data theft (for example, using real-time audit mechanisms on top of all the other controls), and be significantly better protected against insider threats to individual patient privacy than present paper or EHR-based systems. As already noted, technical security, no matter how effective, must also be augmented by administrative, civil, and criminal penalties. Because technical measures can never be perfect (especially against insider threats), it is ultimately these penalties that deter willful misuse by individuals or negligence by institutions. What well-designed technical measures can do is to make data compromises very difficult to perpetrate, and thus very rare.

Privacy Protection of Metadata-Tagged Data Elements

By way of example, let us look somewhat more closely at how the general technologies described above might be combined in an infrastructure based on tagged data elements. For the purposes of this example we will make an arbitrary set of design choices, not necessarily those that might be made after a careful systems study. Suppose that the data elements in question are, as in a previous example, the mammogram history of a particular patient, Abigail.

In a first scenario, suppose that Abigail’s physician, Dr. Jones, queries to bring up all of Abigail’s previous mammograms. The data element access services (DEAS) described in Chapter 4 first check that Dr. Jones has properly authenticated herself to the system and that she is in a role (e.g., primary care physician) that allows her to issue queries of this type. It then assembles (based on Abigail’s name, date of birth, present and previous addresses, and so forth) a list of locations at which Abigail has medical records and has given prior consent for them to be locatable (assuming that rules or policies are in place requiring such consent). 69 If Abigail has consented to have the nature of her medical records also indexed (e.g., that some locations hold mammogram records, while others hold blood test records) then the list of locations can be pruned to a smaller number; otherwise the DEAS has no medical information and does no pruning. The DEAS now sends the locator information list (analogous to the web’s “https://” universal record locators) to the EHR system on Dr. Jones’s computer. That system, not the DEAS, then fetches the actual tagged data elements, each one containing a previous mammogram. It is important to note that the DEAS never has access to the mammograms themselves (the clinical data), and has access to even a description of the clinical data (the fact that it is a mammogram) only with patient consent. While most patients may elect a default choice that allows more efficient indexing and location of their records, the DEAS is designed to also serve (albeit with reduced efficiency) patients who choose to impose greater privacy restrictions on their data.

Can Abigail’s mammogram images now be displayed? No, because they are still encrypted. For each data element, Dr. Jones’s computer now queries another service of the DEAS for the required decryption keys. These requests include, again, Dr. Jones’s own authentication data and role. They now also include the digitally signed (and therefore unforgeable) patient privacy preferences that accompany each mammogram as metadata. The DEAS examine whether Dr. Jones’s credentials and role are consistent with Abigail’s privacy choices. If they are, the DEAS send back the individual keys, and Dr. Jones’s computer displays the mammograms. If they are not, then an explanatory message is sent and the mammograms are not displayed. In either case, the entire transaction is summarized in an audit record that goes, in real time, to a layer of security checking designed to look for anomalous signs of misuse. Such signs might include the collection of more patient records by a single supposed clinician than can plausibly make sense in that clinician’s role, or a pattern of requests from a single facility for data on patients with whom they have no previous relationship and for whom they cannot supply any required evidence of patient interaction.

Notice that, in this and all scenarios, data and key are brought together only in the clinician’s computer, and only for the purposes of immediate display; decrypted data are not replicated or permanently stored locally. Note also that the multiple data storage locations never had access to the keys, so compromise of their data, even by an insider with physical access, is impossible. Similarly, the DEAS that managed the keys never saw the data.

In a second scenario, suppose that an NIH researcher, Dr. Garcia, is studying the comparative effectiveness of two different mammography techniques. His credential and role identify him to the DEAS as authorized to receive only de-identified data from patients. When Dr. Garcia queries for data, he receives 100,000 locator records for mammograms meeting these criteria. However, these locator records are different from those returned to Dr. Jones’s in the first scenario. Their unforgeable digital signature specifies that they may only be used to locate de-identified data. When Dr. Garcia’s computer now sends out for the 100,000 mammograms (and their accompanying metadata), they come back de-identified, and they contain a digital signature that so certifies. Dr. Garcia’s new DEAS queries for the individual decryption keys must now contain (i) his own authentication and role as researcher, (ii) the digitally signed privacy requirements and preferences (where applicable), and (iii) the certification that the data have already been de-identified. Only if everything matches do the DEAS provide Dr. Garcia’s computer with the decryption key for each piece of de-identified data.

These examples are intended only as illustrations. In fact, the computer exchanges would be even more complicated than indicated. The fields of computer security and data protection are sophisticated and highly developed. While the web will continue to be full of reports of data compromises in badly designed systems, or systems subverted by bad management practices, there is no reason that a national health IT infrastructure should be designed and managed at less than state-of-the-art best practice. Our judgment is that such best practice can yield much better privacy and security for health IT than today’s scattered approach, and also can be much more enabling of secondary data uses such as public health and research.

This chapter’s bottom line: The tagged data element approach allows for a sophisticated, fine-grained model of implementing strong privacy controls (including honoring patient-controlled privacy preferences where applicable) and strong security protection.

VI. Economic and Regulatory Issues

Introduction

Many economic and regulatory steps need to be taken to realize the technological opportunities described in this report. This chapter offers a succinct discussion of some of the main issues. An important consideration here is that many aspects of health IT, particularly those associated with data exchange and aggregation, have “public good” characteristics. Because the benefits of a networked health infrastructure will be distributed widely, while costs are borne locally, market forces may fail to generate appropriate incentives for providers to invest in interoperability or to allow their data to be indexed and accessed. The public good nature of the problem calls for coordinated leadership to implement standards for interoperability and to enable indexing and retrieval of patient records. At the same time, policy makers need to create market conditions that reward information exchange, and enable market innovation to deliver the IT services and applications that can ultimately have a major effect on healthcare systems.

The technological approach described in Chapters Four and Five relies on two key elements. The first is the adoption by providers of interoperability standards that enable data to be shared across institutions. The second is the creation of network infrastructure and administration that enable distributed data to be indexed and accessed subject to appropriate data access restrictions. Both have the public good features mentioned above, in much the same way as investments in transportation or communications networks. We argue that Federal leadership exercised by ONC and CMS can play an important role in furthering both interoperability investments and network infrastructure development.

Standards and Incentives for Interoperability

As described in Chapter Four, one way to enable scalable data exchange and new application development is through the adoption of standardized metadata that enable patient data to be indexed, queried, transmitted, and re-assembled for different uses. This route to interoperability does not mean that every provider has to adopt a standard health record format or reconfigure its approach to inputting and managing patient records. Indeed, we pointed out that technology already exists and is offered by a variety of middleware providers that enables existing systems to become interoperable in this fashion. 70

Nevertheless, the economic environment poses substantial roadblocks for investments in interoperability. There is not yet a recognized standard for health metadata, and healthcare organizations and technology providers considering adoption of a standard face a coordination problem. Even for the healthcare systems that are leaders in using information technology, there is little private incentive to focus on widespread interoperability unless other providers are making the same investment and there is a clear path toward productive data exchange.

Furthermore, the economic incentives of healthcare providers may not be strongly aligned with making patient data exchangeable. Healthcare providers with their current closed data systems may view their data at least partly as a proprietary strategic asset. A hospital may have an incentive to exchange data with local clinicians, improving patient care and tethering the clinicians more closely to the hospital. But the incentives become less clear if the hospital is contemplating exchanging data with competing hospitals or with providers who are not local and with whom it shares few patients.

The local and regional health information exchanges discussed in Chapter Three have gone some distance toward promoting data transfer between institutions. But these models in their current form do not use a tagged data element approach that enables parties to flexibly assemble and re-assemble data elements in different ways to respond to different types of patient encounters, address population questions, track drug effects or epidemics, or enable clinical research. Moreover, as described earlier, local and regional exchanges will not provide a clear route toward national interoperability if they adopt different standards or settle on different governance models for regulating data access.

Federal leadership, therefore, has a clear role to play in coordinating standards for health metadata and in creating economic incentives to adopt the standard. The definition of meaningful use and the rewards for being a meaningful user (and penalties for not being one) are powerful mechanisms for doing this. Current work on meaningful use already has begun to incorporate interoperability standards. The initial recommendations by the Health IT Standards Committee that were transmitted to ONC in March 2010 do describe data exchange standards that providers must adopt to qualify as meaningful users, but they are far less ambitious than the objectives laid out in this report. In the next chapter, we will make some specific recommendations for how these standards can be developed over time so that the lever of meaningful use can help promote an effective architecture for widespread data exchange.

We emphasize that there is a potential concern with pushing too many requirements into meaningful use. The concern is that this will create too onerous a burden for many healthcare providers, especially smaller physician offices that already may lag behind in adoption. However, the initial experience with meaningful use suggests that providers of the IT systems have a strong incentive to compete by ensuring that their products qualify under meaningful use. If meaningful use is expanded in a moderate way to require standardized metadata, technology providers likely will incorporate the standards into their products, and competition between technology firms will rapidly bring down the costs of middleware that will allow legacy systems to meet the standard.

Creating a Data Exchange Infrastructure

The second component to the technological model we have outlined is the network infrastructure that links healthcare providers, patients, labs, researchers, and other stakeholders and enables qualified users to query distributed data stored by partners in the network. In thinking about the development of such an infrastructure, an important economic point is that communication networks are very often characterized by increasing returns. One reason is user externalities: the more parties sharing data in a network, the more valuable is membership to any given party. A second is the spreading of fixed costs. On a per-member basis, the costs of creating an indexing and data retrieval service may be large if only a few providers are participating in the network, but many of the costs are fixed and hence decrease on a per-member basis with increasing participation.

Current efforts at health data networking are at relatively small scale. As we have described, they consist of local and regional health information exchanges and narrower initiatives between particular institutions (hospitals and affiliated local physicians, or Kaiser Permanente and the Veterans Health Administration). The ONC is offering important support to these efforts—for instance, through cooperative agreements with all 56 states and territories to lead and promote health information exchange and through its Beacon Community grants program, which provides funding to 17 communities to build systems by which hospitals, clinicians, and patients use technology to improve health. 71 An important strategic question, however, is whether local experimental projects are the appropriate approach if the end goal is a national infrastructure.

One way to achieve this is to ensure that pilot projects are scalable and employ sufficiently flexible and interoperable technology. There are several ways in which Federal agencies might take this approach. One possibility is that CMS, the VHA system, or the Department of Defense (DoD) could initiate scalable pilot exchanges using the type of tagged data element model described in Chapter Four. The ONC also could use its grant funding to promote exchanges with the same type of flexible and scalable architecture. Finally, meaningful use guidelines that require providers to expose certain data to qualified users over approved networks are a powerful incentive mechanism. We make specific recommendations about meaningful use in the final chapter.

Regardless of how the network takes shape, an essential piece of the approach described in Chapter Four is a service that would index data available to the network and allow approved parties to locate a patient’s data and assemble data elements, in both cases subject to access regulations. We termed this the data element access services model. The provider or providers of these services do not need to physically possess or store patient records in a central repository. But the providing entity does need to index data stored in a distributed fashion and retrieve and transmit data elements in response to qualified user queries, in much the same way that Internet search engines index data on the web and assemble data elements in response to queries.

The economic and regulatory issues around this service require careful consideration. Because privacy concerns are paramount with patient data, any provider of indexing and retrieval services must be able to maintain the trust of patients and clinicians. While such services might evolve in response to market forces, it seems likely that, at a minimum, regulatory oversight by ONC will be important for preserving patient trust. For instance, one possible regulatory requirement might be that providers of indexing and retrieval services have no commercial interest in the data and operate in ways that seek to maximize benefits for patients and the general public.

Compared with the broader costs of health IT adoption, the costs of creating indexing and retrieval services are likely to be low provided that the network reaches sufficient scale. Nevertheless, if the entities providing the service are prohibited from making commercial use of the data, they will need a funding mechanism. One possibility would be for the Federal Government to provide initial funding. Ultimately a variety of models might work. Funding could come from small charges on queries or from a small fee assessed to insurers on the basis of their enrolled members. One potential advantage of having payers, rather than providers, be the source of funding is that payers are in the best position to pass the costs on to the general population, who ultimately will have to bear the costs for any technology investment. Also, obtaining funding from payers would not impose a direct financial burden on providers, labs, or pharmacies whose participation would be important for making the system valuable.

A Regulatory Structure for Data Access

The national health IT infrastructure we envision would also require a carefully considered system to control access and ensure patient consent. As described in Chapter Five, an important benefit of the tagged data element approach is that different data elements can have different levels of security. This means that a single system can allow a treating physician to access a complete patient record, a payer to access summary statistics from a physician, and a researcher to access de-identified data to enable clinical research on different treatments.

With a tiered system for data access, applications used by providers, patients, and researchers might be assigned roles that enable them to retrieve and use different types of data. Patients and providers could then consent to share data for certain purposes but perhaps not for others. For instance, they might consent to allow data to be accessed by other providers for direct clinical care or allow certain data elements to be accessed by researchers in other than de-identified form. But they might prohibit access to firms seeking to market pharmaceuticals unless they wanted to be targeted for advertising.

There are inherent trade-offs in formulating a regulatory policy for data access. Patients with privacy concerns and providers with an economic interest in maintaining proprietary data may prefer a tighter policy that limits data sharing and the ability of third parties to develop applications that make use of networked health data. On the other hand, such applications have the potential to yield substantial general benefits in terms of increasing the quality and consistency of care, informing patients, and facilitating research. In this sense, ensuring data access has some of the same public good aspects as interoperability and network investment—in particular, widespread general benefits and more targeted costs to privacy. It is important to keep this trade-off in mind in formulating regulatory policy.

Competition to Supply Technology

The economic incentives created by ARRA have already generated substantial innovation and competition in cloud-based electronic record products. More than 300 companies are offering some form of EHR product for physicians. Competition among these companies already has led to more affordable systems and improved products. Some of the companies in this market also are offering guarantees that physicians who adopt their system will qualify for meaningful use payments. 72 These cloud-based products are likely to become increasingly powerful as data exchange increases because physicians in smaller practices will be able to take advantage of data integration and tools that currently are available only to physicians in large integrated practices. This market therefore has an important role in ensuring that all physicians and patients benefit from advances in health IT and data exchange.

As noted above, moving from the current system to a tagged data element architecture will require that existing systems be upgraded to achieve interoperability. If providers have sufficiently strong incentives to upgrade, either because of the benefits of data exchange or because of meaningful use requirements, large EHR vendors are likely to move to interoperability. For organizations with legacy systems, we observed earlier that middleware products already exist that can extract data from existing systems and put them into tagged element form. The products might also provide an alternative for clients of large vendors who want a competitively priced alternative to upgrading their current system. To ensure that providers have multiple options, it is important that Federal policies are consistent with this market remaining competitive and innovative.

One further technology issue that arises in envisioning the future path of health IT relates to the problem of data storage and aggregation. Providers using electronic records are currently adding roughly 80 megabytes of data per person per year. 73 This rate is likely to increase as imaging and genetic data expands over time. As datasets expand, there could be substantial efficiencies in archiving large amounts of data in aggregated repositories. Indeed, this may be one advantage of cloud-based products. As we emphasized earlier though, the networked environment we envision is not dependent on the physical location of data storage. In this sense, it is consistent with a scenario under which data remain physically located with individual providers and labs, and one where technology evolves to favor a regime where data are stored in more aggregated forms.

Innovation and Markets for Applications

Transforming large amounts of linked data into information that improves healthcare delivery and benefits patients and other stakeholders will require a sophisticated layer of application software. Chapter Three described in some detail the limitations of today’s EHR systems that could be remedied with innovative applications. But because providers currently create and store data in many different ways and typically in closed systems, there is no common data “substrate” that application developers can use. Furthermore, short of individual time-consuming sales, there is no easy way to make data-centric products available to providers or patients.

An important advantage of the technological approach we have described is that it would enable new markets where firms compete to provide services and tools to patients, healthcare providers, payers, public health officials, and researchers. These tools might include products for patients to gather information about diseases using their personal health data, to input data from home health monitors, or to compare healthcare providers. Providers might benefit from improved tools for data entry, clinical decision support, or e-prescribing. Commercial products could also emerge to serve the general health system. For example, providers could benchmark their patient population and outcomes with peer provider organizations, enabling new forms of quality measurement.

Many of these tools might function by combining individual data with a broader reference database. Analogous products are common on the Internet. Map-based products that provide directions or help consumers locate businesses or services combine individual information (a person’s location and interest) with an underlying population database (maps with GPS coordinates, traffic data, and inventories of businesses). Personal finance tools use a combination of individual financial data and broader publicly available data on financial markets. The Internet also offers a model for market creation. As increasing amounts of data have become available (real estate transaction prices, financial market data, search and browsing data, and social network data), companies have emerged to build applications that use the data and market these applications to consumers and businesses.

One set of applications might address the problems with usability of EHRs described in Chapter Three. One way to understand some of the usability challenges is that current systems do not necessarily format information in a way that reflects the decision-making and information-flow processes of medical care. The problem is acute if a patient is seen by several providers who have to exchange clinical notes or lab results in document form. A system based on tagged data elements, coupled with the ability to query remote data stored by other providers, can allow for new software products that would deliver the data that the physician and patient require at the point of care, including the ability to intelligently retrieve information for advanced clinical decision support (evidence-based guidelines, genetic information, clinical trial access, and so on).

Patients also stand to benefit from applications that would allow them to collect information on treatments and physicians or share information with those who have similar conditions. For example, with the infrastructure we have outlined, a patient with a new diagnosis might be able to search instantly for the local specialist who has seen the most patients with similar conditions and prognoses. While it is possible that many patients may be uninterested in this form of engagement or these types of tools and will prefer to rely on a physician’s advice, there are likely to be a large set of patients, particularly those with chronic health problems, who are interested. Patients with chronic illnesses already benefit from being able to search the Web or share information through discussion boards and social networking sites. Many might have a strong interest in applications that would allow them to access information culled from underlying health records.

A further class of applications might help users compile and aggregate population-level data on health outcomes, physician performance, or population health. These applications could be geared toward provider organizations, insurance companies, public-health companies, and researchers, broadly defined.

The Broader Economics of Healthcare

A central point to keep in mind in thinking about the future of health IT is that the mere adoption of EHRs, and even the creation of a technological infrastructure for data exchange, is unlikely to have a truly transformative effect on the healthcare sector unless the appropriate economic incentives are in place to improve the quality of care and reduce costs. Indeed the same organizational and economic factors that have blunted the incentives to adopt IT will also affect the incentives of healthcare providers to use IT as they begin to adopt EHRs. In this sense, it is difficult to separate health IT issues from broader economic issues relating to the healthcare system. While addressing the broader economic structure of the healthcare system is far beyond the scope of this report, it is useful to highlight a few of the issues and mention some current Federal initiatives that may complement health IT efforts.

To see the issues we have in mind, consider the common claim that EHRs can eliminate duplication and reduce healthcare costs. While it may be true that, for instance, networked EHRs could allow access to recent lab tests, one also needs to remember that in the healthcare system, one person’s costs are another person’s income. There often can be a fine line between duplication and a useful safeguard, and to the extent that providers have strong financial incentives pushing in one direction, the mere installation of IT systems may not reverse behavior.

Taking this example up a level, it is widely understood that the dominant fee-for-service model does not provide much incentive to streamline care, and also that the fragmented organizational structure of healthcare makes it challenging to move away from this model, because each small practice or hospital is a “tub on its own bottom” financially and therefore is not rewarded for interactions with other providers. This puts some of the major potential benefits of health IT, such as the ability to coordinate care across physicians, or to share and aggregate data from clinical encounters, somewhat at odds with the prevailing economics of the healthcare system. From this perspective, it is clear that the vision of health IT we have described needs to be supplemented by a broader set of reforms in payment and healthcare organization to realize the full potential of these technologies.

Several of the CMS initiatives funded under the Patient Protection and Affordable Care Act (PPACA) are notable in this regard, because they potentially complement health IT efforts. One such initiative is the primary care medical home model, which would put the patient and primary care physician at the center of a virtual organization that is paid a fee to coordinate all care the patient receives from specialists and other providers. In this model, the primary care physician would need to be able to exchange patient information seamlessly with other providers and assemble a complete record of the patient to successfully coordinate care. Another is the accountable care organization model, which would group hospitals and physicians into larger organizations that would contract with payers to care for an entire population. In this model, physicians and hospitals would need to share patient data and information to coordinate care, reduce unnecessary emergency room and hospital use, engage patients and families to enhance self-care, and track patient outcomes in a continuous manner. Both of these models would seem to require the type of coordination and data exchange that health IT can provide.

Advances in health IT are also likely to facilitate many proposed innovations in healthcare payment. Many of these innovations, and particularly those authorized as pilots under the PPACA, revolve around either pay-for-performance or bundled payments. With pay-for-performance, providers would be rewarded or penalized for patient outcomes relative to some quality benchmark. Bundled, or episode-based, payments would shift payment away from fee for service toward payment for all treatment following a diagnosis or for a set of procedures and subsequent care.

Estimating Costs

PCAST has not performed a detailed analysis of the system-wide costs associated with implementing the recommendations of this report. However, some general comments on costs are in order here. Overall, the approach recommended in this report is expected to improve healthcare quality, decrease the cost of health IT systems (due to increased competition) and lay the foundation for systemic reforms to increase the efficiency of healthcare. These benefits are likely to be distributed widely throughout the healthcare system and persist over a long period of time. The transition costs to achieve these savings are expected to be small, both compared to the broad societal benefits and to the overall $20 billion scale of the Federal health IT effort. These costs will be borne more narrowly, at least initially, by EHR vendors, healthcare providers, and government agencies. It is useful to distinguish several components of cost:

1. An initial cost for developing standards for the universal exchange language and its associated privacy and security protocols. Based on this group’s examination of a range of analogous activities from other sectors of the economy and a survey of the literature and colleagues, we estimate the engineering cost of developing the actual standards to be in the range of $20 million to $40 million.

2. For healthcare providers with installed EHR systems, a cost to upgrade their systems, or to add middleware, so as to enable the exchange of data by means of the new protocols. Based on the current cost of middleware products, we estimate the incremental cost might be 5 to 10 percent of providers’ current EHR costs. On the other hand, this estimate may be overstated, because a nationwide move to adopt the new communication protocol would likely result in significant competition to supply upgrade products, which would place price discipline on incumbent EHR providers. We estimate that to upgrade their products, existing EHR vendors might have to make one-time engineering investments on the order of $5 million to $20 million per vendor, based on estimates of private investment in companies now offering products with similar levels of controls and privacy. The duplication inherent in these costs can be reduced by the Federal Government developing, and putting into the public domain, reference implementations for key processes (such as security functions).

3. For healthcare providers with no current EHR system, the additional cost associated with the new requirements of the universal exchange language. We expect this cost to be minimal or absent. The proposed approach will likely to result in a more competitive and innovative market for EHR solutions, for example cloud-based products that are well-suited for smaller providers.

4. Capital and operating costs to the government associated with the infrastructure for indexing and searching patient healthcare data, and for related trusted security processes. Here, we note that multiple companies such as Google, Microsoft, Yahoo, Baidu, and some that preceded them, have made private investments in building and provisioning search systems for the entire Internet, which dwarfs the quantity of information in health IT. We estimate the proposed costs as being on the order of $100 million to $300 million per year, probably ramping up from the lower figure as the use of these services ramps up correspondingly, producing greater national cost savings. Included in the costs is an assumption of 0.1 GB per person, which would today be $0.20 per person per year, a total of $62 million in storage costs. One possibility is that the Federal government would bear the cost for the initial capital investment, and that the costs ultimately would be borne by either all users of the service, or by healthcare payers, including the government in its role as a payer.

This chapter’s bottom line: Some aspects of the new health IT infrastructure will enable new, competitive, entrepreneurial markets. Some other aspects are “public goods” and will require government leadership. The benefits of health IT affect, and are affected by, other aspects of healthcare reform, especially payment models.

VII. Health Data and the Research Opportunity

Introduction

Today, most information about the effectiveness of therapies such as drugs derives from small-scale observations of a handful of patients (often a few hundred, sometimes fewer) in clinical studies. The most convincing clinical studies incorporate design elements, such as randomization of subjects to alternative treatments, to reduce the impact of unmeasured confounders on the treatment effect. These studies are appropriately considered to produce the highest quality evidence regarding a particular agent’s efficacy, but they also suffer from well-recognized problems.

Efficacy, not effectiveness: Clinical research studies usually focus on highly selected and often nonrepresentative patients. They are designed to detect differences in the main outcome of interest, which means they are often too small to pick up less common but potentially important outcomes (such as serious adverse events) and are too brief to capture fully the long-term consequences of different treatment strategies.

For efficiency’s sake, the studies often exclude patients with complex medical histories or many illnesses. This is problematic in that the treatments are needed by patients with complex illnesses where multiple different conditions make the range of choices greater than the usually simple comparison of a single trial.

Out of date before they are even finished: Today’s clinical research studies are not carried out in real time. Instead, they take years to design, fund, launch, and complete. Sometimes, by the time they are completed the question under investigation is obsolete. For instance, it is quite common for multiple clinical trials in cancer to be occurring simultaneously. New drugs can then be approved that have never been compared with each other, so the physician and patient do not have any way of knowing which is best. They only know that each is better than some other drug that is no longer used.

Burdensome and costly: Today’s clinical research enterprise is, at best, a sidecar loosely tethered to the clinical care enterprise. What is done in clinical research has its own expense structure and funding stream. The oversight of research is separate and apart from the oversight for clinical care. Its participants— both patients and investigators—are involved in sometimes redundant or repetitive activities. For instance, data often are collected twice for patients in clinical research studies: once for the patient’s chart, and again for the research database.

Narrow focus: Most research focuses on a narrow set of questions regarding therapeutic choices. Yet many important questions in healthcare stretch far beyond the choice between drug A or drug B. For example, healthcare research needs to evaluate operational aspects of the delivery system and evaluate arrays of therapeutic choices side by side. Ideas for new directions for research can and should come from observations about health trends independent of specific hypotheses.

The Potential for Real-Time, Real-World, and Comprehensive Data

Numerous questions that clinical research is poor at addressing today could be answered using large datasets gathered through ongoing medical care, particularly if the data were available in near real time. A list of questions that could be addressed illustrates the promise.

Syndromic surveillance and public health monitoring: Our infrastructure for monitoring public health is spotty and slow, depending on individual offices reporting data locally or regionally. Health IT and real-time data on the use of the healthcare system have the potential to address this deficiency. Today, the ability to follow cancer trends, asthma and other environmentally sensitive conditions, antibiotic resistance, or flu-like symptoms requires additional infrastructures layered on top of the healthcare delivery system (such as cancer registries or emergency room reporting).These infrastructures are costly and incomplete. In many cases, they also are unable to produce details related to the entire population (the denominator) against which this information should be compared.

Routine collection of data could eliminate redundancy, be far more comprehensive, and overcome the denominator problem. Case ascertainment (such as detecting new cases of cancer or new cases of antibiotic resistance) would grow naturally out of data capture during routine clinical care. Moreover, the denominator (or denominators) would grow out of the same resource. For instance, it would be straightforward to assess the prevalence of antibiotic resistance across all cultures of a certain bacterium in a geographic area during a certain period of time. Those data could be married to data on prescriptions of different antibiotics in ways that cannot be achieved today.

There are working examples of such real-time data collection. New York City monitors pharmacy purchases as a way of capturing early signs of flu-like symptoms. 74 This activity is important for routine decisions about vaccinations and also for such factors as bio-terrorism preparedness. Current search engines also can identify a flurry of inquiries about flu, but they cannot identify whether the queries resulted from symptoms or from media exposure.

Adverse event monitoring: An ongoing concern for drug and device safety is the lack of a routine system of data collection for adverse events. The Food and Drug Administration mostly relies on ad hoc reporting of events. It does not have a good way to estimate the relative frequency of atypical events among all patients exposed to a drug or device or to separate association from causation. With extensive use of health IT and aggregated data, the data would be sufficiently rich to identify patterns and to separate events caused by particular drugs and devices from those that occur purely by coincidence.

Many examples of such event detection exist. The most frequently cited is the linking of Vioxx to cardiovascular events—something achieved through analyses of data captured by Kaiser Permanente and reported by several insurers as well. 75 Other examples include the detection of cardiovascular complications associated with the diabetes drug Avandia and with several calcium channel blockers used for treating high blood pressure. 76 Yet these represent relatively rare cases of adverse events detected through clinical databases. Other serious adverse events, such as those observed in randomized trials measuring the effect of erythropoeisis stimulating agents on cancer progression, were not detected in administrative data even though the effects were large, because there was not enough clinical detail in the information. This limitation could be overcome by greater data availability.

Assessments of dissemination and utilization: The gap between knowledge and the delivery of care, branded as the “quality chasm” by the Institute of Medicine a decade ago, remains a serious concern. The shortfalls disproportionately affect members of minority groups and individuals who lack insurance. 77 Currently, numerous redundant and sometimes conflicting systems aim to monitor utilization and quality as a way to mitigate these problems. Through programs such as quality measurement and reporting, chart review, and auditing, providers are increasingly being asked to report on what they are doing. This set of approaches, although conceptually attractive, has many problems. Any quality measurement collection involves large costs and burden. It also involves choosing the quality measures before creating a structure to capture the measures, which means both that the domains of quality that can be assessed are logistically limited and that the speed of change is sub-optimal.

The potential of data to monitor quality and the use of evidence-based approaches is immense. At scale, health IT will provide insight into the quality of care in all settings without actually having to design systems to report a particular element. The initial standards for meaningful use emphasize this potential benefit. If clinical systems capture sufficient data about patients, including both their eligibility for particular treatments and their contraindications, along with physician orders, e-prescriptions, and other delivery data, continuous quality monitoring and feedback could become part of routine care rather than the add-on it is today.

Comparative effectiveness research: Perhaps the greatest potential of the data that can be captured using health IT lies in the potential to fuel comparative studies of diagnostic and therapeutic approaches. Comparing treatment and management approaches in a way that can easily be accessed by both physicians and patients could improve patient outcomes and reduce healthcare spending. Funding for comparative effectiveness research is already growing. Electronic health information, in the easily accessible form enabled by metadata-tagged data element collection, aggregation, and security standards, would enable this kind of research to advance much more rapidly than with the traditional, institutional EHR model.

Supporting Research Uses

The uses described above, although they all hinge on data collected through EHRs, require somewhat different types of data, falling broadly into one of three categories: Effective syndromic surveillance and other public health monitoring could be achieved through collection of data that are already regularly recorded in patient charts but are not currently aggregated. Separation of adverse events from coincidence and ascertainment of quality measures may require more detailed information than is currently routinely captured in most patient charts today, but likely possible to capture within the system that we envisage. However, comparative effectiveness studies, particularly those that build in some experimental design or require additional data elements or assessments, would require more data than are routinely captured and also would require a framework of two-way interaction with the clinician and patient. We will illustrate this in an example below. And there are many other types of clinical research, not just clinical trials, in which two-way interactions between research and clinicians are desirable.

Methodological issues will need to be considered as data from EHRs become available for research studies of increasing sophistication. Practicing physicians are busy, not necessarily trained in research, and not always ideal collectors of patient data for research. Patients, exercising their right to opt in or out of studies, will cause data to be collected from incomplete, or incompletely defined, populations. Effects like these complicate the design and validation of research results. But the availability of data in quantities orders of magnitude larger than today will allow subtle and sophisticated experimental designs, more than compensating, we think, for the data’s complexities.

Linking Patients to Clinical Studies

To see the potential for interactive data collection in EHRs to lead to the enrollment of patients in clinical trials, consider an oncologist who, upon seeing a patient with a new diagnosis of cancer, could be asked by the interactive program to upload detailed information about disease type, stage, other conditions, and performance status. Depending on that information, lists of eligible ongoing studies could be presented to the treating physician and patient, and enrollment in the study could occur during that visit. As an intermediate step, a more intensive data collection could be initiated, along with patient enrollment into a registry when enriched data are needed to address a particular question.

The value of such a system is clear. More information generated in clinical care could be used to accelerate learning, and many biases that exist in observational data could be overcome through the use of several types of experimental designs (such as randomization or block assignment). Providers and the patients would know all of the available opportunities to participate in clinical trials, and the physician could manage the patient through the process, with real-time data exchange to and from the research team. Not all providers would be authorized investigators in any trial, but electronic access to every available study would include the real-time ability to query the study about its appropriateness for the interested patient and any additional information. Much of this could be done without the patient having to transfer care to another provider.

 

Committing to only one level of data collection at a national level would be a mistake. A lot can be achieved based on clinical data gathered during routine care only, while some research requires additional data gathered during healthcare encounters. Other research may require experimental designs that entail additional steps such as informed consent, data categorization, follow-up questionnaires, and the like. To accommodate different levels of data collection, the infrastructure should be designed while considering the tradeoffs of collecting research-quality data against possible burdens. These burdens include a higher level of training for the providers involved and possible additional costs and processes required for high-quality research data, but the burdens can be limited and the advantages enhanced with access to a tagged data element environment. The implied trade-offs are matters of policy, to be codified only after careful consultation with all stakeholders, and to be justified not by the abstract desirability of research, but by explicit consideration of how research feeds back to better patient care.

Some opportunities and challenges in observational data: Observational data first uncovered the cardiovascular side effects of Vioxx, long before randomized trials demonstrated the same findings. Likewise, the apparent benefits of some unusually effective cancer treatments, such as Gleevec for chronic myelogenous leukemia, were apparent based on outcomes of studies using single specified therapies, well before randomized trials documented the actual size of the beneficial effect. 78 Yet observational studies can be hindered by biases that can be hard to detect, and sometimes findings are disproved by randomized trials or observational studies that contain more granular data. For instance, numerous observational cohort studies suggested that beta-carotene supplementation would reduce the risk of developing lung cancer, but randomized trials of the intervention showed the opposite effect. 79 A recent observational analysis of radiation treatment for women with DCIS (ductal carcinoma in situ, an early stage breast cancer) suggested that delays in radiation reduced overall survival, even though the underlying disease has a very low mortality rate and randomized trials of radiation for it had shown no mortality benefit. 80 The potential, and the limitations, are one motivator for providing an infrastructure that will eventually allow more than one approach to EHR-driven research.

Real-Time Patient Benefits from Comparative Effectiveness Research

Making patient clinical data available to researchers clearly has long-range benefits to patients. Until now, this has been a linear process with a timescale of years, since it requires performing the research, submitting it for peer review, publication, and ultimately the adoption of new clinical practices that benefit future patients.

Health IT can make it possible to get benefits to patients much faster. Indeed, patients could benefit directly from a research study to which they are concurrently contributing.

If patient progress and outcomes were routinely captured in data and made available in near real time, partial data can be used in sophisticated ways to assign treatments to new patients in optimal ways. These data also could be used to personalize treatment for patients already enrolled in a study.

 

A patient-physician interaction in an adaptive comparative study might proceed along these lines:

1. Using the physician’s diagnosis, the physician’s computer identifies a comparative effectiveness study relevant to the patient’s condition and advises the physician.

2. The physician asks the patient whether he is interested in participating. The patient is advised that, by participating, he will receive a treatment recommendation based on, literally, today’s best weighted judgment of all the accumulated data. However, the recommended treatment might not be the brand name drug that he expects.

3. The patient agrees to participate in the study.

4. Through the physician’s computer and the physician, the patient is asked if he wants to allow the study to access his personal genotype data, in which case a more personalized treatment recommendation might be made.

5. The patient agrees to this.

6. The study recommends a treatment, for example a prescription which is sent through the physician’s computer (with patient and physician concurrence) to the patient’s local pharmacy.

This example demonstrates a synergistic combination of three health IT opportunities, each potentially revolutionary. The first is real-time decision support to the physician based on evidence-driven best practice. The second is the real-time interaction of that decision support with completely current clinical data, without months or years of lag. The third is seamless integration of the clinical setting with the enrollment of patients into the clinical and comparative studies that will generate the next round of new data. Importantly, because these studies are adaptive (that is, they assign patients to treatments not arbitrarily, but rather based on the partial accumulated study data), they are consistent with the physician’s duty to give each patient the treatment believed to be best for him or her on the basis of the most current evidence. 81

 

This chapter’s bottom line: A national health IT infrastructure will enable new kinds of research and will also create opportunities for the faster coupling of research to clinical practice.

VIII. Guidance to Agencies

Introduction

In this final chapter, we discuss what needs to be done if rapid progress toward the realization of a national health IT infrastructure is to be achieved. Because of the complexity of the issues, we give recommendations at several levels of specificity. First, as an example, we sketch a possible roadmap for getting all the way to the transformative future that we envision. Next, in narrative format, we give some overall short-term guidance relevant to the two key agencies, ONC and CMS. In the next chapter, we give a list of specific recommendations to several agencies that can (and, we think, should) be tracked by senior policy makers within the Executive Office of the President as to progress achieved.

A Feasible Roadmap to the Future

An important feature of the tagged data element model advocated in this report is that there is a natural transition path from present EHRs and from existing demonstrations of information exchange. As an illustration, we sketch a possible way—though by no means the only possible way—in which that transition might unfold. Key to this roadmap is its leveraging of universal data exchange, and the network effect, to spur EHR adoption.

First, HHS would define by regulation the most basic features of the tagged data element exchange. This would include the specification of an extensible markup language, most likely a variant of the existing language XML. ONC’s clinical document architecture standard is important foundational work for this. However, additional focus is needed on aspects that relate to data transmission, to innate privacy features, and (perhaps most importantly) to facilitating the disaggregation of complex records into the smallest possible data elements, suitable for use by a broad range of new health IT products in a new, entrepreneurial marketplace. The universal exchange language is more than just an extensible wrapper for the exchange of documents, each in its own fixed format. It needs to facilitate (if not directly require) the exposure of the underlying semantics of individual data elements for new uses, including many not anticipated by the original data producer.

Also defined from the start would be a minimal initial set of requirements for the metadata that will accompany each piece of data. These might include, for example, the patient’s name and birthdate, the applicable privacy rules and policies, including any patient’s pre-consented privacy choices (e.g., “data may be used in research but only when fully de-identified”), an identifier of the originating physician or institution, a provenance within that institution (for example, a reference to a type of equipment or standard clinical procedure), and a time-stamp. Since the language is extensible, only a minimal set of metadata needs to be standardized at this stage; more will naturally evolve at later stages of adoption or as features added by individual software vendors.

A part of the specified metadata—for example, the patient name and birthdate—would be specified as “indexable” items that are made visible to authorized data element access services for indexing and data locating as they become available in stages of the transition.

Next, ONC and existing standards groups would publish mappings of existing vocabularies and content standards (for example, the HL-7 vocabulary standards for electronic exchange of healthcare information 82 and the ICD-9 and ICD-10 international disease classifications 83) into the adopted markup language. 84 This straightforward step immediately expands the semantically meaningful realm of tagged data exchanges to include data that are coded in these existing standards. It incorporates these standards into the new architecture, leveraging the work done by thousands of people for decades.

In parallel, vendors of existing EHRs would be encouraged to rapidly publish mappings of their existing exchange mechanisms into the extensible markup language. For example, if a product is now able to exchange prescriptions, whole medical records, or other information, the vendor should easily be able to map that exchange at the existing level of aggregation into the markup language. This is only a first step toward an infrastructure of fully tagged data elements, because the individual data units are not yet the smallest pieces that make sense to exchange and aggregate. However, it is an important step, because it immediately allows the development of middleware that is able to exchange and display information from multiple vendor systems. It also is an important first step toward creating the kind of competitive marketplace that we envision. Data from patient-controlled personal health records can likewise easily be mapped into the new framework.

Many, if not all, of the meaningful use exchanges that are posited for the near future can and should also be mapped into exchanges of tagged elements within the framework of the markup language. Also important is a standard metadata markup for physicians’ clinical summary records and case progress notes. There is no requirement at this stage for any exotic natural language processing or coding of these items. Their textual contents are exchangeable data elements in their own right whose exchange can add valuable clinical context.

After only these steps, we would already begin to see the value added of a single framework for tagged data element exchanges. At this point in the transition, the data are not yet in the smallest pieces that make sense and are not yet accompanied by all the metadata that will ultimately be needed. But the data will already have become universally exchangeable and universally privacy-protected, and the data will already incorporate large, widely recognized semantic realms. This is where the power of emergent markets, and the network effect, will first be felt.

This is the point at which patients and clinicians would see tangible benefits from “putting the patient back together.” Aided by new software applications, physicians will start to see tailored, unified views of all of a patient’s interactions with the healthcare system, seamless across institutional and geographical boundaries.

In parallel, both as the market for health IT becomes more competitive and also to meet new government or payer requirements, vendors of existing EHRs would start to break down their data exchanges into smaller, more elemental units. For example, a regulatory requirement for metadata that includes the model and calibration of the instrument used in a specific lab test will cause the data to be exposed as tagged elements, rather than as part of an unwieldy integrated EHR. If there are new entrants into the EHR business, they should see a competitive advantage in producing systems that use metadata-tagged data elements by original design. At the same time, existing vendors, or unrelated middleware vendors, will provide add-on software to expose existing EMR information in an exchange interface where it appears as tagged data elements, regardless of how it is internally represented. The feasibility of such middleware is demonstrated by the fact that, as we have noted, in special cases it already exists today.

Over time, deliberatively and by appropriate processes, ONC and CMS would require (by means of the meaningful use or certification regulatory mechanisms) that smaller meaningful units of tagged data, and more extensive metadata tagging, be exposed at the interface, so as to be encouraging the development of new software applications and new benefits to the physician and patient. We will have gotten to this point by incorporating into the new framework, and then incrementally upgrading, health IT systems that exist today. Also, by creating a universal framework, new markets will be created for innovative software applications whose internal representations of the data, and thus capabilities, may be amazingly different from those available today.

Guidance on Necessary Design Choices

The development of a complex information infrastructure, such as that required for health IT, requires many design choices at many levels, and with appropriate ordering in time. Early conceptual design choices may have large, and even unanticipated, effects on later implementation-related choices. An important concept is that every choice limits the possible design space of subsequent choices. Sometimes this is desirable, because it forces convergence to desired goals. Other times, and especially early in the design process, it is important that design choices preserve a wide range of subsequent design options. Good systems design consists of finding the golden path between the extremes.

One often hears it said that “government should not dictate IT architectures,” and we agree. The word “architecture” implies a series of decisions extending far down into the design process. What government does need to dictate, or at least facilitate the early standardization of, are those early design choices that will enable interoperability. These choices do not specify architectures, but rather “high-level protocols,” or “data exchange languages,” or even just common ways of thinking about the problem from a global perspective. Here government, both by its convening powers and by its regulatory authorities, has a crucial role to play, for the reasons already discussed in Chapter Six. 85

ONC leadership recognizes (as do we) that complete interoperability in the entirety of the domain of healthcare is a massive undertaking. This has led to an approach that is iterative and incremental, focused on producing the specific, limited solutions that bring the greatest immediate value. The problem with this seemingly sensible approach is that it can result in a set of ad hoc solutions, rather than in high-level design decisions that could be both convergent and preserving of a wide range of possible subsequent design options. A key example, previously discussed, is the rapid establishment of a universal, extensible exchange language. As a more general statement, we think that ONC needs to augment its current multi-faceted approach with a process that can generate design choices at a national level that are carefully balanced between the goals of convergence and diversity. This is an appropriate government role and requires a more aggressive approach than is visible at present.

As a related issue, ONC’s current approach has the effect of postponing the development of a genuinely universal “syntax” (that is, the formatting of data that are exchanged and the details of exchange protocols) until after the government has harmonized the “semantics” (that is, the clinical or operational meaning of the data, or its human understanding) from many different health IT-related realms. This approach implies a focus on achieving some harmonization between taxonomies for diagnosis, for test results, for genetic information, for billing codes, for the particulars of medical instrumentation, and so forth. We urge reconsideration of this approach.

A large body of experience in other domains suggests that creative and entrepreneurial energies are best unleashed by standardizing a syntax that is broadly extensible into different semantic spaces. A much-studied historical example 86 is the language XML (“extensible markup language”) and its many off-shoots. If an XML-like universal exchange language for health IT were even minimally standardized, then many existing semantic taxonomies could immediately be mapped to it. Would these be instantaneously harmonized? No. But there would be immediate market incentives toward harmonization, because vendors could compete on how broadly their products “understand” the existing semantic spaces. Rather than a never-ending, Sisyphean government approach to harmonization, the existence of an extensible standardized syntax would promote a market-driven, largely nongovernment, ongoing process. This is a case where government needs to define a (syntax-based) approach that opens the market to new players, and then largely get out of the way.

As mentioned, ONC’s CDA is a foundational step in the right direction. However, the thrust of CDA seems largely that it be an extensible wrapper that can hold a variety of structured reports or documents, each with vocabulary-controlled metadata. While this shares many features with the universal exchange language that we envisage, it lacks many others. In particular, it perpetuates the record-centric notion that data elements should “live” inside documents (albeit metadata tagged). We think that a universal exchange language must facilitate the exchange of metadata tagged elements at a more atomic and disaggregated level, so that their varied assembly into documents or reports can itself be a robust, entrepreneurial marketplace of applications. In a similar vein, we view the semantics of metadata tags as an arena in which new players can participate (by “publishing”), not as one limited to a vocabulary controlled by the government.

ONC’s cautious approach on these two issues is understandable: the problem itself is inherently complex, and the Office is under pressure from parties who would like the bar for receiving payments under ARRA to be set low. However, we are concerned that this direction, pace, and actions are not currently sufficient to achieve, in the necessary time frame, the President’s goal that the Nation have a health IT system adequate to support efforts to increase the quality and decrease the cost of healthcare. Some additional guidance for ONC relates to its support of CMS and is discussed in the next section.

Guidance on Meaningful Use Requirements

Earlier we discussed the broad discretionary powers given to CMS, under ARRA, to define what constitutes meaningful use of EHR technology. In Chapters 4 and 5, we outlined a vision of what ought to be achievable, over the mid- and long-term, as a state-of-the-art national health IT infrastructure. Here, we put these pieces together to suggest what CMS should be doing now.

To accelerate the adoption of a universal exchange language, HHS should specify that meaningful use measures reported to CMS be captured in a tagged data element format. 87 To meet these criteria in the short term, some healthcare providers with legacy EHR systems would probably add middleware to extract and operate on data-level clinical information. Large vendors of EHR systems would likely offer upgrades to meet the CMS requirements.

Such a meaningful use data policy would accomplish several things. First, it would advance EHR technologies in the direction of being able to generate data needed to support other aspects of meaningful use, for example, advanced clinical decision support. Second, this substrate of data will catalyze a host of new IT applications for physicians and hospitals to improve the quality and efficiency of care. Third, this policy eliminates the incentive for vendors to “hard wire” into EHRs the specific quality measures currently required to qualify for meaningful use, instead motivating them to provide a flexible framework into which specified reporting items can be easily inserted. This is important because meaningful use measures will change over time as the art and science of quality measurement improve and as more clinically meaningful measurement constructs become available. If providers are required to pay for expensive system upgrades as new measures are implemented, their support for both the technology and for quality assurance programs will quickly dissipate. Moreover, providers need flexibility in their EHRs to respond to the unique quality-reporting requirements of different health plans and to satisfy licensure, certification, and accrediting organizations with the least possible added burden.

To support this type of meaningful use policy, ONC should issue reference standards with which EHR, software, and middleware vendors would need to comply. The original set of standards for EHR certification 88 implementing HITECH relies heavily on existing standards for the interoperability of health information technologies, including those established and/or promoted by the Health Level 7 standards organization (HL7), NIST, and Integrating the Healthcare Enterprise (IHE). These standards were chosen in an attempt to provide a “minimum set of transport, content, and vocabulary standards required to drive or enhance the predictability of data exchange when used in EHR technologies, in order to drive adoption”. We would like to see ONC focus on enabling and accelerating health information exchange at the level of the datum, rather than the message or document, while developing a corresponding reference implementation to verify interoperability. This conceptually straightforward approach to certification would allow flexibility and continued innovation in quality measurement and reporting without adding an extra administrative burden.

For its part, CMS’s approach to innovation in quality assessment will need major structural and technical overhauls, and to share the visionary and strategic goals of ONC and the President, so that it advances the state of the art in both clinical practice and health IT. Now, for Stage 1 of meaningful use, CMS will require a set of objectives/measures for eligible professionals and 23 for hospitals. In selecting clinical quality measures for physicians, CMS chose to use a subset of measures from its Physician Quality Reporting Initiative. These measures are highly specified and can be submitted to (and received by) CMS only through specific, limited, technical methods.

PCAST has two concerns with this approach. The first concern is that although isolated, condition-specific measures such as “percent of patients with blood pressure under control” are relevant to population health, they are not adequate to assess the broad range of competencies required for physicians and healthcare organizations to deliver safe and effective care. There is good evidence that real improvements in quality will result only from generating and acting on data that reflect the multidimensional aspects of the clinical practice. 89 Today, large integrated group practices can often generate more sophisticated quality metrics and feedback to physicians than what CMS plans to require. It would be unfortunate if CMS were to re-focus these organizations on less effective measures. As another example, some medical specialty boards and health plans are creating comprehensive assessments of a physician’s skills in a particular clinical area. 90 These assessments might combine clinical data elements from a physician’s practice with results from a test of knowledge, a review of clinical practice systems, and patient experience surveys, all while testing the psychometric properties of new or different combinations of these various data elements. Such innovation in quality measurement and feedback should lead to innovation in practice improvement cycles comparable to other modern engineering standards. 91 CMS should develop a roadmap for expanding its quality measures to reflect improvements in both information technology and methods of quality assessment.

Our second concern is that clinical quality reporting to CMS is limited to the technical specifications of a single designated consensus body, the National Quality Forum (NQF). This in turn limits both the scope of kinds of measures and the technical specifications that CMS is able and willing to accept. The law contains language allowing an alternate pathway for measures if justified by the Secretary of HHS, but that pathway has not been used. We think that wider use of this alternate pathway provision would allow for more innovation and more meaningful quality assessment than is possible using only computable data that have been electronically “defined” for some other purpose. Moving to a tagged data element environment would allow much greater flexibility of quality assessments. It also would require improvement in CMS’s ability to receive more complex data as described above. With new resources and the charge from the PPACA, CMS should ensure that this flexibility is built into its future rulemaking.

CMS’s attempt to synergize the Physician Quality Reporting Initiative and meaningful use programs and reduce the reporting burden on physicians is a very reasonable approach during the first years of implementation, and is required by legislation. Going forward, however, quality improvement information will be richer, more secure, and timelier if gathered and delivered through Internet-accessible systems.

CMS needs to take specific actions that will demonstrate the value of tagged data element exchange. Adjusting fee-for-service payments based on currently reportable quality measures may spur at least some providers to become more sophisticated users of health IT. But it will not bring healthcare closer to the vision described in Chapter Two if the goal is only to achieve higher scores on specific measures. In Chapter Six, we discussed how CMS demonstrations projects such as the primary care medical home and accountable care organization models would shift the payment focus toward coordinated, integrated care. These models are potentially highly complementary to investments in health IT. CMS could further this connection and perhaps make these models more likely to succeed by requiring that demonstration sites have EHR technologies capable of more than reporting specified measures. These capabilities should include delivering and retrieving metadata-tagged, patient-centered, and patient-authorized information with other networks and sources such as PHRs and public health data aggregators. In addition, it will be important for CMS to document and publicly share what is learned about the contributions of such exchanges to the effectiveness of these new models and the results they achieve.

CMS needs a more aggressive program to support the growth of clinical decision support and secondary data uses. Chapter Three discussed the many problems with the “usability” of EHRs from the clinician’s perspective. Most of today’s systems do not format information in such a way that it reflects the decision-making and information-flow processes of medical care. Instead, their information display is codified in a series of “pages” that can hamper care while providers work through an electronic version of their written record. Software is needed that is more flexible and can deliver the relevant data that the physician and patient require at the point of care, including the ability to intelligently retrieve information for advanced clinical decision support (such as evidence-based guidelines, genetic information, and clinical trial results).

Federal policies also could seed the development of applications that can improve the capabilities of Federal and public health agencies to leverage large stores of electronic data to advance national health system objectives. Specifically, the Department of Health and Human Services should jumpstart an applications market through both requests for proposals and technology transfer agreements for the secondary use of EHR data. This market could result in the development of a very wide range of applications, including software to support pilot projects for benchmarking, coordination of new ONC objectives toward tagged data element ecosystems with entities developing adverse event and syndromic surveillance networks, tools and training to enable the gathering and input of research-quality data within a fully functional EHR, and the development of a test network for comparative effectiveness research.

Finally, we return to the serious challenge posed by CMS’s antiquated IT infrastructure, and the pressing need for its modernization, as has already been recognized by CMS leadership. CMS needs to ensure that it does not replace one inflexible architecture with another. While it is outside of our charge to anticipate the conclusions of a recently initiated National Research Council study of CMS information system capability, we would be surprised if a modern solution did not include most of the following elements: (1) a hardware infrastructure based on continuously upgradeable commodity data center technology; (2) a distributed, redundant, reliable storage system that logically presents as a unified, global file system; (3) a software infrastructure based on standard tools and APIs for distributed computing; (4) data consistency maintained by well-understood distributed transaction management protocols; (5) a well-specified protocol stack (most likely with remote procedure calls on top of TCP) and carefully specified interface formats. As discussed in Chapter Three, Federal IT projects of this magnitude frequently incur cost overruns and schedule slippages, and can take many years to complete. Rapid and otherwise achievable progress in health IT, as envisioned by ONC and (even more aggressively) by this report, could be forestalled or derailed if it becomes tied to CMS’s formidable IT challenges.

IX. Recommendations

A number of specific recommendations for the short- and mid-term follow from the discussions contained
in this report.

The Chief Technology Officer of the United States should:

  • In coordination with the Office of Management and Budget (OMB) and the Secretary of HHS, and using technical expertise within ONC, develop within 12 months a set of metrics that measure progress toward an operational, universal, national health IT infrastructure. Research, prototype, and pilot efforts should not be included in this metric of operational progress.
  • Annually, assess the Nation’s progress in health IT by the metrics developed, and make recommendations to OMB and the Secretary of HHS on how to make more rapid progress.

The Office of the National Coordinator should:

  • Move more boldly to ensure that the Nation has electronic health systems that are able to exchange health data in a universal manner based on metadata-tagged data elements. In particular,
  • ONC should signal now that systems will need to have this capability by 2013 in order to be deemed as making “meaningful use” of electronic health information under the HITECH Act.
  • Act to establish initial minimal standards for the metadata associated with tagged data elements, and develop a roadmap for more complete standards over time.
  • Facilitate the rapid mapping of existing semantic taxonomies into tagged data elements, while continuing to encourage the longer-term harmonization of these taxonomies by vendors and other stakeholders.
  • Support the development of reference implementations for the use of tagged data elements in products. Certification of individual products should focus on interoperability with the reference implementations.
  • Set standards for the necessary data element access services (specifically, indexing and access control) and formulate a strategic plan for bringing such services into operation in an interoperable and intercommunicating manner. Immediate priority should be given to those services needed to locate data relating to an individual patient.
  • Facilitate, with the Small Business Administration, the emergence of competitive companies that would provide small or under-resourced physician practices, community-based long-term care facilities, and hospitals with a range of cloud-based services.
  • Ensure that research funded through the SHARP (Strategic Health IT Advanced Research Projects) program on data security include the use of metadata to enable data security.

The Centers for Medicare & Medicaid Services should:

  • Redirect the focus of meaningful use measures as rapidly as possible from data collection of specified lists of health measures to higher levels of data exchange and the increased use of clinical decision supports.
  • Direct its efforts under the Patient Protection and Affordable Care Act toward the ability to receive and use data from multiple sources and formats.
  • In parallel with (i.e., without waiting for) the NRC study on IT modernization, begin to develop options for the modernization and full integration of its information systems platforms using modern technologies, and with the necessary transparency to build confidence with Congress and other stakeholders.
  • When informed by the preliminary and final NRC study reports, move rapidly to implement one or more of the options already formulated, or formulate new options as appropriate, with the goal of making substantial progress by 2013 and completing implementation by 2014. CMS must transition into a modern information technology organization, allowing integration of multiple components and consistent use of standards and processes across all the provider sectors and programs it manages.
  • Exercise its influence as the Nation’s largest healthcare payer to accelerate the implementation of health information exchange using tagged data elements. By 2013, meaningful use criteria should include data submitted through reference implementation processes, either directly to CMS or (if CMS modernization is not sufficiently advanced) through private entities authorized to serve this purpose.
  • By 2013, provide incentives for hospitals and eligible professionals to submit meaningful use clinical measures that are calculated from computable data. By 2015, encourage or require that quality measures under all of its reporting programs (the Physician Quality Reporting Initiative, hospitals, Medicare Advantage plans, nursing homes, etc.) be able to be collected in a tagged data element model.

The Department of Health and Human Services should:

  • Develop a strategic plan for rapid action that integrates and aligns information systems through the government’s public health agencies (including FDA, CDC, NIH, and AHRQ) and benefits payment systems (CMS and VA).
  • Convene a high-level task force to align data standards, and population research data, between private and public sector payers.
  • Convene a high-level task force to develop specific recommendations on national standards that enable patient access, data exchange, and de-identified data aggregation for research purposes, in a model based on tagged data elements that embed privacy rules, policies and applicable patient preferences in the metadata traveling with each data element.
  • As the necessary counterpart to technical security measures, propose an appropriate structure of administrative, civil, and criminal penalties for the misuse of a national health IT infrastructure and individual patient records, wherever such data may reside.
  • Appoint a working group of diverse expert stakeholders to develop policies and standards for the appropriate secondary uses of healthcare data. This could be tasked to the Interagency Coordinating Council for Comparative Effectiveness Research.
  • With FDA, bring about the creation of a trusted third-party notification service that would identify and implement methods for re-identification of individuals when data analysis produces important new findings.

Other or multiple agencies:

  • AHRQ should be funded to develop a test network for comparative effectiveness research. The FDA, and also other HHS public health agencies, should enable medical researchers to gain access to de-identified, aggregated, near-real-time medical data by using data element access services.
  • HHS should coordinate ONC activities with CDC, FDA, and any other entities developing adverse event and syndromic surveillance networks.
  • The Department of Defense and the Department of Veteran Affairs should engage with ONC and help to drive the development of standards for universal data exchange of which they can become early adopters.

References

1.

Network effect is defined as the user externality by which the more people who use a network, the greater its
value to each of them. The classic example is the rapid adoption of universal telephone service in the early 20th Century.

2.

Dr. Varmus resigned from PCAST on July 9, 2010 and subsequently became Director of the National Cancer Institute (NCI).

3.

Agency for Healthcare Research and Quality. 2010. Health Care Costs Fact Sheet. See
http://www.ahrq.gov/news/costsfact.htm

4.

Anderson, G., and P. Markovich. 2009. Multinational Comparisons of Health Systems Data, 2009. New York: The
Commonwealth Fund.

5.

Terms in bold-faced type the first time they appear in this report are defined in the glossary.

6.

Chaudhry, B., J. Wang, S. Wu, M. Maglione, W. Mojica, E. Roth, S. C. Morton, and P. G. Shekelle. 2006. Systematic review: impact of health information technology on quality, efficiency, and costs of medical care. Annals of Internal Medicine, 2144:742-752.

7.

Blumenthal, D. 2010. Launching HITECH. New England Journal of Medicine, 362:382-385.

8.

National Center for Health Statistics. December 2009. Electronic Medical Record/Electronic Health Record Use by Office-based Physicians: United States, 2008 and Preliminary 2009.

9.

The working group members are listed in page 7.

10.

P.L. 111-5, “American Recovery and Reinvestment Act of 2009” (ARRA), 111 th Congress.

11.

Foreshadowing discussion later in this report, a more technical description of the common framework is: (1) a universal extensible language for the exchange of health information based on “metadata-tagged data elements,” (2) a standard for a minimal set of metadata that specifically enforce privacy safeguards on each individual piece of data, and (3) the development of a secure national infrastructure, based on the technology of today’s web search engines, for locating and assembling all of a patient’s information for clinical encounters and (when de-identified) for public health purposes.

13.

Healthcare IT News (February 26, 2010) at http://www.healthcareitnews.com/blog...ate-ehr-safety

14.

Brownstein, J. S., C. Clark, B. S. Freifeld, E. H. Chan, M. Keller, A. L. Sonricker, S. R. Mekaru, and D. L. Buckeridge. 2010. Information Technology and Global Surveillance of Cases of 2009 H1N1 Influenza. New England Journal of Medicine, 362:1731-1735.

15.

For example, given an entry containing a laboratory test result, one might deduce the name of the physician who ordered the test from a case note with a corresponding date (context present, but implicit); but, for the case of an equipment recall, one might not at all be able to deduce the brand of medical equipment used (missing context).

16.

Provenance includes information about the data’s source and the processing that the data have undergone.

17.

Brynjolfsson, E, and L. M. Hitt. 1998. Beyond the Productivity Paradox: Computers are the Catalyst for Bigger Changes. See http://ebusiness.mit.edu/erik/bpp.pdf

18.

E.g., Garwin, R. L. 1968. Impact of Information-Handling Systems on Quality and Access to Health Care. Public
Health Reports, 83(5):346-351.

19.

See http://www.cdc.gov/nchs/data/hestat/...hr/emr_ehr.htm Primary care physicians and those practicing
in large groups, hospitals or medical centers, and the western region of the United States were more likely to use
electronic health records.

20.

A growing literature demonstrates a positive return on investment for EHRs in small practices, but the larger part of the benefit is not captured.

21.

Stead, W. W., and H. S. Lin, Eds. 2009. Computational Technology for Effective Health Care: Immediate Steps and Strategic Directions. Washington, DC: National Academies Press. http://www.nap.edu/catalog.php?record_id=12572

22.

Schiff, G. D, and D. W. Bates. 2010. Can Electronic Clinical Documentation Help Prevent Diagnostic Errors? New England Journal of Medicine, 362:1066-1069.

23.

Nass, S. J., L. A. Levit, and L. O. Gostin, Eds. 2009. Beyond the HIPAA Privacy Rule: Advancing Research, Improving Health Through Research. Washington, DC: National Academy Press. http://www.nap.edu/catalog.php?record_id=12458

24.

Asch, S. M., et al. 2004. Comparison of Quality of Care for Patients in the Veterans Health Administration and Patients in a National Sample. Annals of Internal Medicine, 141:938-945.

25.

VistA: Winner of the 2006 Innovations in American Government Award. 2006. See http://www.innovations.va.gov

26.

VA Receives 2006 Innovations in Government Award. 2006. See http://www1.va.gov/opa/pressrel/pres...se.cfm?id=1152

27.

VistA: Winner of the 2006 Innovations in American Government Award. 2006. See http://www.innovations.va.gov

28.

R. Kahn. 2010. Kaiser Permanente Completes Electronic Health Record Implementation. Available at http://xnet.kp.org/newscenter/pressr...rcomplete.html

29.

Fast Facts about Kaiser Permanente. Available at http://xnet.kp.org/newscenter/aboutkp/fastfacts.html

30.

Weissberg, J. Perspective: Electronic Health Records in a Large, Integrated Health System: It’s Automatic....NOT! At Least, Not Yet. National Quality Measures Clearinghouse.

31.

Kweder S. 2004. Vioxx and Drug Safety. Available at http://www.fda.gov/NewsEvents/Testimony/ucm113235.htm

32.

Chen, C., T. Garrido, D. Chock, G. Okawa, and L. Liang. 2009. The Kaiser Permanente Electronic Health Record: Transforming and Streamlining Modalities Of Care. Health Affairs, 28: 323-333.

33.

Ibid.

34.

“Sutter Health and Affiliated Palo Alto Medical Foundation Praised by U.S. Health and Human Services for IT Innovation.” 2005. See http://www.sutterhealth.org/about/ne..._pamf-ehr.html

35.

Academy Health. “HIT and HSR for Actionable Knowledge: Description of Partnering Health Systems. Partner:
Geisinger Health System.” See http://www.academyhealth.org/files/H...ystem_1wfs.pdf

36.

Pham, H. H., D. Schrag, A. S. O’Malley, B. Wu B, and P. B. Bach. 2007. Care Patterns in Medicare and Their Implications for Pay for Performance. New England Journal of Medicine, 356(11):1130-1139.

37.

Robert Wood Johnson Foundation. Aligning Forces for Quality. See http://www.forces4quality.org/welcome

38.

GAO. 2009. “Social Security Administration: Effective Information Technology Management Essential for Data Center Initiative,” GAO-09-662T.

39.

See, for example, GAO, 2008, ”Information Technology: Agencies Need to Establish Comprehensive Policies to Address Changes to Projects’ Cost, Schedule, and Performance Goals,” GAO-08-925; GAO, 2008, “DOD Business Systems Modernization: Progress in Establishing Corporate Management Controls Needs to Be Replicated Within Military Departments,” GAO-08-705; and GAO, 2008, “Environmental Satellites: Polar-Orbiting Satellite Acquisition Faces Delays, Decisions Needed on Whether and How to Ensure Climate Data Continuity,” GAO-08-518.

40.

Elm, J.P., Goldenson, D., El Emam, K., Donitelli, N., and Neisa, A. 2008. Survey of Systems Engineering Effectiveness—Initial Results. Carnegie Mellon University/SEI, CMU/SEI-2008-SR-034, at http://www.sei.cmu.edu/library/abstr...ts/08sr034.cfm

41.

Kibbe, D. C. 2010. Should Doctors Reject the Government’s EHR Incentive Plan? Family Practice Management, 17:8.

42.

There are exceptions, however. For example, in Massachusetts, 50% of all providers have comprehensive EHRs, and 33% of all medications are electronically prescribed.

43.

Sprott, D., and L. Wilkes. January 2004. Understanding Service-Oriented Architecture, Microsoft Architect Journal.

44.

eHealth Initiative. 2009. Migrating Toward Meaningful Use: The State of Health Information Exchange.

45.

However, a few interesting examples of HIEs working across state boundaries are starting to emerge.

46.

As a privacy choice, a patient might choose to hide even the existence of certain data from the DEAS, for example the fact that he/she had received treatment at a particular facility. In making such a choice, the patient would understand that his/her own future physicians would be unaware of this data, with possible negative effect on their ability to deliver the best care.

47.

World Health Organization 2007“Patient Identification”, Patient Safety Solutions, vol. 1, solution 2, at http://www.ccforpatientsafety.org/co...-Solution2.pdf

48.

Markle Foundation 2005 Linking Health Care Information: Proposed Methods for Improving Care and Protecting Privacy, at http://www.connectingforhealth.org/a...ort_2_2005.pdf

49.

See, e.g., J. Jonas, 2006, Threat and Fraud Intelligence, Las Vegas Style, IEEE Security and Privacy.

50.

Government Health IT. June 25, 2010. ONC to issue “rules of the road” for NHIN Exchange. See http://www.govhealthit.com/newsitem.aspx?nid=74064

51.

Currently installed systems that do not encrypt data “at rest” can be upgraded evolutionarily over time, but would be required to encrypt data “in transit” when it is shared with another system.

52.

NPR, Kaiser Foundation, and Harvard School of Public Health. March 2009. Cost, Privacy Top Health Care
Concerns.

53.

Electronic Privacy Information Center. Medical privacy public opinion polls.

54.

Lake Research Partners and American Viewpoint. November 2006. Survey Finds Americans Want Electronic
Personal Health Information To Improve Own Health Care.

55.

McGraw, D., J. X. Dempsey, L. Harris, and J. Goldman. 2009. Privacy as an Enabler, Not an Impediment: Building
Trust into Health Information Exchange. Health Affairs, 28(2):416-27.

56.

45 CFR Parts 160 and 164. Summaries at http://www.hhs.gov/ocr/privacy/hipaa...ing/index.html

57.

See, for example, Health IT Policy Committee, Privacy and Security Tiger Team, transcript of Consumer Choice Technology Meeting (June 29, 2010), at
http://healthit.hhs.gov/portal/serve...3&PageID=19477

58.

The need to have an unbiased second opinion may be an exception to this principle.. Henriksen K. and H. Kaplan, H. 2003. Hindsight bias, outcome knowledge and adaptive learning Quality and Safety in HealthCare 12:ii46-ii50,

59.

Armstrong, D., E. Kline-Rogers, S. M. Jani, et al. 2005. Potential Impact of the HIPAA Privacy Rule on Data Collection in a Registry of Patients with Acute Coronary Syndrome. Archives of Internal Medicine, 165:1125-1129.

60.

J.F. Wilson. 2006. Health Insurance Portability and Accountability Act Privacy Rule Causes Ongoing Concerns Among Clinicians and Researchers. Annals of Internal Medicine 145(4):313-316.

61.

Public Law 111-5 (2009), especially Sec. 13405 (42 USC 17935), at http://www.hhs.gov/ocr/privacy/hipaa...ct.pdf#page=39

62.

Nass, S. J., L. A. Levit, and L. O. Gostin, Eds. 2009. Beyond the HIPAA Privacy Rule: Advancing Research, Improving Health Through Research. Washington, DC: National Academy Press. http://www.nap.edu/catalog.php?record_id=12458

63.

But see, for example, PI Newswire, “Medical Records Found in DMV’s Dumpster,” June 3, 2010, at http://www.pinewswire.net/2010/06/me...-dmvs-dumpster

64.

For examples, see “Celebrity Medical Records in Massive UCLA Breach” at http://www.huffingtonpost.com/2008/0..._n_116968.html, and “Exposed: Clooney’s Medical Records” at http://abcnews.go.com/GMA/story?id=3711136&page=1

65.

InformationWeek January 30, 2008. “Laptop Stolen With Personal Data On 300,000 Health Insurance Clients,” at http://www.informationweek.com/news/...leID=206100526

66.

WBBM Chicago May 27, 2010. “Nearly 200,000 Are Potential ID Theft Victims,” at http://cbs2chicago.com/investigation...2.1719905.html

67.

While the breach notification requirements of HITECH provide significant incentives for encryption, they do not require it.

68.

Markle Foundation (2006) Implementing a Trusted Information Sharing Environment: Using Immutable Audit Logs to Increase Security, Trust, and Accountability. at http://www.markle.org/downloadable_a...IAL_020906.pdf

69.

Abigail has chosen to exclude from indexing, for example, that as a teenager she was once treated for a drug overdose.

70.

Halamka, J. November 11, 2009 The Magic of Middleware. Life as a Healthcare CIO, at
http://geekdoctor.blogspot.com/2009/...iddleware.html

71.

Office of the National Coordinator. May 26, 2010. Beacon Community Program. Available at http://healthit.hhs.gov/portal/serve...=2&cached=true

72.

Stytz, M., et al. 2010. Electronic Patient Health Record Technology: Status and Challenges. Washington, DC: STPI.

73.

John Halamka, personal communication, based on 2000-2010 Beth Israel Deaconess Medical Center data.

74.

USA Today. October 25, 2009. “R.I. Tracks H1N1 with Electronic Data,” at http://www.usatoday.com/news/nation/...tracking_N.htm

75.

Kweder S. November 18, 2004. “Vioxx and Drug Safety.” Available at http://www.fda.gov/NewsEvents/Testimony/ucm113235.htm

76.

Nissen, E., and K. Wolski. 2007. Effect of Rosiglitazone on the Risk of Myocardial Infarction and Death from Cardiovascular Causes. New England Journal of Medicine, 356(24):2457-2471.

77.

Alliance for Health Reform. March 2006. “Racial and Ethnic Disparities in Health Care.” Available at http://www.allhealth.org/publications/pub_38.pdf

78.

Cohen, H., G. Williams, J. Johnson, J. Duan, J. Gobburu, A. Rahman, K. Benson, J. Leighton, S. Kim, R. Wood, M. Rothmann, G. M. Chen, M. Staten, and R. Pazdur. 2002. Approval Aummary for Imatinib Mesylate Capsules in the Treatment of Chronic Myelogenous Leukemia. Clinical Cancer Research, 8(5):935-942.

79.

National Cancer Institute. Beta-Carotene Supplements Confirmed as Harmful to Those at Risk for Lung Cancer. Available at http://www.cancer.gov/clinicaltrials...inal-CARET1204

80.

Gold, T., T. Do T, and W. Dick. 2008. Correlates and Effect of Suboptimal Radiotherapy in Women with Ductal Carcinoma in Situ or Early Invasive Breast Cancer. Cancer, 113(11):3108-3115.

81.

W. H. Press. 2009. Bandit Solutions Provide Unified Ethical Models for Randomized Clinical Trials and Comparative Effectiveness Research. PNAS. 106:22387-22392.

82.

“Health Level Seven International” at http://www.hl7.org/

83.

World Health Organization. “International Classification of Diseases (ICD)” at http://www.who.int/classifications/icd/en/

84.

The United States Health Information Knowledgebase (USHIK), maintained by AHRQ, maintains metadata on many healthcare-related data standards that could be considered for rapid incorporation. See http://ushik.ahrq.gov/index.html

85.

The crux of the argument in Chapter Six is that this is a public good problem. Market incentives are lacking for private firms to invest in universal exchange capabilities, because they cannot appropriate the benefit

86.

Gray, J., “A Conversation with Tim Bray.” February 16, 2005. http://queue.acm.org/detail.cfm?id=1046941

87.

Although the reported data consists of aggregated counts, not individual patient data, a tagged metadata format can also be applied to this type of data.

88.

Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology at http://HealthIT.HHS.gov/standardsandcertification

89.

Leatherman, S., and A. Epstein. 2010. Performance Measurement for Health System Improvement. Cambridge, UK: Cambridge University Press.

90.

Darves, B. June 2008. “Ensuring—and Tracking—Physician Competence.” New England Journal of Medicine Career Center. at http://www.nejmjobs.org/career-resou...ompetence.aspx

91.

Gawande, A. 2009. The Checklist Manifesto: How to Get Things Right. New York: Metropolitan Books.

Appendices

Appendix A: Expert Input

Expert Input into Health Information Technology Report. PCAST is grateful for the input of these individual experts. Listing here does not imply endorsement of this report or its recommendations.

Jonathan Bush
Chief Executive Officer
Athenahealth

David Blumenthal
National Coordinator
Office of the National Coordinator for Health Information Technology
Department of Health and Human Services

Julie Boughn
Director and Chief Information Officer, Office of Information Services
Centers for Medicare & Medicaid Services

Aneesh Chopra
Chief Technology Officer
Associate Director for Technology
Office of Science and Technology Policy

Janet Corrigan
President and Chief Executive Officer
The National Quality Forum

Peter Cullen
Chief Privacy Strategist
Microsoft Corp.

Nancy-Ann DeParle
Director, White House Office of Health Reform

Mary Durham
Senior Investigator
Director, Center for Health Research
Vice President for Research
Kaiser Foundation Hospitals

Spike Duzor
Director, Division of Survey Management & Data Release
Centers for Medicare & Medicaid Services

Carl Dvorak
Executive Vice President
Epic

Sean Eddy
Group Leader
HHMI Janelia Farm Research Campus

Colin Evans
President and Chief Executive Officer
Dossia

Craig Feied
Professor of Emergency Medicine at Georgetown University
Chief Health Strategy Officer, Microsoft Corp.

Douglas Fridsma
Acting Director, Office of Interoperability and Standards
Office of the National Coordinator for Health Information Technology
Department of Health and Human Services

Charles Friedman
Chief Scientific Officer
Office of the National Coordinator for Health Information Technology
Department of Health and Human Services

John Glaser
Senior Advisor
Office of the National Coordinator for Health Information Technology
Department of Health and Human Services

Arthur Glasgow
Senior Vice President and General Manager of Health Information Networks
Ingenix

Richard HodesDirector
National Institute on Aging
U.S. National Institutes of Health

Marjorie Kanof
Managing Director, Health Care
Government Accountability Office

Martha Kelly
Assistant Director, Health Care
Government Accountability Office

Carl Kesselman
Professor of Industrial and Systems Engineering
Fellow in the Information Sciences Institute Viterbi School of Engineering
University of Southern California

David Kreiss
Senior Executive
Athenahealth

David C. Kibbe Senior Advisor, American Academy of Family Physicians
Chair, ASTM International E31 Technical Committee on Healthcare Informatics
Principal, The Kibbe Group LLC

Robert Kocher
Special Assistant to the President for Health Care
National Economic Council

S. Lawrence Kocot
Deputy Director, Engelberg Center for Health Care Reform
The Brookings Institution

Rebecca Kush
Founder, President, and Chief Executive Officer
Clinical Data Interchange Standards Consortium (CDISC)

Kipp Lassetter
Chairman and Chief Executive Officer
Medicity

Kenneth Mandl
Associate Professor
Children’s Hospital Boston|Harvard Medical School Harvard-MIT Health Sciences and Technology

Mark McClellan
Director, Engelberg Center for Health Care Reform
Leonard D. Schaeffer Chair in Health Policy Studies
The Brookings Institution

Deven McGraw
Director, Health Privacy Project
Center for Democracy and Technology

Andrew McLaughlin
Deputy Chief Technology Officer
Office of Science and Technology Policy

Farzad Mostashari
Senior Advisor
Office of the National Coordinator for Health Information Technology
Department of Health and Human Services

Sean Nolan
Chief Architect, Health Solutions Group
Microsoft Corp.

Betty Otter-Nickerson
President
Sage
Healthcare Division

Todd Park
Chief Technology Officer
Office of the National Coordinator for Health Information Technology
Department of Health and Human Services

Daniel Pelino
General Manager, Health Care and Life Sciences
IBM

Richard Platt
Professor and Chair, Harvard Medical School Department of Population Medicine
Harvard Pilgrim Health Care Institute

Thomas Reilly
Deputy Director, Office of Research, Development, and Information
Centers for Medicare & Medicaid Services

Andrew Slavitt
Chief Executive Officer
Ingenix

Jean Slutsky
Director, Center for Outcomes and Evidence
Agency for Healthcare Research and Quality
U.S. Department of Health and Human Services

Barry Straub
Chief Medical Officer
Centers for Medicare & Medicaid Services

Marilyn Tavenner
Principal Deputy and Chief Operating Officer
Centers for Medicare & Medicaid Services

Tony Trenkle
Office of E-Health Standards & Services
Centers for Medicare & Medicaid Services

Adindu Uzoma
Senior Fellow and Chief Scientist
Ingenix

Thomas Valuck
Senior Vice President, Strategic Partnerships
National Quality Forum

Janet Woodcock
Director, Center for Drug Evaluation and Research
U.S. Food and Drug Administration

Appendix B: Acknowledgments

Joe Alper
Writer

Aman Bhandari
Policy Analyst
Office of Science and Technology Policy

Kathleen Black
Intern
Office of Science and Technology Policy

Judith Hautala
Core Research Staff Member, Life Sciences
Science Technology Policy Institute

Peter Haynes
Senior Director, Advanced Strategies and Research
Microsoft Corp.

Steve Olson
Writer

Christina Viola Srivastava
Research Associate
Science Technology Policy Institute

Mark Shankar
Intern
Office of Science and Technology Policy

Leslie Tucker
Policy Director
American Board of Internal Medicine

Appendix C: Glossary

Anonymize

removing all personal identifiers from data

Authentication

Determining the identity of a principal

Authorization

Determining the rights of an authenticated principal

Clinical decision support

Bringing relevant information to the clinician, at the right time and place, to enable optimal health care

Cloud-based

A technology that allows software to be run and data to be stored on remote servers

Comparative effectiveness research

Research that informs clinical decisions by comparing evidence on the benefits, harms, and effectiveness of different treatments

Data element access services

Services that are associated with crawling, indexing, security, identity, authentication, authorization, and privacy

Data-centric

A focus on the specific data relevant to a given task

Data element indexing

Process and infrastructure for locating data elements, similar to today’s web search engines

De-identified

Data with all patient identifying information removed, but with the possibility of providing information back to the patient under specified circumstances

Digital signature

Cryptographic method for ensuring that data cannot be altered except by the person who created them.

Electronic health record

An electronic record of health-related information for an patient that contains information captured in clinical visits, lab and imaging studies, and other information important to the patient’s medical past

Encryption

Technology of making data completely unreadable except by a person in possession of the corresponding “key”

Genotype

The genetic makeup of a specific human being

Health information exchange

The mobilization of electronic healthcare information across organizations within a community, region, or hospital system

Health information technology

Technologies that manage and transmit health information for use by providers, consumers, payers, insurers, and all the other pertinent groups

HITECH Act

An act passed by Congress in 2009 that authorizes expenditures of approximately $20 billion over five years to promote the adoption and use of electronic health record technologies that would be connected through a national health information network

Integration engines

An application of a universal exchange language that can facilitate data exchanges with personal health records and other types of EHRs in a cloud

Key

A piece of data that can unlock and make readable cryptographically protected information

Meaningful use

Still pending an official definition from CMS, but ARRA requires that the definition include e-prescribing, the ability to exchange information with other healthcare providers to improve care, and the reporting of clinical quality measures to CMS

Metadata

Information that characterizes data, such as contextual information

Metadata tag

A tag accompanying each piece of data describing the attributes, provenance, and required security protections of that piece of information

Middleware

Software used to extract and reformat data elements from existing clinical systems

Patient-centric

Healthcare organized around the needs, capabilities, and desires of patients, with the goal of optimizing care in part through greatly improved uses of data

Personal health record

An electronic record of health information that is maintained, controlled, and shared by a patient-consumer

Personalization

Tailoring medical care to be optimized for the unique individual characteristics of the particular patient

Physician Quality Reporting Initiative

Established under the 2006 Tax Relief and Health Care Act, the initiative provides physicians with a financial incentive to voluntarily provide CMS with a report on three or more chosen quality measures that applies to their Medicare patient base

Post-marketing surveillance

A system by which to identify adverse events that did not appear during the drug approval process

Primary care medical home

A model of care that places the patient and primary care physician at the center of a virtual organization that is paid a fee to coordinate all care the patient receives from specialists and other providers

Randomized clinical trials

A type of clinical trial in which participants are randomly assigned to different forms of treatment

Semantics

The clinical or operational meaning of data

Service-oriented architecture

An approach to health IT that involves using software policies, practices, and frameworks to enable one user to access sets of “services” on another party’s computers and data

Standardized health records

Health records that follow a standardized format that is comparable to all other formats and can be accessed by all necessary parties

Syndromic surveillance

Surveillance using health-related data that precedes diagnosis and signals a sufficient probability of a case or an outbreak to warrant a further public health response

Syntax

The formatting of data that are exchanged, as well as the details of the exchange protocols, including privacy protection and other important aspects

Tagged data elements

Data accompanied by metadata describing the attributes and privacy protections of the data

Two-factor authentication

The use of two of the following three in determining the identify of a principal: physical credentials (such as smartcards), biometrics (such as fingerprints), and a secret (such as a password)

Universal exchange language

A common language and format in which all electronic health systems can exchange data

Usability

The ease with which physicians and other healthcare providers can learn to use electronic records, capture data from clinical encounters, and then make use of the data to improve care delivery

Value-based purchasing

The concept that buyers should hold providers of health care accountable for both the cost and quality of care

VistA

An integrated system of software applications that directly supports patient care at Veterans Health Administration facilities

XML

Also known as extensible markup language, a set of rules for encoding documents in machine-readable form

Appendix D: Abbreviations

ACO–Accountable Care Organization
AHRQ–Agency for Health Care Research and Quality
ARRA–American Recovery and Reinvestment Act
CDA–Clinical Document Architecture
CDC–Centers for Disease Control & Prevention
CDS–Clinical Decision Support
CMS–Centers for Medicare & Medicaid Services
EHR–Electronic Health Record
FDA–Food and Drug Administration
HIE–Health Information Exchange
HHS–U.S. Department of Health and Human Services
HIPAA–Health Insurance Portability and Accountability Act
HL7–Health Level 7, Inc.
IHE–Integrating the Healthcare Enterprise
IOM–Institute of Medicine
ONC–Office of the National Coordinator
NHIN–Nationwide Health Information Network
NIST–National Institute of Standards and Technology
PCIP–Primary Care Information Project
PCMH–Primary Care Medical Home
PHR–Personal Health Record
PPACA–Patient Protection and Affordable Care Act
RHIO–Regional Health Information Organizations
SHARP–Strategic Health IT Advanced Research Projects
VHA–Veterans Health Administration

Page statistics
3125 view(s) and 82 edit(s)
Social share
Share this page?

Tags

This page has no custom tags.
This page has no classifications.

Comments

You must to post a comment.

Attachments