Department of health and human services

We propose to adopt a 2015 Edition certification criterion for “transitions of care” (ToC) that is a continuation and extension of the ToC certification criterion adopted as part of the 2014 Edition Release 2 final rule at § 170.314(b)(8). This proposed criterion also reflects the corresponding structural and clarifying changes that we adopted in the 2014 Edition Release 2 final rule that correspond to “clinical information reconciliation and incorporation” certification criterion also adopted as part of the 2014 Edition final rule.

Accordingly, the 2015 Edition ToC certification criterion we propose to adopt would include many of the same capabilities adopted at § 170.314(b)(8) with the exception of the following revisions and additions.

Updated C-CDA Standard

As expressed in the 2014 Edition final rule, the C-CDA standard is now the single standard permitted for certification and the representation of summary care records. It is also referenced in other proposed 2015 Edition certification criteria. Industry stakeholders have continued to work to improve and refine the C-CDA standard since the 2014 Edition final rule, including publishing additional guidance for its consistent implementation.⁷⁵ An updated version, HL7 Implementation Guide for CDA^® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.0⁷⁶, which was balloted through 2014, includes the following changes, which we believe provide important clarifications and enhancements:

• 
  Addition of new structural elements: new document sections and data entry templates:
  
  • 
    New Document Templates for: Care Plan; Referral Note; Transfer Summary.
    
  • 
    New Sections for: Goals; Health Concerns; Health Status Evaluation/Outcomes; Mental Status; Nutrition; Physical Findings of Skin.
    
  • 
    New organizers and many new entries (e.g. Wound Observation).
    
• 
  Some sections/entries were deprecated (i.e., should no longer be used).
  
• 
  Updates to (versioning of) template/section/entry object identifiers (OIDs).
  
  • 
    This includes a new chapter describing HL7's approach to template versioning.
    
• 
  Tighter data constraints/requirements.
  
  • 
    For example, some data elements with a “MAY” requirement now have a “SHOULD” requirement. Likewise, some with a “SHOULD” requirement now have a “MUST” requirement.
    
• 
  Updated Vocabulary/Value Set constraints.
  
  • 
    For example: two SNOMED CT^® codes were added to the Current Smoking Status value set and the Tobacco Use value set to support the 2014 Edition vocabulary requirements for patient smoking status.
    
  • 
    NLM's Value Set Authority Center (VSAC) was named as reference for Value Sets used in C-CDA.
    

In the Voluntary Edition proposed rule, we proposed to adopt the C-CDA Release 2.0 standard and reference its use in the other certification criteria in which this standard would have also been applicable. At the time of that proposal, the C-CDA Release 2.0 had not yet completed its balloting cycle within HL7 and stakeholder comments on the Voluntary Edition proposed rule expressed concern related to the C-CDA Release 2.0 standard’s stability. Given that the C-CDA Release 2.0 has completed balloting and is now published as the next C-CDA version, we believe that the continued attention it received through HL7 balloting has resulted in a standard that is the best available for adoption in this proposed rule and for future implementation in the coming years. Thus, we propose to adopt C-CDA Release 2.0 at § 170.205(a)(4) as part of this certification criterion. We note that compliance with the C-CDA Release 2 cannot include the use of the “unstructured document” document-level template for certification to this criterion.

To address a technical implementation challenge sometimes referred to as “bilateral asynchronous cutover,” (which is meant to convey the complexity of continued interoperability among exchange partners as each upgrades their health IT at different times and with different standards capabilities), we propose that the 2015 Edition ToC certification criterion reference both the C-CDA Release 1.1 and Release 2.0 standards. In other words, a Health IT Module presented for certification to this criterion would need to demonstrate its conformance and capability to create and parse both versions (Release 1.1 and 2.0) of the C-CDA standards. Under this proposal, the sending Health IT Module would send two documents (one conforming to C-CDA R1.1 and other conforming to C-CDA R2.0) and the receiving Health IT Module would receive both versions of the documents and choose the appropriate version for downstream processing.

While we recognize that this proposal is not ideal, we have proposed this more conservative approach as a way to mitigate the potential that there would be interoperability challenges for ToC as different health care providers adopt Health IT Modules certified to the 2015 Edition criterion at different times that include C-CDA Release 2.0 capabilities. However, we request public comment, especially from health IT developers with experience implementing the C-CDA, on an alternative approach related to the creation of C-CDA-formatted documents. The alternative approach would be focused on C-CDA creation and receipt capabilities related to whether the health IT system could produce one, “dually compliant,” C-CDA that addresses both C-CDA versions at once. We understand that this approach is possible, may be preferred from an implementation perspective, and could help prevent potential data duplication errors that could result if a Health IT Module is required to be able to produce two separate C-CDA files (one in each version) as part of certification.

Our proposal to adopt C-CDA Release 2.0 is applicable to all of the other certification criteria in which the C-CDA is referenced. Similarly, unless C-CDA Release 2.0 is explicitly indicated as the sole standard in a certification criterion, we propose to reference both C-CDA versions in each of these criteria for the reasons just discussed.

Valid/Invalid C-CDA System Performance

As we considered stakeholder feedback and reviewed the additional public dialogue surrounding the variability of CEHRT in recognizing valid/invalid documents formatted according to the C-CDA 1.1 standard, including structured content by different health IT developers⁷⁷, we recognized that an expanded ToC certification criterion with a specific capability focused principally on health IT system behavior and performance related to recognizing valid/invalid C-CDAs would be beneficial. Thus, we propose to include within the 2015 Edition ToC certification criterion a specific focus on this technical system behavior. We believe this type of error checking and resilience is an important and necessary technical prerequisite in order to ensure that as data in the system is parsed from a C-CDA for incorporation as part of the “clinical information reconciliation and incorporation” certification criterion the user can be assured that the system has appropriately interpreted the C-CDA it received. Further, we believe this level of rigorous testing will better enable Health IT Modules to properly recognize C-CDA-based documents and prepare the necessary information for reconciliation and other workflow needs.

We propose that this specific aspect of the certification criterion would focus on and require the following technical outcomes be met. The Health IT Module would need to demonstrate the ability to detect valid and invalid C-CDA documents, including document, section, and entry level templates for data elements specified in 2014 and 2015 edition. Specifically, this would include:

• 
  The ability of the Health IT Module to detect invalid C-CDA documents. Thus, any data in the submitted C-CDA document that does not conform to either the C-CDA 1.1 or 2.0 standard (in addition to data coding requirements specified by this regulation) would be considered invalid;
  
• 
  The ability to identify valid C-CDA document templates (e.g., CCD, Discharge Summary, Progress Note) and process the required data elements, section and entries, specific to the document templates and this regulation.
  
• 
  The ability to detect invalid vocabularies and codes not specified in either the C-CDA 1.1 or 2.0 standard or required by this regulation (e.g., using a SNOMED CT^® code where a LOINC^® code is required or using a code which does not exist in the specified value set).
  
• 
  The ability to correctly interpret empty sections and nullFlavor combinations per the C-CDA 1.1 or 2.0 standard. For example, we anticipate testing could assess a Health IT Module's ability to continue to process a C-CDA when a nullFlavor is used at the section template level.
  

We expect these capabilities would be tested by providing several C-CDA documents with valid and invalid data. We do not expect Health IT Modules presented for certification to have a common C-CDA handling process, however, we do expect that they would have a baseline capability to identify valid and invalid C-CDA documents and prepare the necessary data for clinical information reconciliation and incorporation. Further, we expect that Health IT Modules will have some mechanism to track errors encountered when assessing received C-CDA’s and we have proposed that health IT be able to track the errors encountered and allow for a user to be notified of errors or review the errors produced. The Health IT Module would not need to support both and how this technical outcome is accomplished is entirely up to the health IT developer.

We direct readers to the proposed “Consolidated CDA creation performance” certification criterion (§ 170.315(g)(6)) under which we seek comment on a potential requirement for this certification criterion or the “Consolidated CDA creation performance” certification criterion that would evaluate the completeness of the data included in a C-CDA in order to ensure that the data recorded by health IT is equivalent to the data included in a created C-CDA.

XDM Package Processing

As indicated in the earlier paragraphs, a Health IT Module presented for certification to this certification criterion will need to support one of the edge protocols referenced in the Edge IG version 1.1 (i.e., the “IHE XDR profile for Limited Metadata Document Sources” edge protocol or an SMTP-focused edge protocol (SMTP alone or SMTP in combination with either IMAP4 or POP3)). However industry feedback has indicated that the use of XDM packages has grown within the stakeholder community using Direct, which most often happens when Edge System A using XDR sends content and metadata to its HISP-A, who in turn packages that content and metadata into an XDM ZIP and sends it within a Direct message to HISP-B, which then ultimately sends the message containing the XDM package to Edge System B using an SMTP-based edge.

Therefore, if Edge System B does not support XDM package processing, interoperability could be impacted when HISP-B forwards XDM packages to Edge System B via the SMTP protocol. To mitigate this potential incompatibility, we propose to include a specific capability in this certification criterion that would require a Health IT Module presented for certification that is also being certified to the SMTP-based edge to demonstrate its ability to accept and process an XDM package it receives, which would include extracting relevant metadata and document(s). That is, this additional requirement only applies to a Health IT Module presented for certification with an SMTP-based edge implementation and not an XDR edge implementation). Additionally, because we expect XDM packaging to be created in accordance with the specifications included in IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-2b)⁷⁸, we propose to adopt this as the standard (at § 170.205(p)(1)) for assessing whether the XDM package was successfully processed.

Common Clinical Data Set

We propose to include an updated Common Clinical Data Set for the 2015 Edition that includes references to new and updated vocabulary standards code sets. Please also see the Common Clinical Data Set definition proposal in section III.B.3 of this preamble.

Encounter Diagnoses

For encounter diagnoses, we are carrying over the requirement from the 2014 Edition “ToC” certification criterion that a Health IT Module must enable a user to create a transition of care/referral summary that also includes encounter diagnoses using either SNOMED CT^® (September 2014 Release of the U.S. Edition as a baseline for the 2015 Edition) or ICD-10 codes.

“Create” and Patient Matching Data Quality

In 2011, both the HITPC and HITSC made recommendations to ONC on patient matching. The HITPC made recommendations in the following five categories: standardized formats for demographic data fields; internally evaluating matching accuracy; accountability; developing, promoting and disseminating best practices; and supporting the role of the individual/patient.⁷⁹ The HITSC made the following four recommendations: detailing patient attributes that could be used for matching (in order to understand the standards that are needed); data quality; formats for these data elements; and what data are returned from a match request.⁸⁰ The standards recommended by the HITSC are as follows:

• 
  Basic Attributes: Given Name; Last Name; Date of Birth; Administrative Gender.⁸¹
  
• 
  Other Attributes: Insurance Policy Number; Medical Record Number; Social Security Number (or last 4 digits); Street Address; Telephone Number; Zip Code.
  
• 
  Potential Attributes: Email Address; Voluntary Identifiers; Facial Images; Other Biometrics.
  

In July 2013, ONC launched an initiative to reinvigorate public discussion around patient matching, to perform a more detailed analysis of patient matching practices, and to identify the standards, services, and policies that would be needed to implement the HITPC and HITSC’s recommendations. The initiative’s first phase focused on a common set of patient attributes that could be leveraged from current data and standards referenced in our certification criteria. Given the initial findings, we proposed to include a limited set of standardized data as a part of the “Create” portion of the ToC criterion in the Voluntary Edition proposed rule to improve the quality of the data included in outbound summary care records. Overall, the vast majority of commenters supported the proposed policy that standardized patient attributes should be required for use in as part of the transitions of care certification criterion. Commenters overwhelmingly supported the inclusion of the proposed constrained specifications for last name/family name, maiden name, suffix, first/given name, middle/second name, maiden name, date of birth, current address and historical address, phone number, and sex in support of patient matching. However, given our approach in the 2014 Edition Release 2 final rule to only adopt a small subset of the proposed certification criteria to provide flexibility, clarity, and enhance health information exchange, we decided not adopted this proposal.

We again propose to include a limited set of standardized data as a part of the “Create” portion of the ToC criterion in the 2015 Edition to improve the quality of the data included in outbound summary care records. To be clear, this proposal does not require a Health IT Module to capture the data upon data entry, but rather at the point when the data is exchanged (an approach commonly used for matching in HL7 transactions, IHE specifications⁸², C-CDA specification, and the eHealth Exchange). The proposed standardized data include: first name, last name, middle name (including middle initial), suffix, date of birth, place of birth, maiden name, phone number, and sex. In the bulleted list below, we identify more constrained specifications for some of the standardized data we propose. Based on our own research, we do not believe that the proposed constraints to these data conflict with the C-CDA. That being said, some proposed constraints may further restrict the variability as permitted by existing specifications and others may create new restrictions that do not currently exist within the C-CDA. We propose that:

• 
  For “last name/family name” the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0⁸³ (which addresses whether suffix is included in the last name field) be followed.
  
• 
  For “suffix,” that the suffix should follow the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, PHD, ESQ)⁸⁴ and that if no suffix exists, the field should be marked as null.
  
• 
  For “date of birth,” that the year, month and date of birth should be required fields while hour, minute and second should be optional fields. If hour, minute and second are provided then either time zone offset should be included unless place of birth (city, region, country) is provided; in the latter local time is assumed. If date of birth is unknown, the field should be marked as null.
  
• 
  For “phone numbers,” the ITU format specified in ITU-T E.123 ⁸⁵ and ITU-T E.164⁸⁶ be followed and that the capture of home, business, and cell phone numbers be allowed.⁸⁷ Further, that if multiple phone numbers are present in the patient’s record, all should be included in the C-CDA and transmitted.
  
• 
  For “sex” we propose to require developers to follow the HL7 Version 3 Value Set for Administrative Gender and a nullFlavor value attributed as follows: M (Male), F (Female), and UNK (Unknown).
  

While the Patient Matching Initiative’s recommendations included standardizing current and historical address, we have not included a specific standardized constraint for that data at this time due to a lack of consensus around the proper standard. In response to the Voluntary Edition proposed rule, commenters also suggested that we delay support for international standards for address until future editions of certification criteria. To reiterate, the data we propose for patient matching would establish a foundation based on leveraging current data and standards in certification criteria. We welcome comments on this approach and encourage health IT developers to consider and support the use other patient data that would improve patient matching for clinical care and many types of clinical research.

Direct Best Practices

In the past couple of years we have heard feedback from stakeholders regarding health IT developers limiting the transmission or receipt of different file types via Direct. We wish to remind all stakeholders of the following best practices for the sharing of information and enabling the broadest participation in information exchange with Direct: http://wiki.directproject.org/Best+Practices+for+Content+and+Workflow.

Certification Criterion for C-CDA and Common Clinical Data Set Certification

We note that no proposed 2015 Edition health IT certification criteria includes just the C-CDA Release 2.0 and/or the Common Clinical Data Set, particularly with the 2015 Edition not including a proposed “clinical summary” certification criterion as discussed later on in this preamble. Health IT certified to simply the C-CDA Release 2.0 with or without certification to the Common Clinical Data Set may be beneficial for other purposes, including participation in HHS payment programs. We request comment on whether we should adopt a separate 2015 Edition health IT certification criterion for the voluntary testing and certification of health IT to the capability to create a summary record formatted to the C-CDA Release 2.0 with or without the ability to meet the requirements of the Common Clinical Data Set definition.

C-CDA Data Provenance Request for Comment

As the exchange of health data increases, so does the demand to track the provenance of this data over time and with each exchange instance. Confidence in the authenticity, trustworthiness, and reliability of the data being shared is fundamental to robust privacy, safety, and security enhanced health information exchange. The term “provenance” in the context of health IT refers to evidence and attributes describing the origin of electronic health information as it is captured in a health system and subsequently persisted in a way that supports its lifespan. As described in the President’s Council of Advisors on Science and Technology (PCAST) Report “Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans”⁸⁸, provenance includes information about the data’s source and the processing that the data has undergone. The report refers to “tagged data elements” as units of data accompanied by a “metadata tag” that describes the attributes, provenance, and required security protections of the data.

In April 2014, ONC launched the Data Provenance Initiative within the Standards and Interoperability (S&I) Framework to identify the standards necessary to capture and exchange provenance data, including provenance at time of creation, modification, and time of exchange.⁸⁹ The stakeholder community represented a wide variety of organizations including health IT developers; federal, state, and local agencies; healthcare professionals; research organizations; payers; labs; and individuals within academia. In the fall of 2014, the HL7 IG for CDA Release 2: Data Provenance, Release 1 (US Realm) (DSTU)⁹⁰ was published. This IG clarifies existing content from various standards within HL7⁹¹ and describes how provenance information for a CDA document in a health IT system should be applied, and what vocabulary should be used for the metadata. This includes provenance metadata in the CDA at the header, section and entry levels. We seek comment on the maturity and appropriateness of this IG for the tagging of health information with provenance metadata in connection with the C-CDA. Additionally, we seek comment on the usefulness of this IG in connection with certification criteria, such as ToC and VDT certification criteria.

 Clinical Information Reconciliation and Incorporation

2015 Edition Health IT Certification Criterion § 170.315(b)(2) (Clinical information reconciliation and incorporation)