Department of health and human services
Yüklə 1,55 Mb.
|
- Bu səhifədəki naviqasiya:
- 2015 Edition Health IT Certification Criterion
|
We propose to adopt a 2015 Edition CPOE certification criterion specific to laboratory ordering that is revised in comparison to the CPOE – laboratory criterion adopted at § 170.314(a)(19) as well as § 170.314(a)(1). We propose to adopt and include in this criterion, for the ambulatory setting, the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders (LOI) from EHR, Draft Standard for Trial Use, Release 2 – US Realm (“Release 2”).19 Due to the absence of a consensus standard for the purpose of sending laboratory orders from EHRs to laboratories, this standard was developed in conjunction with laboratories representative of the industry, health IT developers, and provider stakeholders through an open consensus-based process under the Standards and Interoperability Framework (S&I Framework). Release 1 of the standard was balloted and approved through HL7, a standards developing organization. Release 2 is currently under ballot reconciliation with HL7 and should be published in the next few months. Release 2 would:
Overall, we propose to adopt Release 2 of the standard because it addresses errors and ambiguities found in Release 1 and harmonizes requirements with other laboratory standards we propose to adopt in this proposed rule. Release 2 would also make implementation of the LOI IG clearer and more consistent for health IT developers and laboratories, as well as improve interoperability. We propose to adopt Release 2 at § 170.205(l)(1). Commenters on the Voluntary Edition proposed rule noted that for optimal interoperability we need to also adopt the most recent version of the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, (also referred to as the “electronic Directory of Services (eDOS) IG”), as it is the companion IG to the LOI IG. We agree with the commenters’ assessment and propose to include the most recent version of the eDOS IG in this criterion for certification to all health care settings (i.e., not confining it to only the ambulatory setting) and adopt it at § 170.205(l)(2). The most recent version of the eDOS IG will be Release 2, Version 1.2, which is scheduled to publish in the next few months. Release 2, Version 1.2 is currently under ballot reconciliation.20 In general, the eDOS IG provides requirements and guidance for the delivery of an electronic Directory of Services (test compendium) from a laboratory (compendium producer) to an EHR or other system (compendium consumer) where it is used to produce electronic orders (LOI-conformant messages) for laboratory tests. Version 1.2 of the eDOS IG addresses errors and ambiguities in the prior version as well as harmonizes with Release 2 of the LOI IG. We also propose, for the purposes of certification, to require a Health IT Module to be able to use, at a minimum, the version of Logical Observation Identifiers Names and Codes (LOINC®) adopted at § 170.207(c)(3) (version 2.50) as the vocabulary standard for laboratory orders. This is the most recent version of LOINC®. We refer readers to section III.A.2.d (“Minimum Standards” Code Sets) for further discussion of our adoption of LOINC® as a minimum standards code set and our proposal to adopt version 2.50, or potentially a newer version if released before a subsequent final rule, as the baseline for certification to the 2015 Edition. We note that the LOI Release 2 IG requires the information for a test requisition as specified in the Clinical Laboratory Improvement Amendments (CLIA), 42 CFR 493.1241(c)(1) through (c)(8), to be included in the content message. Therefore, inclusion of this standard for certification may also facilitate laboratory compliance with CLIA. Computerized Provider Order Entry – Diagnostic Imaging
We propose to adopt a 2015 Edition CPOE certification criterion specific to diagnostic imaging. This proposed criterion does not reference any standards or implementation specifications, and is unchanged in comparison to the 2014 Edition CPOE – diagnostic imaging criterion adopted at § 170.314(a)(20). To note, we also propose to adopt the title of “diagnostic imaging,” which is the title we gave to the 2014 Edition version of this certification criterion in the 2014 Edition Release 2 final rule (79 FR 54436). Drug-Drug, Drug-Allergy Interaction Checks for CPOE
We propose to adopt a 2015 Edition “drug-drug, drug-allergy interaction checks for CPOE” certification criterion that is revised in comparison to the 2014 Edition “drug-drug, drug-allergy interaction checks” criterion (§ 170.314(a)(2)). We propose to clarify that the capabilities included in this criterion are focused on CPOE by including “for CPOE” in the title of this criterion. We also propose to include in this criterion the capabilities to record user actions for drug-drug, drug-allergy interaction (DD/DAI) interventions and to enable a user to view the actions taken for DD/DAI interventions (also referred to as “checks”). Specifically, we propose that a Health IT Module must be able to record at least one action taken and by whom in response to drug-drug or drug-allergy interaction checks. To be certified to this criterion, a Health IT Module (at a user’s request) must also be able to generate either a human readable display or human readable report of actions taken and by whom in response to drug-drug or drug-allergy interaction checks. We solicited comment in the Voluntary Edition proposed rule on whether health IT should be able to track (which means “record” and will be referred to as “record” throughout this preamble) provider (referred to as “user” for the purposes of this proposed certification criterion) actions for DD/DAI interventions, including recording if and when the user viewed, accepted, declined, ignored, overrode, or otherwise commented on the DD/DAI interventions. We received comments that supported recording user actions for DD/DAI interventions (79 FR 54449). We also received comments recommending that we consider including recording user actions in response to CDS interventions. We discuss those comments under the CDS certification criterion in this section (III.A.3) of the preamble. We believe that recording user actions for DD/DAI interventions could assist with quality improvement and patient safety. While some commenters expressed concern that functionality for recording user actions would be burdensome to develop, we believe the potential benefits of improved care and reduced adverse events that can come from using such functionality and being able to subsequently analyze user actions for DD/DAI interventions outweighs the development burden. To provide health IT developers with flexibility and the opportunity to innovate, we have explicitly not specified the types of actions a Health IT Module must be able to record to meet this criterion. Health IT developers would need to simply demonstrate that their Health IT Module can record at least one user action for DD/DAI checks. For example, a Health IT Module could include the capability to record whether the user viewed, accepted, declined, ignored, overrode, provided a rationale or explanation for the action taken, took some other type of action not listed here or otherwise commented on the DD/DAI check. We solicit comment on whether we should focus this proposed requirement to record at least one user action taken for DD/DAI interventions on a subset of DD/DAI interventions, such as those of highest patient safety concern, and what sources we should consider for defining this subset. We note, however, that we do not intend with this proposed requirement to infer a specific workflow or user interface in order to achieve conformance to this criterion. While appropriate documentation in accordance with clinical, safety, and system design best practices for these DD/DAI interventions is beyond the scope of certification for this criterion, we would encourage health IT developers to consider these best practices in developing this functionality and attempt to not interrupt a provider’s workflow unnecessarily to meet this criterion. This criterion also does not propose to establish the uses for the “user action” information, whom should be able to view the information, or who could adjust the capability. Further, based on stakeholder feedback, there does not appear to be a consensus method or standard for characterizing the severity of patient DD/DAI reactions. Therefore, until the stakeholder community determines if there should be a set of methods, standards, or clinical guidelines for determining the severity of a patient DD/DAI reaction, we believe that users should determine these definitions for their organization and/or setting. While this proposed certification criterion focuses on DD/DAI checking at the point when a user enters a computerized order, we believe that there are instances when a user should be aware of a patient's DD/DAI when new medications or medication allergies are entered into the patient record. Therefore, we strongly encourage health IT developers to build in functionality, including but not limited to clinical decision support, that would inform a user of new or updated DD/DAI when the medication or medication allergy lists are updated. We also seek comment on whether we should include this functionality in certification and whether this functionality should be included in an existing certification criterion (e.g., medication list, medication allergy list, clinical decision support) or a standalone criterion. Demographics
We propose to adopt a 2015 Edition “demographics” certification criterion that is revised as described below in comparison to the 2014 Edition certification criterion (§ 170.314(a)(3)). Sex We propose that, for certification (and testing) to this criterion, health IT must be capable of recording sex in accordance with HL7 Version 3 (“AdministrativeGender”) and a nullFlavor value attributed as follows: male (M); female (F); and unknown (UNK). This proposal serves as another means of improving interoperability through the use of consistent standards. We propose in a later section of this rule that using HL7 Version 3 for recording sex would be required under the “Common Clinical Data Set” definition for certification to the 2015 Edition. Please see section III.B.3 “Common Clinical Data Set” of this preamble for further discussion of this associated proposal.
We propose that, for certification (and testing) to this criterion, a Health IT Module must be capable of recording each one of a patient’s races and ethnicities in accordance with, at a minimum, the “Race & Ethnicity – CDC” code system in the PHIN Vocabulary Access and Distribution System (VADS), Release 3.3.9.21 We also propose that a Health IT Module must be able to aggregate each one of a patient’s races and ethnicities to the categories in the OMB standard for race and ethnicity, which we previously adopted for the 2011 Edition and 2014 Edition “demographics” certification criteria. As discussed in the 2014 Edition final rule (77 FR 54208), the OMB standard for the classification of data on race and ethnicity requires that the option for selecting one or more racial designations be provided. The standard also permits the use of more than the minimum standard categories for race and ethnicity, but requires that the data can be “rolled up” or mapped to the minimum standard categories as well as aggregated. The “Race & Ethnicity – CDC” code system in PHIN VADS (at a minimum, Release 3.3.9) permits a much more granular structured recording of a patient’s race and ethnicity with its inclusion of over 900 concepts for race and ethnicity. The recording and exchange of patient race and ethnicity at such a granular level can facilitate the accurate identification and analysis of health disparities based on race and ethnicity. Further, the “Race & Ethnicity – CDC” code system has a hierarchy that rolls up to the OMB minimum categories for race and ethnicity and, thus, supports aggregation and reporting using the OMB standard. Accordingly, we propose the adoption and inclusion of both these standards in this certification criterion as described. For the purposes of testing and certification to this “demographics” criterion, we would test that a Health IT Module can record each one of a patient’s races and ethnicities using any of the 900 plus concepts in the “Race & Ethnicity – CDC” code system. We would not, however, expect the user interface to include a drop-down menu of all 900 plus “Race & Ethnicity – CDC” code system concepts for race and ethnicity, as we believe doing so could have negative workflow effects. Rather, we expect that health IT developers and health care providers would work together to establish the appropriate implementation given the care setting. We refer readers to section III.A.2.d (“Minimum Standards” Code Sets) for further discussion of our proposal to adopt “Race & Ethnicity – CDC” code system in PHIN VADS as a minimum standards code set and Release 3.3.9, or potentially a newer version if released before a subsequent final rule, as the baseline for certification to the 2015 Edition. We propose in a later section of this proposed rule that the “Race & Ethnicity – CDC” code system in PHIN VADS (at a minimum, Release 3.3.9) and the OMB standard would become the race and ethnicity standards under the “Common Clinical Data Set” definition for certification to the 2015 Edition. Please see section III.B.3 “Common Clinical Data Set” of this preamble for further discussion of this associated proposal. Preferred Language Based on specific HITSC recommendations from 2011, we adopted ISO 639-2 constrained by ISO 639-1 for recording preferred language in the 2014 Edition “demographics” certification criterion (77 FR 54208).22 More specifically, this means that technology is required to be capable of using the alpha-3 codes of ISO 639-2 to represent the corresponding alpha-2 code in ISO-639-1. To provide further clarity, we issued FAQ 2723 in which we stated that where both a bibliographic code and terminology code are present for a required ISO 639-2 language, technology is expected to be capable of representing the language in accordance with the (T) terminology codes (ISO 639-2/T) for the purposes of certification. After we issued FAQ 27, we issued FAQ 4324 in which we acknowledge that our constrained approach to the use of ISO 639-2 unintentionally excluded multiple languages that are currently in use, such as sign language and Hmong. Additionally, ISO 639-2 is meant to support written languages, which may not be the language with which patients instinctively respond when asked for their preferred language. To improve the situation described above, we propose to adopt the Internet Engineering Task Force (IETF) Request for Comments (RFC) 564625 standard for preferred language. RFC 5646 entitled “Tags for Identifying Languages, September 2009” is the coding system that is commonly used to encode languages on the web and is the most current RFC for this purpose and listed as a “best current practice.”26 The first part of the code relies on the shortest ISO-639 code for the language. That means a 2-character code if the language is specified in ISO 639-1 or a 3-character code from ISO 639-2 or -3, if the language is only listed in one of those two ISO standards. We are also aware that RFC 5646 supports dialects. After consideration of comments we received on the Voluntary Edition proposed rule (79 FR 54450) and further research, we believe that RFC 5646 is the most appropriate standard to support preferred language interoperability. It is our understanding that this standard is compatible with the C-CDA Release 2.0 and that other preferred language standards in use today can be efficiently mapped to it, such as ISO 639-1, 639-2, and 639-3. Therefore, for the purposes of testing and certification to this “demographics” criterion, we would test that a Health IT Module can record a patient’s preferred language using any of the codes in RFC 5646. We emphasize that this requirement would apply to a Health IT Module presented for certification and not health care providers. In other words, a Health IT Module certified to this criterion would need to support the recording of preferred language in RFC 5646 and should in no way be interpreted or imply the way in which health care providers use the capability to record preferred language or the preferred language values they are presented with to select a patient’s preferred language. For example, we would not expect the user interface to include a drop-down menu of all RFC 5646 codes for language, as we believe doing so could have negative workflow effects. Rather, we expect that health IT developers and health care providers would work together to establish the appropriate implementation given the care setting. We propose in a later section of this proposed rule that RFC 5646 would also become the preferred language standard under the “Common Clinical Data Set” definition for certification to the 2015 Edition. Please see section III.B.3 (“Common Clinical Data Set”) of this preamble for further discussion of this associated proposal. Preliminary Cause of Death and Date of Death We propose to include in the 2015 Edition the capability to enable a user to electronically record, change, and access the “date of death” as a required capability that EHR technology designed for the inpatient setting must demonstrate. We previously included this capability as part of the 2011 Edition “demographics” certification criterion and inadvertently omitted it from the 2014 Edition. While we heard from commenters in response to the Voluntary Edition proposed rule that they were unaware of any developer removing this capability, we believe it is appropriate to specifically include this capability in the 2015 Edition criterion for testing and certification purposes and to align with the data required by the Meaningful Use criteria of the EHR Incentive Programs. To note, this functionality would be in addition to the inclusion in the 2015 Edition “demographics” certification criterion of the same capability to enable a user to electronically record, change, and access “preliminary cause of death” in case of mortality, as is included in the 2014 Edition “demographics” certification criterion.
Yüklə 1,55 Mb. Dostları ilə paylaş:
|