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 “vital signs, BMI, and growth charts” certification criterion that is revised in comparison to the 2014 Edition “vital signs, BMI, and growth charts” criterion (§ 170.314(a)(4)). Specifically, we propose to: 1) expand the types of vital signs for recording; 2) require that each type of vital sign have a specific LOINC® code attributed to it; 3) that The Unified Code of Units of Measure, Revision 1.9, October 23, 2013 (“UCUM Version 1.9”) 27 be used to record vital sign measurements; and 4) that certain metadata accompany each vital sign, including date, time, and measuring- or authoring-type source. Proposed Approach for Vital Signs In the Voluntary Edition proposed rule (79 FR 10889-10890), we solicited comment on whether we should require health IT to record vital signs in standardized vocabularies. We solicited comments on whether we should require that vital signs be recorded in standardized vocabularies natively within the health IT system or only during transmission. We also solicited comment on whether we should require vital signs be recorded with specific metadata for contextual purposes. Many commenters recommended that the industry should standardize how vital signs are represented and collected. To this end, we are aware that several stakeholder groups are working to define unique, unambiguous representations/definitions for clinical concepts along with structured metadata that together provide improved context for the system to interpret information, including vital signs. This approach can help increase data standardization at a granular level so that clinical elements and associated values/findings can be consistently represented and exchanged. For example, blood pressure is represented in current systems using a variety of formats, which creates significant challenges to aggregate, compare, and exchange data across systems. This occurs despite the numeric nature of blood pressure, resulting in costly and time-consuming manual translation to integrate this data across systems. Some commenters supported requiring standardized vocabularies for vital signs during data exchange rather than natively within the health IT system. While we agree that data should be exchanged in a standard way, we also believe that the granularity necessary to unambiguously represent this data should be implemented within health IT systems so that data is captured with the same level of specificity to enable consistent and reliable interpretation by other data users and receivers without requiring mapping. Thus, we propose that health IT demonstrate it is able to record vital signs data natively as specified below. Overall, these proposals reflect our interest in ensuring that the data a user enters into a health IT system is semantically and syntactically identical to the information coming out of the system and being exchanged. We believe this would increase the confidence that the data exchanged is what the provider intended. The 2014 Edition “vital signs” certification criterion requires health IT to enable a user to electronically record, change, and access a patient’s height/length, weight, and blood pressure. We propose to include BMI, heart rate, respiratory rate, temperature, oxygen saturation in arterial blood by pulse oximetry, and mean blood pressure as we understand that these vital signs are commonly captured or calculated (i.e., BMI) in the routine course of clinical encounters across a wide variety of both inpatient and ambulatory settings. We also propose to further specify that health IT would need to be able to record diastolic and systolic blood pressure as separate vital signs rather than “blood pressure” (unspecified) as a single vital sign. We clarify that this list of vital signs is not intended to be comprehensive. Rather, these listed vital signs indicate our interest in a more specific approach to recording and exchanging vital signs data that could promote unambiguous interpretation. These vital sign concepts derive from the C-CDA standard and the Public Health Information Network Vocabulary Access and Distribution System value set for vital sign result types28 (2.16.840.1.113883.3.88.12.80.62), which was developed by the Health IT Standards Panel.29 Therefore, we believe the health care community has experience with collecting these vital sign concepts because they have been defined for some time as part of previous collaborative stakeholder work. We propose to require that a Health IT Module be able to attribute a specific LOINC® code to each type of vital sign using the following identifiers:
We understand that the industry is commonly identifying these vital signs using LOINC® codes today. We also propose to require that a Health IT Module enable a user to record these vital signs with at least the following metadata:
In some cases, the provider documenting the vital sign may record the date and time of vital sign measurement manually and enter the data into a health IT system at a later time; therefore, it would not be necessary to use the clock synchronization standard. However, use of the clock synchronization standard may be useful for situations where the vital sign data comes from a device and should be synchronized with the health IT system. For “oxygen saturation in arterial blood by pulse oximetry,” we propose that a Health IT Module enable a user to record “inhaled oxygen concentration” with LOINC® code 3150-0 as metadata associated with the vital sign. We understand that “inhaled oxygen concentration” is frequently provided to assist with interpretation of the “oxygen saturation in arterial blood by pulse oximetry” value. For all units of measure associated with a vital sign value, we propose to require that health IT be able to record an applicable unit of measure in accordance with UCUM Version 1.9 (e.g., the UCUM unit “mm[Hg]” for systolic blood pressure; e.g., the UCUM unit “[lb_av],” “g,” “kg,” or “[oz_av]” for body weight). We note that LOINC provides a translation table30 that enumerates the UCUM syntax for a subset of UCUM codes that are commonly used in health IT that may be a useful reference for stakeholders.
We propose to offer optional certification for health IT to be able to electronically record, change, and access:
We propose to require that a Health IT Module enable each optional vital sign to be recorded with an applicable unit of measure in accordance with UCUM Version 1.9. CDC recommends the collection of these anthropomorphic indices for youth 2-20 years of age and infants less than 3 years of age, respectively, as part of best care practices.31 A Health IT Module certified to the “BMI percentile per age and sex,” “weight for length per age and sex,” or “head occipital-frontal circumference by tape measure” vital signs would also need to record metadata for the date and time or end time of vital sign measurement, the measuring- or authoring-type source of the vital sign measurement, the patient’s date of birth, and the patient’s sex in accordance with the standard we propose to adopt at § 170.207(n)(1). We believe offering optional certification to these three vital signs can provide value in settings where pediatric and adolescent patients are provided care. Request for Comments on Vital Signs Proposal We intend that the LOINC® codes proposed for attribution to the vital signs in the list above are neutral to, and therefore can encompass, any clinically reasonable method of measurement that is commonly used in obtaining vital signs in the course of clinical encounters in a wide variety of contexts, including but not limited to, primary-care office/clinic visits, emergency department visits, and routine inpatient admissions processes. For example, this would mean the system would attribute “body height” to LOINC® code 8302-2 for the measurement of how tall or long the patient is. This measurement is collected as part of routine vital signs observation regardless of whether this clinical observation was made by measuring a standing or supine adult/child, or a supine infant, or by estimating through clinically reasonable methods the height/length of an adult or child who cannot be measured in a standing or fully supine position. Likewise, we propose to attribute a specific LOINC® code for body temperature regardless of whether the temperature was measured by a liquid-filled, digital/electronic, or infrared (non-contact) thermometer. The choice of UCUM unit code will indicate whether the measurement was taken in English or metric units. The metadata describing the source of the measurement would provide the context of the device that was used to perform the measurement. We reiterate that the intent behind this “vital signs” proposal is to ensure that the data a user enters into a health IT system is semantically and syntactically identical to the information coming out of the system and being exchanged, allowing other users to unambiguously and consistently interpret the information. We anticipate that stakeholders may want to expand the list of metadata beyond the date, time, and source of vital sign measurement. We welcome comment on additional vital sign metadata that we should consider for inclusion and the best available standards for representing the metadata (e.g., LOINC® or a similar standard). Health IT users may currently capture vital signs in more granular LOINC® codes that specify the method of measurement. We therefore solicit comment on the feasibility and implementation considerations for our proposals that rely on less granular LOINC® codes for attribution to vital sign measurements and the inclusion of accompanying metadata. Additionally, we solicit comment on the following issues:
We also solicit comment on whether we should require a Health IT Module to be able to record metadata specific to particular vital signs results/findings. This could provide additional contextual information (e.g., position for diastolic and systolic blood pressure, whether the patient is breathing supplemental oxygen, the site of the temperature such as oral or rectal, pregnancy status for BMI, and whether the vital sign was measured or self-reported). Because the LOINC® code associated with some vital sign concepts we are proposing may include whether the vital sign was measured or self-reported (e.g., body weight measured), we also request comment on which specific vital signs should include metadata on whether it was measured or self-reported. If we were to require a Health IT Module to be able to record metadata specific to particular vital signs, we solicit comment on what additional metadata should be required for certification and what standards (e.g., LOINC® or a similar standard) we should consider for representing that data. We note, with respect to arterial oxygen saturation, that we are proposing here the type of measurement that we understand to be commonly performed as part of vital signs observation across a wide variety of clinical settings. We are aware that in some clinical circumstances oxygen saturation in arterial blood by pulse oximetry is not a sufficiently precise measurement to support sound clinical decisions. We therefore invite comment as to whether we should consider defining the arterial blood oxygen saturation vital sign in a more method-agnostic way, and whether we should also require capture and exchange of more robust metadata to ensure technology could reliably identify to clinicians seeking to use the value whether it was measured by pulse oximetry or a more precise but more invasive and, in most clinical contexts, less commonly performed arterial blood gas (ABG) test. We propose in a later section of this proposed rule that vital signs be represented in same manner for the “Common Clinical Data Set” definition as it applies to the certification of health IT to the 2015 Edition. Note that the optional portions of the proposed vital signs criterion would not be required for the “Common Clinical Data Set” (i.e., BMI percentile per age and sex for youth, weight for length for infants, head occipital-frontal circumference by tape measure, calculating BMI, and plotting and displaying growth charts.) Please see section III.B.3 (“Common Clinical Data Set”) of this preamble for further discussion of this associated proposal. Problem List
We propose to adopt a 2015 Edition “problem list” certification criterion that is revised in one way as compared to the 2014 Edition “problem list” certification criterion (§ 170.314(a)(5)). We propose to include the September 2014 Release of the U.S. Edition of SNOMED CT® in the 2015 Edition “problem list” certification criterion as the baseline version permitted for certification to this criterion. The 2014 Edition “problem list” criterion included the July 2012 Release of SNOMED CT® (International Release and the U.S. Extension) as the baseline version permitted for certification. We also refer readers to section III.A.2.d (“Minimum Standards” Code Sets) for further discussion of our adoption of SNOMED CT® as a minimum standards code set and our proposal to adopt the September 2014 Release (U.S. Edition), or potentially a newer version if released before a subsequent final rule, as the baseline for certification to the 2015 Edition. Medication List
We propose to adopt a 2015 Edition “medication list” certification criterion that is unchanged as compared to the 2014 Edition “medication list” certification criterion (§ 170.314(a)(6)). To note, this proposed criterion does not reference any standards or implementation specifications. Medication Allergy List
We propose to adopt a 2015 Edition “medication allergy list” certification criterion that is unchanged as compared to the 2014 Edition “medication allergy list” certification criterion (§ 170.314(a)(7)). We received comments in response to the Voluntary Edition proposed rule suggesting that a “medication allergy list” criterion should include also other types of allergies and intolerances, such as food and environmental allergies (79 FR 54451-52). We are aware of a number of vocabularies and code sets that could support food and environmental allergies as well as medications, but believe that the industry is working on identifying ways that multiple vocabularies and code sets can be used together in an interoperable way to support coding of allergies. Therefore, at this time, there is no ready solution for using multiple vocabularies to code allergies that could be adopted for the purposes of certification. Clinical Decision Support
Yüklə 1,55 Mb. Dostları ilə paylaş:
|