Health IT Journey - Stories from the Road Register for CMS Electronic Health Record Incentives
ONC Seeks Comment on Standards and Interoperability Framework Initiatives by December 23, 2010
Friday, December 10th, 2010 | Posted by: Jonathan Perlin MD and John Halamka MD Chair Co-Chair HIT Standards Committee | Category: FACA, HIT Standards Committee

Standards & Interoperability Framework Initiatives

The Health IT Standards Committee (HITSC) would like your thoughts and comments on new initiatives being considered by the Office of the National Coordinator for Health Information Technology (ONC) through the Standards and Interoperability (S&I) Framework.

The objective of the S&I Framework is to create a robust, repeatable process that will enable ONC to execute on initiatives that will help improve interoperability and adoption of standards and health information technology. The S&I Framework includes processes and tools that will streamline and coordinate the execution of the initiatives to support the goals of the ONC and the HITECH Act.

More specifically the S&I Framework will enable:

  • Linkage of objectives, challenges, use cases, requirements, and standards across the solution development lifecycle; e.g., pre-discovery, discovery, implementation, pilot, and evaluation
  • Repeatable mechanisms for harmonization and integration of existing standards  as well as identification of new standards
  • Development of tools that enable consistent, robust, and testable solutions; e.g., test suite to validate an implementation against a specification
  • Integration of multiple Standard Development Organizations (SDOs) with different expertise across the solution development lifecycle
  • Leveraging of federal guidance and best practices

More detail on the S&I Framework is available here [PDF - 1.8 MB] (Refer to pages 9-18)

The S&I Framework will be utilized to execute on a number of initiatives – each of which will seek to address a challenge that exists today. Initial efforts have resulted in the development of a set of materials and tools, including the Prioritization Framework [XLS - 78KB], and Proposed Initiative Summaries [PPT - 1.2MB].

The Health IT Standards Committee would like your comments by December 23 on these materials, which will inform the set of Initiatives that will be executed through the S&I Framework.

Prioritization Framework: The Prioritization Framework provides a set of criteria that can be applied to guide the prioritization of initiatives and their development through the S&I Framework. The criteria are grouped into four broad categories: Importance/Relevance, Feasibility, Usability, and Evidence-Based Medicine & Research Support. These four categories are aligned to the four-domain scheme proposed by the National Quality Forum (NQF) and based on previous work done by the National Committee for Quality Assurance (NCQA), Institute of Medicine (IOM), The Joint Commission, and the Centers for Medicare & Medicaid Services (CMS) to capture criteria that evaluate quality measures. These categories are further described within the document.

The Prioritization Framework is the proposed approach moving forward to analyze future initiatives and priorities raised across the health care community. It will apply to both short- and long-term priorities. Short-term priorities are driven by support for Meaningful Use requirements and the Nationwide Health Information Network, including the Virtual Lifetime Electronic Record (VLER). Long-term prioritization focuses on broader requirements, challenges, and goals of the U.S. health care system and its communities.

The Prioritization Framework is currently a template and in spreadsheet format with different tabs covering instructions, a glossary, and the criteria descriptions. The Prioritization Framework can be found here [XLS - 78KB].

As you review the Prioritization Framework, your responses to the questions below and additional comments would be appreciated.

  • Are the current criteria appropriate and sufficient to evaluate Initiatives?
  • Are there additional criteria within the four categories that should be included?
  • ONC will be using the Prioritization Framework to evaluate future initiatives that may pass through the S&I Framework. We would ask you to review the proposed initiatives executive summaries using the Prioritization Framework. We would also ask you to apply weightings on these criteria as your review the initiatives, based on the level of importance you attach to each criteria, and also to use the Prioritization Framework to score new initiatives you may propose as part of your comments. We will use this feedback to evaluate the criteria in the Prioritization Framework and the various weightings that could be used to score initiatives.

Proposed Initiative Executive Summaries: This document includes a portfolio of several initiatives under consideration, for review and selection by ONC leadership, in consultation with appropriate steering bodies and advisory groups. These summaries include results of the initial analysis conducted by internal ONC staff and contractors to determine specific short-term priority investment to be undertaken by the S&I Framework project. Each initiative would represent important steps for ONC and the national health care community necessary to improve outcomes through the use of health information technology. These summaries can be found here [PPT - 1.2MB].

As you review the Initiative Executive Summaries, your responses to the questions below and additional comments are appreciated.

  • Is the challenge statement listed for each initiative accurate? What are your general thoughts about this challenge statement? Is it an important initiative to you and the stakeholder community you work in or represent?
  • Is the scope of the initiative acceptable, and if not, what changes would you suggest?
  • Are the outcomes specified for each initiative reasonable and achievable, and if not, how would you refine them?
  • What additional initiatives are not included that should be considered by ONC and the HITSC? Please provide specific details on the challenge statement of the initiative, and the scope of the initiative you are proposing.

Your thoughts and comments in this process would be helpful as ONC develops the Standards & Interoperability Framework and launches future initiatives.

  • Jonathan Perlin, MD, Chair, Health IT Standards Committee
  • John Halamka, MD, Co-Chair, Health IT Standards Committee

Tags: ,

31 Responses to “ONC Seeks Comment on Standards and Interoperability Framework Initiatives by December 23, 2010”

  1. Scott Serich says:

    One area that seems to be overlooked is whether an initiative will contribute long-term economic benefits to the community of interest with regard to its ongoing, overall information technology investments. The Prescription Drug Monitoring Information Exchange (PMIX) initiative (http://www.pmpalliance.org/content/prescription-monitoring-information-exchange-pmix) is establishing an infrastructure for the sharing of prescription controlled substance dispensing history data between state monitoring programs (perhaps to also eventually include federal, territorial, and tribal interests). The project has been progressing under an assumption that it is in the best long-term interest of the states to invest in a standardized NIEM data model (ref. Webber’s comments below) and a GRA/JRA service-oriented architecture (http://it.ojp.gov/default.aspx?area=nationalInitiatives&page=1015). The project is also exploring opportunities to exploit the GFIPM standard (http://it.ojp.gov/default.aspx?area=nationalInitiatives&page=1179) for standardized security and identity management.

    From a national perspective (Constitutional considerations aside), there is constant pressure to demonstrate the value of having many distinct monitoring programs rather than a single nationwide repository. It is believed by at least some of us in the information sharing world that the only way the distributed solution stands a chance of competing economically with the centralized approach is if the former is based heavily on “open” standards (royalty free, widely adopted). By adopting these standards, when the occasion arises for the distributed solution to address problems that cross state boundaries or have become nationwide, the highly standardized infrastructure should enable an economical sharing of data (and design artifacts and even policies). In other words, the economic payback of interoperability and reuse can be leveraged at multiple levels.

    In taking a lesson-learned from this initiative, it’s not clear that the value of an initiative in helping a target community (and spillover beneficiaries) achieve longer-term IT investment protection is included in the S&I Framework’s list of criteria. Perhaps it’s already included under the “Potential to drive sustainability of S&I Framework” Importance / Relevance criterion. If so, then perhaps it’s already being addressed. Otherwise, it doesn’t seem to receive any explicit emphasis elsewhere framework, and I would urge that something along these lines be added.

    The economic foundations for these arguments can be found in the network effect and lock-in literature. More specific studies regarding the value of interoperability standards in have also been produced (e.g., http://egy.org/files/ROI_Study.pdf).

    Thanks.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)

    • Scott Serich says:

      P.S. As a tactical matter, the characterization of standards adoption (whether by buyers acquiring IT capabilities or sellers incorporating them into their products and services) as “avoiding translation costs” in attempting to achieve interoperability with future exchange partners may be more palatable than “adopting standards”, which tends to emphasize a more affirmative commitment of resources (and could be particularly unattractive for organizations under financial stress right now).

      Like or Dislike: Thumb up 1 Thumb down 1 (0)

  2. Comments on S&I Framework PROPOSED INITIATIVE SUMMARIES
    The summaries are quite high-level and several of them require clarification as they have multiple possible interpretations. Specific requirements for each of the initiatives should be added. A one page slide is insufficient to communicate the depth necessary to evaluate the proposals. A short summary, perhaps three pages in length, would better describe the specific requirements and use anticipated for each of the initiatives. Such a “scope statement” is a requirement of most initiatives in the real world. Executives are not expected to approve a project based on a one page slide.
    Many of the initiatives seem to be solution rather than requirements driven. More specifically, they propose a specific solution to a problem rather than the set of requirements which should be driving the solution. In some cases, this is a result of ongoing efforts (e.g., Clinical Summaries and Templated CDA) which have already established requirements and are into design stages. But other cases prematurely address solutions. More attention should be paid to requirements.

    1. Clinical Summary
    The proposal contains several elements, of diverse relevance.
    a. There are more than 200 ONC-ATCB Certified products as of December 17th. More than half of these are Complete EHRs. This demonstrates implementability of the HITSP C32 Version 2.5 specification. This specification now has solid acceptance resulting from years of consensus work performed in the 2006-2009 period. Challenges stem from two places: Multiple sources for documentation, and the variety of options for standards specified in the Certification regulation.
    b. The proposal must be explicit in leveraging previous work: HITSP C32/C83, IHE content profiles, HL7 Implementation Guides. This is critical for time to specify and implement
    c. Implementation should be the primary focus of this initiative. We agree that specification/implementation tools with MDHT and the IHE/HL7/HS convergence & collaboration should be the primary focus.
    d. Complexity, actual and perceived needs to be managed. Some of the actual complexity is generated by selection of multiple standards in stage 1 (e.g. multiple code sets, driving two different standards). Simplicity comes from converging to a single standard, CCD, and help implementers/vendors with implementation tools (MDHT).
    e. There is an absolute need for consistency with the templating initiative. Much of the Summary content will be reused in other templated documents. An identical standards base is required for simplicity.

    2. Templated Clinical Documents
    The proposal and its scoping is generally on-track, with the following suggested adjustments:
    a. Initiative should support direction and templating established by previous work: HITSP C32/C83, IHE content profiles, HL7 Implementation Guides. This is critical to complete this project by its proposed deadline. This initiative should “recognize” a library of “content modules” to be flexibly assembled in a family of documents. This moves the focus away from the document itself and towards its modular content (data element/sections) so that a variety of consistent documents may be easily implemented.
    b. Vocabularies (value sets) associated with these content modules need to be addressed within this initiative, and they have to be made single for simplicity, with when necessary secondary value sets included only as glide path for convergence.
    c. Not clear if the outcome to be measured is at the specification creation time or at the software implementation time. The principles of the S&I framework should be applied rather than making up outcome numbers.
    d. Implementation should be the primary focus of this initiative. Agree that specification/implementation tools with MDHT and the IHE/HL7/HS convergence & collaboration should be the primary focus.
    e. Complexity, actual and perceived needs to be managed. Some of the actual complexity is generated by selection of multiple standards in stage 1 (e.g. multiple code sets, driving two different standards). Simplicity comes from converging to a single standard, CDA with CCD templates, and to help implementers/vendors with implementation tools (MDHT).
    f. There is an absolute need for consistency with the clinical summary initiative. Much of the Summary content will be reused in other template documents. An identical standards base (CDA Release 2) is an absolute requirement to realize simplicity.

    3. Lab Interface Improvement
    The focus of the initiative need not be on the profiling specification. The implementation specs have been done by HITSP & HL7. The value sets for lab test and orders codes also have been specified or are presently in progress (LOINC-Results, LOINC-Orders, HITSP value sets, and CSTE/CDC work on reportable conditions).
    The focus must be on the deployment/adoption/certification by BOTH ENDS. So far MU focuses on EHR standards, testing and certification, but nothing is done for labs (e.g. extend CLIA). Unless the lab side is addressed at the policy level, this initiative, as all previous ones is unlikely to deliver any of the expected outcomes.
    ONC should focus on supporting existing efforts in HL7 (Implementation Guides), testing (e.g., IHE Connectathons), and value set development (LOINC and NLM).
    4. Med reconciliation improvement
    The problem statement and interoperability related scope for this initiative need much clarification:
    a. The exchange of medication data is already covered by medical summaries and prescription. Main remaining gap is to rationalize/converge the vocabularies in medication (MU Stage 1 current multiple choices have amplified the issue, and glide path need to be reaffirmed with timeline).
    b. As defined, this seems to be primarily an application functionality effort, not an interoperability one.
    c. Recommends accelerate/support IHE Reconciliation Profile due to be completed by summer 2011. This profile defines the interoperability data elements to be used as input and output to reconciliation, not the reconciliation algorithms). Do not duplicate/detract these on-going efforts.

    5. Provider Directories
    The scope and expected outcome of this initiative appear very immature:
    a. Initiative seems to ignore the main challenge which is how to keep such directories accurate and trust worthy (back office). This will drive adoption and use, and any of the desired outcomes. This management of the directory content is even more complex in a federated directory environment, which is mentioned, without realization of the complexity of the implied policies.
    b. Proposal is to reduce the scale of the initiatives on leveraging the IHE HPD profile and driving its open source implementations.
    c. The scope need to be assessed in the context of business use cases (not a technology use case) in which such provider directories will bring value (the SSA did this when defining with IHE the HPD profile). Once these use cases resulting in the use of a provider directory are made explicit then the initiative outcome can be evaluated.

    6. Syndromic Surveillance
    a. ISDS use case is a good start for hospital syndromic surveillance, but not for ambulatory care syndromic surveillance. This point should be made explicit in the scope and if the ambulatory environment is also targeted, the schedule should be adjusted to allow for appropriate research to be conducted (this does not seem appropriate for the S&I Framework).
    b. HL7 should develop the implementation guide along with IHE to support the deployment/Connectathon testing (a part of the S&I testing process). This testing process needs to involve BOTH ENDS (EHR and public health systems) in order to enable deployment/adoption/certification.
    c. One statement appears concerning in an ONC issued document. It references ongoing “work conducted by ISDS and CDC to develop Stage 1 meaningful use recommendations for syndromic surveillance”. MU Stage 1 is already defined and ongoing work may only feed Stage 2 or 3.

    7. Quality Measures
    The challenge and the scope are inconsistent: is this initiative about defining measures or a format to convey quality data?
    a. If a reporting format base standard is needed to replace PQRI, this work is in progress at HL7. One needs to establish a measure specific profile/ Implementation Guide and testing, with vocabularies/value sets selected. Given the base standards calendar, the needed profiling, and the testing/adoption process, the proposed schedule may not be realistic. This should be planned for 2015 implementation as a PQRI replacement (not for stage 1, as it is defined, and attempts to change that would be disruptive).
    b. If it is about defining measures, we recommend that much attention be placed on the harmonization of the vocabularies in quality measures and with those used in clinical care data to avoid unspecified mappings.
    c. It is not clear what “a quality measure development standard” is expected to address, as stated as one of the expected outcomes

    8. Population Health Query
    The scope of the initiative is unclear and appears quite immature:
    a. It is not possible to discern which way the query is performed, is it public health querying or being queried? Both ways are implied. What is a “public data source”, an EHR?
    b. This is a very broad topic (all of public health!) and depth of data, and it seems to be a simplistic idea that has not been “vetted”. It sounds like the expectation is to have the all-encompassing “clinical data query”. This may be unrealistic.

    9. Clinical Decision Support
    The scope of the initiative is extremely broad and needs much refinement:
    a. The challenge and the outcome are speaking of two different use cases:
    i. defining the exchange of the CDS rules (in some computable language)
    ii. defining the data to be used as input to and output form a CDS service provider
    b. Depending on the type of CDS problem to be addressed, the focus should be sometimes on (i) defining the exchange of the CDS rule language, and in other cases focus on (ii) defining the data needed as input to and output from a “CDS service provider”.
    c. To be effective this initiative needs to identify a series of specific uses of CDS. Unless the scope is more use case specific, this initiative cannot be evaluated and the expected outcome measured.

    10. Blue Button
    The proposal is quite immature and difficult to understand as documented. What are the use cases? Seems a technical solution to an undefined problem:
    • Is the problem to make the display of summary (e.g. CCD/C32) with minimal effort by the patient?
    • Is it one way to the patient? Does the patient need to be able to have that data imported into a home computer, or a PHR and back to another EHR?
    • Last bullet in target outcomes appears the wrong way: how can one map text to C32?
    • MU Stage 1 is already beyond the blue button. Is there a need for another standard format for a summary?

    11. Green Button
    The objective to get all the data form an EHR product to another one is rather unbounded (especially given the diverse customization made by each provider organization).
    The initiative should be recast to primarily leverage the current/near term state of the art in interoperability (e.g. sets of templated CDAs). By becoming a bi-product of other existing interoperability use cases, adding only a “packaging” mechanism, one should be able to transfer the key data from an EHR installation to another one.
    The outcome should be made dependent on (fed by) the outcome of other initiatives. This should be scheduled in a second phase rolling out on the tail of a core set of specific interoperability use cases.

    12. Value Set Development
    Value set development cannot be performed effectively outside of the primary use case for which it is only a part of the overall solution to a business use case. This is already obvious within these set of proposed initiatives: for example lab results and orders value sets should be integral to the laboratory interface initiative (this is already the case, with the ongoing work by LOINC and CSTE).
    It is proposed to no longer address the value set definition as a stand-alone effort and to reduce the scope of this initiative to the infrastructure needed to support value set distribution, all the way to all provider applications. Suggestion is to leverage IHE to get this done (e.g. IHE SVS-Sharing of Value Sets).
    The tools needed to define and manage value sets need to be addressed. This is a complex multi-stakeholder issue, as value set definitions will come from multiple sources. This is a very different issue than the interoperability to “distribute/access” already defined value sets that IHE SVS addresses.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)

  3. Comments on S&I Framework PRIORITIZATION FRAMEWORK

    This prioritization framework is a good start. There are however four significant gaps:

    a. Deadlines for the program of work are very aggressive, and need to take into account the ability of stakeholders to adopt the technology. It must be coordinated with other federal efforts impacting healthcare IT, including the transition to ICD-10 and 5010 specifications. Individually, each goal may be achievable, but taken together as an overall program of work this does not seem to account for the overall capacity of vendors and providers to adopt ALL of the proposals.

    b. It is necessary to account for the S&I Framework governance and operations. Feasibility will depend largely on the constraints associated with relying on existing SDOs and work underway in these organizations. EHRA hopes that the S&I will work with existing SDOs (HL7, IHE, etc). Duplicating existing operational structures would not only add significant delays but risk in duplicating efforts already underway at the international level. This would considerably detract from these efforts, and slow market adoption.

    c. A section is missing about ROI – return on investment (after importance and feasibility). ROI is much
    broader than just “Contributes to Cost Savings within Health System”. It needs to be assessed at the level of each one of the communicating parties.

    d. In the usability/accountability section, the point on: “Aligns with Stakeholders’ Readiness Level for Use” is so critical, that it needs to be further expanded to ensure the end to end adoption (including the engagement and motivations of both ends of the interoperability interaction). These issues cannot be buried in the “need for policies”, as they are often barriers that need to be removed before any technical work is started to ensure an effective consensus.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)

  4. Comments on S&I Framework PROPOSED INITIATIVE SUMMARIES

    The summaries are quite high-level and several of them require clarification as they have multiple possible interpretations. Specific requirements for each of the initiatives should be added. A one page slide is insufficient to communicate the depth necessary to evaluate the proposals. A short summary, perhaps three pages in length, would better describe the specific requirements and use anticipated for each of the initiatives. Such a “scope statement” is a requirement of most initiatives in the real world. Executives are not expected to approve a project based on a one page slide.
    Many of the initiatives seem to be solution rather than requirements driven. More specifically, they propose a specific solution to a problem rather than the set of requirements which should be driving the solution. In some cases, this is a result of ongoing efforts (e.g., Clinical Summaries and Templated CDA) which have already established requirements and are into design stages. But other cases prematurely address solutions. More attention should be paid to requirements.

    1. Clinical Summary
    The proposal contains several elements, of diverse relevance.
    a. There are more than 200 ONC-ATCB Certified products as of December 17th. More than half of these are Complete EHRs. This demonstrates implementability of the HITSP C32 Version 2.5 specification. This specification now has solid acceptance resulting from years of consensus work performed in the 2006-2009 period. Challenges stem from two places: Multiple sources for documentation, and the variety of options for standards specified in the Certification regulation.
    b. The proposal must be explicit in leveraging previous work: HITSP C32/C83, IHE content profiles, HL7 Implementation Guides. This is critical for time to specify and implement
    c. Implementation should be the primary focus of this initiative. We agree that specification/implementation tools with MDHT and the IHE/HL7/HS convergence & collaboration should be the primary focus.
    d. Complexity, actual and perceived needs to be managed. Some of the actual complexity is generated by selection of multiple standards in stage 1 (e.g. multiple code sets, driving two different standards). Simplicity comes from converging to a single standard, CCD, and help implementers/vendors with implementation tools (MDHT).
    e. There is an absolute need for consistency with the templating initiative. Much of the Summary content will be reused in other templated documents. An identical standards base is required for simplicity.

    2. Templated Clinical Documents
    The proposal and its scoping is generally on-track, with the following suggested adjustments:
    a. Initiative should support direction and templating established by previous work: HITSP C32/C83, IHE content profiles, HL7 Implementation Guides. This is critical to complete this project by its proposed deadline. This initiative should “recognize” a library of “content modules” to be flexibly assembled in a family of documents. This moves the focus away from the document itself and towards its modular content (data element/sections) so that a variety of consistent documents may be easily implemented.
    b. Vocabularies (value sets) associated with these content modules need to be addressed within this initiative, and they have to be made single for simplicity, with when necessary secondary value sets included only as glide path for convergence.
    c. Not clear if the outcome to be measured is at the specification creation time or at the software implementation time. The principles of the S&I framework should be applied rather than making up outcome numbers.
    d. Implementation should be the primary focus of this initiative. Agree that specification/implementation tools with MDHT and the IHE/HL7/HS convergence & collaboration should be the primary focus.
    e. Complexity, actual and perceived needs to be managed. Some of the actual complexity is generated by selection of multiple standards in stage 1 (e.g. multiple code sets, driving two different standards). Simplicity comes from converging to a single standard, CDA with CCD templates, and to help implementers/vendors with implementation tools (MDHT).
    f. There is an absolute need for consistency with the clinical summary initiative. Much of the Summary content will be reused in other template documents. An identical standards base (CDA Release 2) is an absolute requirement to realize simplicity.

    3. Lab Interface Improvement
    The focus of the initiative need not be on the profiling specification. The implementation specs have been done by HITSP & HL7. The value sets for lab test and orders codes also have been specified or are presently in progress (LOINC-Results, LOINC-Orders, HITSP value sets, and CSTE/CDC work on reportable conditions).
    The focus must be on the deployment/adoption/certification by BOTH ENDS. So far MU focuses on EHR standards, testing and certification, but nothing is done for labs (e.g. extend CLIA). Unless the lab side is addressed at the policy level, this initiative, as all previous ones is unlikely to deliver any of the expected outcomes.
    ONC should focus on supporting existing efforts in HL7 (Implementation Guides), testing (e.g., IHE Connectathons), and value set development (LOINC and NLM).

    4. Med reconciliation improvement
    The problem statement and interoperability related scope for this initiative need much clarification:
    a. The exchange of medication data is already covered by medical summaries and prescription. Main remaining gap is to rationalize/converge the vocabularies in medication (MU Stage 1 current multiple choices have amplified the issue, and glide path need to be reaffirmed with timeline).
    b. As defined, this seems to be primarily an application functionality effort, not an interoperability one.
    c. Recommends accelerate/support IHE Reconciliation Profile due to be completed by summer 2011. This profile defines the interoperability data elements to be used as input and output to reconciliation, not the reconciliation algorithms). Do not duplicate/detract these on-going efforts.

    5. Provider Directories
    The scope and expected outcome of this initiative appear very immature:
    a. Initiative seems to ignore the main challenge which is how to keep such directories accurate and trust worthy (back office). This will drive adoption and use, and any of the desired outcomes. This management of the directory content is even more complex in a federated directory environment, which is mentioned, without realization of the complexity of the implied policies.
    b. Proposal is to reduce the scale of the initiatives on leveraging the IHE HPD profile and driving its open source implementations.
    c. The scope need to be assessed in the context of business use cases (not a technology use case) in which such provider directories will bring value (the SSA did this when defining with IHE the HPD profile). Once these use cases resulting in the use of a provider directory are made explicit then the initiative outcome can be evaluated.

    6. Syndromic Surveillance
    a. ISDS use case is a good start for hospital syndromic surveillance, but not for ambulatory care syndromic surveillance. This point should be made explicit in the scope and if the ambulatory environment is also targeted, the schedule should be adjusted to allow for appropriate research to be conducted (this does not seem appropriate for the S&I Framework).
    b. HL7 should develop the implementation guide along with IHE to support the deployment/Connectathon testing (a part of the S&I testing process). This testing process needs to involve BOTH ENDS (EHR and public health systems) in order to enable deployment/adoption/certification.
    c. One statement appears concerning in an ONC issued document. It references ongoing “work conducted by ISDS and CDC to develop Stage 1 meaningful use recommendations for syndromic surveillance”. MU Stage 1 is already defined and ongoing work may only feed Stage 2 or 3.

    7. Quality Measures
    The challenge and the scope are inconsistent: is this initiative about defining measures or a format to convey quality data?
    a. If a reporting format base standard is needed to replace PQRI, this work is in progress at HL7. One needs to establish a measure specific profile/ Implementation Guide and testing, with vocabularies/value sets selected. Given the base standards calendar, the needed profiling, and the testing/adoption process, the proposed schedule may not be realistic. This should be planned for 2015 implementation as a PQRI replacement (not for stage 1, as it is defined, and attempts to change that would be disruptive).
    b. If it is about defining measures, we recommend that much attention be placed on the harmonization of the vocabularies in quality measures and with those used in clinical care data to avoid unspecified mappings.
    c. It is not clear what “a quality measure development standard” is expected to address, as stated as one of the expected outcomes

    8. Population Health Query
    The scope of the initiative is unclear and appears quite immature:
    a. It is not possible to discern which way the query is performed, is it public health querying or being queried? Both ways are implied. What is a “public data source”, an EHR?
    b. This is a very broad topic (all of public health!) and depth of data, and it seems to be a simplistic idea that has not been “vetted”. It sounds like the expectation is to have the all-encompassing “clinical data query”. This may be unrealistic.

    9. Clinical Decision Support
    The scope of the initiative is extremely broad and needs much refinement:
    a. The challenge and the outcome are speaking of two different use cases:
    i. defining the exchange of the CDS rules (in some computable language)
    ii. defining the data to be used as input to and output form a CDS service provider
    b. Depending on the type of CDS problem to be addressed, the focus should be sometimes on (i) defining the exchange of the CDS rule language, and in other cases focus on (ii) defining the data needed as input to and output from a “CDS service provider”.
    c. To be effective this initiative needs to identify a series of specific uses of CDS. Unless the scope is more use case specific, this initiative cannot be evaluated and the expected outcome measured.

    10. Blue Button
    The proposal is quite immature and difficult to understand as documented. What are the use cases? Seems a technical solution to an undefined problem:
    • Is the problem to make the display of summary (e.g. CCD/C32) with minimal effort by the patient?
    • Is it one way to the patient? Does the patient need to be able to have that data imported into a home computer, or a PHR and back to another EHR?
    • Last bullet in target outcomes appears the wrong way: how can one map text to C32?
    • MU Stage 1 is already beyond the blue button. Is there a need for another standard format for a summary?

    11. Green Button
    The objective to get all the data form an EHR product to another one is rather unbounded (especially given the diverse customization made by each provider organization).
    The initiative should be recast to primarily leverage the current/near term state of the art in interoperability (e.g. sets of templated CDAs). By becoming a bi-product of other existing interoperability use cases, adding only a “packaging” mechanism, one should be able to transfer the key data from an EHR installation to another one.
    The outcome should be made dependent on (fed by) the outcome of other initiatives. This should be scheduled in a second phase rolling out on the tail of a core set of specific interoperability use cases.

    12. Value Set Development
    Value set development cannot be performed effectively outside of the primary use case for which it is only a part of the overall solution to a business use case. This is already obvious within these set of proposed initiatives: for example lab results and orders value sets should be integral to the laboratory interface initiative (this is already the case, with the ongoing work by LOINC and CSTE).
    It is proposed to no longer address the value set definition as a stand-alone effort and to reduce the scope of this initiative to the infrastructure needed to support value set distribution, all the way to all provider applications. Suggestion is to leverage IHE to get this done (e.g. IHE SVS-Sharing of Value Sets).
    The tools needed to define and manage value sets need to be addressed. This is a complex multi-stakeholder issue, as value set definitions will come from multiple sources. This is a very different issue than the interoperability to “distribute/access” already defined value sets that IHE SVS addresses.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)

  5. Tim McNamar says:

    The President’s Advisory Panel on Science and Technology issued its report on December 8, 2010 two days before this request. See REPORT TO THE PRESIDENT
    REALIZING THE FULL POTENTIAL OF HEALTH INFORMATION TECHNOLOGY TO IMPROVE HEALTHCARE FOR AMERICANS:THE PATH FORWARD. This recommends a single healthcare computer standard be used by the semantic standards of each of the SDOs, who should continue their semantic work to keep up with new medical science.

    This should be the focus of this group, and the new group that ONC is forming on this subject. With the work of the SDOs and translation software available, a full taxonomy for healthcare can now be done for less than $50 million, including preserving all existing legacy formats. XML has proven a failure because it permits heterogeneous extensions of schema’s. This is why the National Information Exchange Model from Justice Department has failed and is not implemented in law enforcement. It is dated 1998 technology that is designed to impede interoperability rather than enable it.

    This is the only work that the Committee needs to do going forward, implement the December 8th recommendation to the President in healthcare.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)

  6. Mark Segal, PhD; Vice President, Government and Industry Affairs, GE Healthcare IT says:

    The opportunity to review and comment on the S&I Framework and the specific initiatives is much appreciated.

    Given the various detailed comments that have been provided, I would like to express specific support for the excellent comments offered by Keith Boone and David Tao and by Charles Parisot (the latter for the Electronic Health Record Association).

    A common thread of these comments is that ONC has identified a worthy superset of specific initiatives that is largely consistent with meaningful use priorities and that there is an urgent need to:

    § further specify and prioritize these initiatives
    § build on past and current standards work
    § assess the likely level of need/opportunity (ROI) for specific initiatives
    § recognize that ONC and industry resources and capabilities to consume S&I initiatives are constrained
    § consider what can/must be achieved given the timelines for Stages 1, 2, and 3 of meaningful use.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)

  7. Wayne Kubick says:

    As a member of the CDISC Board of Directors, I would like to applaud the Health IT Standards Committee’s work to define a Standards and Interoperability Framework. The Clinical Data Interchange Standards Consortium (CDISC) is a global, open, multidisciplinary, non-profit organization that has established standards to support the acquisition, exchange, submission and archive of clinical research data and metadata. The work completed to date by the Committee is most impressive, yet we at CDISC believe it would benefit from a greater recognition of the importance of improving interoperability between healthcare and clinical research. Specifically, I would like to offer the following suggestions:

    1. For the SI Framework spreadsheet, I suggest including an additional criterion for “Complies with regulatory requirements applicable to healthcare and research information
    2. In that same document under “Evidence-Based Medicine & Research Support” I suggest an additional criterion for “supports interoperability with protocol-driven clinical research, including safety reporting”
    3. In the “Proposed Initiative Summaries” document, slide 5, I suggest adding “HL7 v3″ to line 3 under challenge and adding “and for protocol-driven research and safety reporting” to the Scope statement. This may require one or more additional use cases.
    4. In slide 6 of that document, I suggest adding to Target Outcomes “Designate a standardized vocabulary and syntax for medication coding”
    5. In slide 7 of that document, I suggest adding “qne includew research investigator status” to the end of the scope statement.

    In conclusion, let me reiterate my support for the great work to date while also stressing my belief that it would benefit on a greater emphasis on the importance of research.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)

  8. Joel White says:

    Standards and Interoperability Framework

    The Health IT Now Coalition (HITN, http://www.healthitnow.org), a group of 62 organizations that came together to promote adoption and use of HIT to lower costs and improve quality, is pleased to offer comments on the Prioritization Framework and the Proposed Initiative Summaries being developed in the context of the Standards and Interoperability Framework. Our membership is diverse; it includes health care providers, small businesses, large employers, unions, patient advocates and consumers, insurers, brokers and agents, and others that share our views. These comments reflect those of the Coalition and not necessarily those of any individual member.

    Generally, we have supported the efforts of ONC to leverage technology for comment processes on proposed initiatives as indicative of the connective power of technology to illicit public involvement. We believe, however, that the Prioritization Framework is difficult to present using this medium and thus fully understand, as well as equally difficult to imagine using as an evaluative tool. While we support the effort undertaken to prioritize various efforts, we believe that the methods used should be redefined.

    Our comments below refer to the various Proposed Initiative Summaries as those are more helpful in outlining a structure for each of the critical issues evaluated.

    Clinical Summaries

    As a coalition we recognize that the challenges outlined in the exchange of clinical information are not trivial, but the scope defined for the approach outlined by the Standards Committee (HITSC) needs to be further focused. Many of the highlighted problems stem from a lack of standardized data elements. As a Coalition we believe that it is critical not to define these data elements in a vacuum but rather reach out to SDOs and the HIT vendor community in order to unify around standard vocabularies and data elements that are already being utilized. In doing so, ONC would be adopting the best practices associated with the standard as well. One such standard that is already widely in use and would be easily harmonized with ONC’s efforts is the HITSP data dictionary known as HITSP C154. The dictionary lays out every applicable data element as well as their constraints on values. This system is aligned with the vocabularies already adopted by HHS as standards and would greatly alleviate some of the core issues faced in the real exchange of clinical summaries.

    Templated Clinical Documents

    HITN believes the standardization of templated clinical documents is critical to care coordination across provider settings. The core challenge with the documents is that they are often comprised of structured and unstructured data. There is considerable work being done to structure all the data elements and we encourage ONC to look to the HITSP C83 specification as a standard that is already well understood by the health technology development community.

    In addition, we believe the outcomes threshold identified in the executive summaries are too low. A 10% reduction in time to create unstructured and structured documents in 2011 is too low and should be increased to at least the 25% contemplated for adoption in 2013.

    Finally and perhaps most importantly, during the October meeting of the HIT Policy Committee, Dr. Tang indicated in his MU workgroup recommendations that ONC should consider harmonizing the MU standards with other health IT enabled programs. The example he gave was using MU as sufficient for the HIT component of ACO certification and vice versa. Clinical templates will be a critical piece of the functionality of ACOs and for this reason we believe that there should be an increased focus on the timely production of unstructured and structured documents based on the HL7 CDA because it will better align with MU and with other programs using the MU programs as a benchmark. We strongly encourage this development and the harmonization of standards across federal programs such as using MU as the baseline for ACO HIT certification.

    Lab Interface Improvement

    Many of our coalition members have extensive experience with the difficulties of incorporating lab results as structured data. We point to the extensive work being done by the National Library of Medicine (NLM-NIH) as well as the National Center for Biotechnology Information (NCBI-NIH) to structure lab data so that it may be exchanged between care settings, departments of public health, and EHRs. There are additional constraints put on this kind of data because of the requirements of the Clinical Laboratory Improvement Amendments (CLIA) defined by CMS. However, HL7 2.5.1 does meet those requirements and for this reason should be employed as the messaging standard.

    NLM has also done a considerable amount of work defining LOINC messages for ordering; LOINC as a standard covers nearly all order types. Furthermore the HIT Standards Committee has already acknowledged a desire to use SNOMED CT as a vocabulary standard as well as RxNORM for drug orders. SNOMED CT, when layered with HL7 and LOINC is robust enough to cover specialized laboratory requests such as pathogenic labs. Currently NLM is working with the Health Resources and Services Administration Maternal and Child Health Bureau (HRSA-MCHB) to require these standards be used for care settings to exchange information about newborn screening between labs and state departments of health. While mandating these standards for use in a national program will familiarize labs with the standards used in the Newborn program, this kind of data exchange only represents a small part of lab orders. By making HL7 2.5.1, LOINC, and SNOMED CT the national standard for EHRs lab systems will be more readily integrated into the data exchange community.

    Medication Reconciliation Improvement

    We understand the complexity of this issue but believe that the number of private sector technology solutions in this field is ubiquitous. We believe that part of the problems with medication reconciliation is that associated standards for e-prescribing are not stringent enough. As a coalition we have been very vocal about the need to raise the e-prescribing standard to the Medicare Part D standard of 75% as a minimum. Many of the issues surrounding medication reconciliation often relate to a cumbersome and paper based reconciliation process. Requiring structured e-prescribing and by increasing the volume of electronic scripts may sufficiently digitize the process to make the technology solutions easier to implement and use.

    Provider Directories

    HITN believes that these directories are critical to ensure that care plans are as coordinated as possible. Furthermore, we believe that provider directories as a part of the EHR and as a tool for patient use will empower patients to identify care options and resources available to them in or near their communities. While there is no exiting structure for these directories, we believe that the ELPD model should be used as a foundation for ILPDs and eventually Specialty Level Provider Directories (SLPD).

    Syndromic Surveillance

    HITN believes that best practices can be drawn from the work done by NLM and HRSA in the newborn screening space. Newborn screening is an excellent example of an integrated health care system because it includes data exchange between the provider and lab settings, and State Departments of Health for short-term and long-term follow up. This is a complex and nuanced example of syndromic surveillance. We agree with the Standards Committee that these best practices should be combined with the work currently being conducted by the International Society for Disease Surveillance.

    Quality Measures

    We agree that there are not clear connections between standards and quality measures required by CMS. One reason providers are frustrated is there seems to be little rationale given for reporting on quality measures. In the past, we have encouraged CMS to produce a strategic plan for why the measures are being reported and for what purpose the data will be used. We suggest a good use would be to attain quality benchmarks for ACOs and other delivery and payment models, thereby more closely aligning the MU program with these programs.

    We also believe the Standards Committee should take the same outcomes-based approach that the Policy Committee has in setting quality measures. To reach desired outcomes the standards setting process must build a framework that will not only take exiting best practices into account, but also allow for the reinfusion of lessons learned and new evidence-based medicine that is developed as a function of EHR enabled healthcare and in the Medicare physician feedback program.

    Population Health Query

    Incidence aggregation is a common problem in nationally mandated screening programs. The issue is two-fold: lab data is often unstructured and therefore the data is not liquid; and there are considerable privacy concerns even in de-identified databases. Currently, exiting incidence aggregators generally rely on unstructured reporting or a central body distributing a semi-annual survey to relevant providers. This is neither efficient nor is it scientific. We believe that bolstering standards for structured lab results will meaningfully facilitate liquid data exchange between provider settings, labs, and State Departments of Health. Likewise, increasing data liquidity will allow associated data to be automatically pushed to a relevant aggregator as a function of the EHR.

    As a Coalition we believe that meaningful steps should be taken to maintain patient privacy in a way that builds a fabric of systemic trust while at the same time provides sufficient data to leverage the function of EHRs. Aggregated data, if made publically available, has the potential to be re-identified and violate an individual’s trust. This is particularly true for rare conditions. Disallowing data aggregation as a function of EHRs, however, will severely compromise our ability to conduct timely population based research and provide feedback to providers to improve care delivery. HITN believes that population health queries are an essential stepping stone to meaningful decision support features of EHRs and for this reason they should be paired with very strict disclosure accounting and audit trails for PHI to maintain patient trust.

    Clinical Decision Support

    Clinical Decision Support is one of the most important and powerful features of EHR-enabled healthcare. CDS holds the potential to improve the quality and reduce the cost of healthcare in a constructive partnership with care providers. For this reason we believe that the development of exchange standards should be seen through the lens of enabling CDS as the best outcome. To facilitate this, we must identify the data that should be exchanged to enable CDS and make sure that it is appropriately structured and standardized. Standardized data is a prerequisite of CDS because EHR systems are designed with to receive a certain data type that will be fed into CDS algorithms. If designers cannot anticipate what kind of data will be exchanged with their EHR systems then the responsibility to develop a CDS interface will fall onto the provider. If a unique CDS interface needs to be developed for every patient, providers will not meaningfully adopt CDS functions in EHRs and the true power of HIT will be greatly diminished.

    We believe the numeric targets outlined by the HITSC are arbitrary and perhaps unrealistic. If a particular CDS is important to preventing medical errors and deaths, universal adoption should be the goal. CDS associated with a more minor health interaction, but more closely associated with a clinician’s work flow might also warrant a higher adoption target. We believe HHS should focus on CDS that prevents medical errors, reduces never events and known causes of mortality and morbidity and helps to reduce hospital readmissions. Standardized data (lab and otherwise) is critical to achieve meaningful progress in these areas, as is provider input into CDS design to ensure robust adoption.

    Blue Button

    We support the concept of the Blue Button and believe that it should be a required feature of all EHR systems. We believe that the challenges associated with the Blue Button lie in an emphasis on human readability. While it is clear that the CCD created by the EHR should be machine and human readable, we believe that the Standards Committee should work closely with industry leaders like HL7 to transform standards based reports into human readable text and not try and make text versions of each of the individual standards.

    Green Button
    We do not support “Green Button” functionality. While we understand the need to prevent providers from being locked into a vendor, HITN believes that this will not be an issue if exchange standards are meaningfully developed and implemented. If a larger emphasis is put on exchange standards, providers should have no trouble sending a standardized version of an entire patient record between two EHR platforms. If providers are to meaningfully exchange data between one another in care scenario then they should be able to exchange the exact same data between the EHR platform they use and the new one that they have purchased. Pursuing a green button strategy may actually detract from achieving bi-directional and systemic interoperability and we encourage the Standards Committee to abandon this concept.

    Value Set Development

    HITN believes that the development of value sets can be greatly informed by the standards that are laid out in the structuring of lab data. In our previous comments to ONC, we have stated that LOINC, SNOMED CT, and RxNORM can address lab orders, anatomy and pathogens, and drugs. The value sets currently exist and can be readily adopted through solid leadership.

    Prioritization Framework

    The Health IT Now Coalition believes that the Prioritization Framework is a reasonable first step in addressing complex issues. However we believe that many aspects of the framework are very complex and not easily adoptable. We are concerned with the scoring system that has been developed by the framework. Many of the projects and programs that will be evaluated through this framework are going to be very different and not easily compared to one another. For these reason a scoring system may be subjective and does not lend itself to a complex weighting system that is data driven and scientifically based.

    We would like to thank the National Coordinator for this opportunity and for the work the Committees have done thus far. The Health IT Now Coalition looks forward to the insight provided by all commenters and encourages the Committees and ONC to adopt the recommendations outlined above.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)

  9. Beth Franchi says:

    Thank you for the opportunity to provide comment on the Prioritization Framework. The Veterans’ Health Administration Office of Health Information Data Quality Program commends the effort put into this document. Below are our suggestions:

    We recommend adding a criteria, “Scalability”, to the technical aspect of the Feasibility category.

    Under the “Usability / Accountability” category we recommend adding a criteria, “Aligns with stakeholder business processes”. (“Readiness level” in cell C36 reads somewhat abstract with regard to business vs. technical readiness. By adding this new criteria, the business processes can be regarded separately from stakeholders’ technical readiness level for use.)

    Within the “Requires/Supports Information Exchange” criteria under Feasibility, we recommend adding a question to the Criteria Description, “Are the required data elements automated?”

    Within the “Has Outcome of Performance Measures” criteria under Usability/Accountability, we recommend adding a qualifying statement to the criteria description about including outcome measures to assess conformance to both business and technical requirements.

    Like or Dislike: Thumb up 2 Thumb down 0 (+2)