About MHDC

Founded in 1978, MHDC, a not-for-profit corporation, convenes the Massachusetts’s health information community in advancing multi-stakeholder health data collaborations. MHDC’s members include payers, providers, industry associations, state and federal agencies, technology and services companies, and consumers. The Consortium is the oldest organization of its kind in the country.

MHDC provides a variety of services to its members including educational and networking opportunities, analytics services on both the administrative and clinical side (Spotlight), and data governance and standardization efforts for both clinical and administrative data (the Data Governance Collaborative/DGC and the New England Healthcare Exchange Network, respectively).

About DGC

The DGC is a collaboration between payer and provider organizations convened to discuss, design, and implement data sharing and interoperability among payers, providers, patients/members, and other interested parties who need health data. It is a one stop interoperability resource. The DGC primarily focuses on three areas:

1. Collaboration: Development of common understanding of and specifications for data standards, exchange mechanisms, and what it means to participate in the modern health IT ecosystem
2. Education: helping members understand their regulatory obligations, the data and exchange standards they're expected to use, and modern technology and related processes
3. Innovation: Identification and development of projects and services needed to make modern health data practices and exchange a reality

Particularly pertinent to this comment is the DGC history working on quality measures. The first major project of the DGC involved creating a (pre-FHIR) flat file data exchange using Secure FTP to send data between payers and providers. This specification – called the MHDC Quality Measures specification - was developed collaboratively in conjunction with payers and providers in Massachusetts, was first released on December 31, 2019, and is still in use.

General Comments

This section includes general comments on the approach and data included in the USCDI+ for Quality dataset and its place in the quality measures ecosystem.

Definitions

It would be helpful to have basic definitions or intent for the data elements accompany each data element in the list. While it’s true that some come directly from USCDI and many others are found in the proposed but not ready sections, it is extremely tedious to look up data elements individually to discover whatever information is available about them one at a time. Further, some of the elements that are most opaque appear to come mainly from other sources.

Links to USCDI Listings

Extending the previous comment, including a direct link to a data element’s entry on the main USCDI website (whether formally adopted into USCDI or still in one of the “under consideration” levels) would be extremely helpful (when such an entry exists).

Consistent Casing

We note that most data class and data element names capitalize the first letter of each word, but a few do not (for example, several longer data element names under Newborn Delivery Information). It would make the list easier to read if this formatting was applied universally.

Using Plurals for Data Class Names

In general, data class names are plural – Goals, not Goal or Problems not Problem. However, a few of the new data classes in this list use the singular form for no apparent reason (examples: Referral, Substance). The naming rules should be consistently applied unless there is a substantive reason to do something different.

Cadence for Updates

We believe USCDI+ for Quality updates should trail NCQA HEDIS requirements releases so people can use the data needed for a HEDIS release to inform their comments during the public feedback period.

NCQA currently does a major release for each measure year during August of the year preceding the start of collection with a follow up smaller “corrections” release the following March during the collection period and approximately a year before the actual reporting period for the measure year. For example, the major release of MY2024 requirements should happen in August 2023 with a smaller “corrections” release in March 2024 to be used for reporting covering calendar year 2024 and reported during the spring of 2025.

We believe it makes sense for USCDI+ for Quality to follow and produce a new major version followed by a smaller version with small corrections and changes each year in keeping with the NCQA releases.

We propose the following annual schedule or something similar for USCDI+ for Quality updates:

• September: annual version N.0 draft release
• November: public comment on N.0 draft deadline
• January: annual version N.0 final release
• April: annual version N.1 draft release
• June: public comment on N.1 draft deadline
• August: annual version N.1 final release

Given that the N.1 releases are likely to be small, compressing the timeframe for those releases may be acceptable. However, we urge ONC to ensure there is sufficient review time for public comment even if there is significant other regulatory activity going on at the same time.

We note this cycle also allows the annual N.0 USCDI+ for Quality draft to consider and include data that was also added to that year’s USCDI version likely finalized in July.

Comments on Guidance Document

We appreciate that many users may find a mapping between the USCDI+ for Quality, the QI-Core implementation guide, and current CMS quality measures useful. However, we urge that the document add the following:

• Direct links to the relevant QI-Core profile on the HL7 website
• Direct links to descriptions of the listed CMS quality measures
• Mapping between USCDI+ for Quality and HEDIS measures/related data

In addition, we think the following information would be helpful, although perhaps not in this specific document:

• Descriptions of each data element (see comment above)
• Code systems, value sets, or other constraints placed on the allowed values

Intended purpose of USCDI+ for Quality and Its Place in the Existing Quality Measures Ecosystem

It is unclear exactly how USCDI+ for Quality fits into the existing emerging systems for quality measures specification and data exchange. Our Data Governance Collaborative struggled with understanding this as we evaluated the USCDI+ proposal and we urge both ONC and CMS to address this clearly, comprehensively, and directly. Some of the specific topics we think need to be addressed are included below.

Requirements for Comprehensive USCDI+ for Quality Data Exchange

It is our understanding that the USCDI+ program generally is meant to define minimum data sets for support and exchange for specific major use cases (in this case quality measures) that could then be used in interoperability and other regulations to mandate specific support and exchange requirements. As the first publicly available USCDI+ dataset, discussion of purpose and intended use from this perspective would be helpful.

As part of this, addressing the universe of quality measures intended for inclusion would be helpful. It is our belief this is meant to be as all-encompassing as possible, but outlining some specific common types of quality measures to consider while evaluating the completeness of the dataset (such as inpatient hospital measures, outpatient clinical measures, patient-reported measures, etc.) would be helpful. More specifically, if there are common types of quality measures and the corresponding data meant to be explicitly excluded from this dataset would be extremely helpful.

Relationship between USCDI+ for Quality and QI-Core Implementation Guide

It is unclear at this time if there is an intent to develop a symbiotic relationship between USCDI+ for Quality and QI-Core similar to the relationship between USCDI and US Core. Is QI-Core seen as the FHIR implementation of USCDI+ for Quality even when there’s not an exact 1-1 relationship and is QI-Core expected to produce new versions that align with future versions of USCDI+ for Quality. Discussion of the expected relationship between the two would be extremely helpful for potential users of the dataset, especially if they wish to use it in conjunction with FHIR.

Relationship between USCDI+ for Quality and Quality Measures/Data Exchange for Quality Measures Implementation Guides

At the current time much of the quality measures work happening via FHIR uses the Quality Measures implementation guide (QM IG) to define specific measures in FHIR and the Data Exchange for Quality Measures implementation guide (DEQM IG) for exchanging exactly the data needed to calculate measures defined in the QM IG format. When asked why this approach was chosen over exchange of a more general quality measures data set at once, folks developing those IGs responded the industry wasn’t ready for larger data exchange models at the time.

We note that the industry is currently expecting large scale data exchange of USCDI data as represented by the US Core IG so the concept of such exchanges is not a reach at this time. At the same time, existing industry quality measures work, while not extensive, is ongoing using the QM/DEQM IGs. It would be helpful if the relationship between the two models of quality-related data exchange – a single larger pot of data as represented by USCDI+ for Quality vs multiple smaller, more specific (possibly duplicative) exchange as needed for each individual measure per QM/DEQM– was discussed in some detail.

Relationship between USCDI+ for Quality and Specific dQMs and eCQMs from CMS and NCQA

Again, how does the upcoming release of USCDI+ for Quality impact existing plans, standards, and mechanisms in place and in the pipeline for dQMs and eCQMs from CMS and NCQA. Our Data Governance Collaborative was confused about how to think about USCDI+ for Quality within the context of HEDIS quality measure requirements. Specific, clear guidance on how this initiative fits into the existing models of electronic quality measures definition, collection, and calculation would be extremely helpful.

ONC Certification Against USCDI+ for Quality

In order for widespread, consistent support of USCDI+ for Quality to happen on the provider side, ONC certification programs are likely necessary. Our Data Governance Collaborative wanted to know if this was being planned and, if so, whether it would be a part of a wider Quality Measures certification program that might involve other components. While we understand certification program details cannot be outlined within USCDI+ for Quality documents, high level discussion of intentions and plans in this area would be helpful.

Level of Data Definition

Our Data Governance Collaborative felt like many of the data elements included in USCDI+ were not defined at the right level to indicate the desired data represented. For example, the Family Health History data class just includes a single data element also called Family Health History. Instead, the specific data intended to be part of the history should be specified so an actual baseline expectation of the required data is set. In general, we favor specific structured data elements over vague, general, composite data elements.

Time data elements

We note that many different data classes within USCDI+ for Quality include a time data element but no corresponding date element. We encourage the use of datetime or separate time and date elements (consistently using one or the other) but regardless feel capturing the date is generally important, particularly if a time is already expected.

USCDI Versions

Many of the notations of USCDI inclusion provided in the USCDI+ for Quality draft do not accurately map to the initial version of USCDI that supported the data element. We called out specific cases we noticed in individual comments below, but we urge ONC to do a full scrub of the dataset to correct any other currently incorrect citations we may have missed.

Response to Specific Data Classes and Data Elements and Request for Missing Elements

This section will address specific data classes and data elements in the USCDI+ for Quality proposal and comment on potentially missing data. We are including a section outlining data we collect for our MHDC Quality Measures specification not included in USCDI+ for Quality. In general, we chose not to separately list those data elements in the more general comments about the same data elements.

Advance Directives data

We note that this dataset does not capture any information about the invocation of an advance directive (or evaluation then rejection of its use for a mandated reason). We believe data in this area should be collected and available. Some specific data elements might include:

• Advance Directive Invoked
• Date Invoked
• Provider Evaluating Advance Directive
• Actions Taken (to include actions not taken that would have been otherwise)
• Date Action Taken
• Advance Directive Request Rejected
• Rejection Reason

However, we are not certain that this is the entire breadth of data needed to track and measure this area or other aspects of advance directives and suggest coordinating with other groups working specifically on advance directives such as PACIO and the Massachusetts Coalition for Serious Illness Care.

Adverse Events and Allergies/Intolerances

Our Data Governance Collaborative notes that it can be difficult to determine the difference between an adverse event and an allergy/intolerance at times and that some events may qualify as both. Guidance around how to address this would be helpful.

Further, a reference to another data element related to the event – such as a procedure or encounter during which it occurred or a medication or immunization causing a specific reaction – seems warranted. We see this separate from causality which carries with in specific information about why the adverse event happened.

Birth Information vs Newborn Delivery Information

Our Data Governance Collaborative got very confused regarding the intention of these data classes. Is the patient/person about which the data is being reported in this case the person who gave birth or the baby? We initially interpreted both categories as intended to be for the same individual – whether that person is currently still a newborn or now 100 years old or somewhere in between. After some examination of the data elements and discussion among the group, we think perhaps the Birth Information is intended to be interpreted this way but Newborn Delivery Information may be intended to be captured for any newly delivered child of that individual. Specific clarity around the intention of these data classes would be extremely helpful.

Cancer Care

Our Data Governance Collaborative participants believe that toxicity screening should be part of the supported cancer care data. In addition, they note that capturing and managing adverse events from treatment are a major part of cancer care and believe the link between the two should be captured and managed (but that could likely be handled via references/links from data captured under the Adverse Events data class).

Care Experience and Outcomes

The data elements included in this data class are too vague and we were unable to figure out what data was intended to be captured here. We also suggest that the care experience and care outcomes are very different things and perhaps should be captured in separate data classes.

Communications

This Is another data class where the intent is very unclear and the types of communications to capture should be specified. Is this meant to show that required documentation such as HIPAA privacy policies have been provided? To collect data on how often providers receive and respond to messages from a patient portal? Capture letters sent to patients sharing results of various tests or evaluations? That pre-appointment documents were supplied to a patient for them to fill out?

Regardless, we feel that, at a minimum, the following data elements are missing:

• Writer
• Reviewer
• Role of Responder
• Requested (is this in response to a specific request)
• Initiator (was this initiated by the patient, provider, or payer)

Family Health History

In addition to the general comment above regarding the lack of specificity in the single supplied data element, we wonder if there are also potential consent issues around including family health history data in a dataset that may potentially be widely required and exchanged. While relevant to the patient, the majority of data captured is actually the health data of other individuals who often can be identified based on the level of information provided. We question whether some requirement for their consent to collect this data in a potentially exchangeable manner or their consent to actually exchange the data should be required.

Goals

We find this data class perplexing. We applaud the concept of collecting patient goals and, within the context of quality measures it may make sense to track whether these goals were accomplished or the number of individuals with goals in certain specific areas such as weight loss, smoking cessation, reducing alcohol intake, or other such goals. However, the data class as used appears to be capturing two very specific types of goals related to specific types of functional assessments.

We believe it may make more sense to have separate Functional Assessment and Goals data classes with the current data elements moved under functional assessments if they are meant to be tied to specific assessments or rename the existing goals to Self Care and Mobility which are reasonable categories to have goals in separate from any functional assessments. We propose either having general goals data elements that can encompass any goals or keeping the current goals and also adding some or all of the following types of goals:

• Physical activity goals
• Weight loss goals
• Alcohol consumption goals
• Smoking frequency goals
• SDOH goals
• Healthy Habits goals (use of seatbelts, sunscreen, bike helmets, etc)

Health Insurance vs Health Insurance Information

The USCDI+ for Quality includes both a Health Insurance and a Health Insurance Information data class. It is not at all clear what the difference between them is or why both are needed. Unless there is some hidden rationale we do not understand, we recommend collapsing both under Health Insurance Information to match the terminology used in USCDI. If there is a reason for the distinct data classes we urge ONC to explain it and why the various data elements are placed in one data class or the other.

Health Insurance Information data

In addition to combining both of the current data groups under Health Insurance Information, we propose inclusion of the following additional data elements:

• Plan Name
• Plan Category (HMO, PPO, MA, Medicare FFS, etc)
• Initial Coverage Effective Date
• Plan Rollover Date

Medical Devices and Equipment vs Medical Devices

We urge ONC to use consistent naming between USCDI and USCDI+ for Quality whenever possible. USCDI uses the data class name Medical Devices whereas USCDI+ for Quality uses Medical Devices and Equipment. If the longer name is deemed more appropriate then we urge ONC to use it in both data sets and change Medical Devices to Medical Devices and Equipment when USCDI v4 is finalized or, if that’s not possible, starting in USCDI v5 draft.

Medical Devices data

We propose the inclusion of the following additional data elements:

• Installation Date (for implantable devices)
• Start Date (for non-implantable devices)
• Prescription Date (for prescribed devices)

Medical Device Type

The Device Type data element under Medical Devices and Equipment indicates it comes from USCDI v4 draft. However, there is no such element listed on the ONC USCDI v4 draft web listings. There remains just one element under that class, although it appears to have been renamed Medical Device Identifier – Implantable from its v3 name of just Medical Device Identifier.

Medication Dates

There are two date elements in the Medications data class: Date Medication Administered and Date Medication Prescribed. It seems like there should be a third date option, Date Medication Filled. Logically, the three dates have clear and distinct meanings:

• Date Medication Prescribed: the date the medication is ordered by a clinician
• Date Medication Filled: the date the medication is filled by a pharmacist (outpatient or inpatient)
• Date Medication Administered: the date the medication is given to the patient by a clinician

We believe all three have useful and distinct meaning as outlined above, although not all may apply to each medication, and not clearly outlining the distinctions will lead to inconsistent data. If only two are collected, it seems like Date Medication Filled will be applicable in more cases than Date Medication Administered.

Medications data

We propose the inclusion of the following additional data elements:

• Pharmacist
• Pharmacy

Birth Weight vs Birthweight

The Newborn Delivery Information data class contains one data element using birthweight as one word and one splitting it into two word. We ask ONC to be consistent and recommend using two words in both places.

Birth Information::Gestational Age vs Newborn Delivery Information::Gestational Age at Delivery

It seems duplicative to include both of these data elements. If this data is desired for every patient regardless of age, then it makes sense to have a general Birth Information data class with a Gestational Age or Gestational Age at Delivery data element (we prefer the latter as it’s more explicit). If it is only needed for newborns, then it makes more sense to retain it under Newborn Delivery Information.

We note our general comment above where we posit that perhaps the Birth Information data class is meant to apply to all patients while the Newborn Delivery Information data class is meant to apply to the newborn child of the patient in question. Please clarify and if this is the case, then we withdraw this specific comment.

Newborn Delivery Information data

Our Data Governance Collaborative suggests the following additional data element be supported:

• Feeding Method at Hospital (breast feeding vs formula vs combination)

Patient Demographics vs Patient Demographics/Information

We again urge consistent naming between USCDI and USCDI+ for Quality. USCDI uses Patient Demographics/Information as the name of its data class, USCDI+ for Quality should do the same.

Birth Sex

USCDI+ for Quality includes a Birth Sex data element and indicates it’s part of USCDI v3. However, USCDI v3 does not include a Birth Sex or Sex (Assigned at Birth). The Sex (Assigned at Birth) data element was removed from USCDI in v3. We have no argument with including Birth Sex or Sex (Assigned at Birth) in USCDI+ for Quality, but it is not accurate to map it to USCDI v3 or later.

Since Sex (Assigned at Birth) is no longer part of USCDI, we have no problem using the Birth Sex label currently in USCDI+ for Quality so long as the term is consistently used among any or all other USCDI+ data sets that may include the same concept.

Gender vs Gender Identity

USCDI uses the name Gender Identity for its gender data element while USCDI+ for Quality just uses Gender. As the data element is noted as being included in USCDI we assume that it is intended to capture the same data and thus it should use the same name for consistency and clarity.

USCDI version of Race, Ethnicity, and Gender/Gender Identity

USCDI+ for Quality indicates the data elements Race, Ethnicity, and Gender/Gender Identity are part of USCDI v3, but Race and Ethnicity have both been part of USCDI since v1 and Gender Identity was added in v2.

Employment Category

Instead of specifically collecting the farmworker status of a patient, we recommend collecting the employment category data for all patients.

Patient Demographics data

We propose the inclusion of the following additional demographic data elements:

• Marriage or Partner Status
• Patient Lives Alone
• Environmental Hazards Exposure Status

Pregnancy Status

We propose the inclusion of the following additional data elements:

• Prenatal Care Status
• Temporary Diagnoses (gestational diabetes, pre-eclampsia, etc)
• Known Risks
• Amniocentesis Status
• Amniocentesis Results

We also feel like the following postpartum data should be collected either as part of this data class or in a new one for post-pregnancy:

• Post-Partum Depression screening
• Postpartum checkup status

SDOH/Health Concerns

USCDI+ for Quality includes a data element called SDOH/Health Concerns under the Problems data class, noted as included in USCDI as of v3. We assume this is intended to map to the SDOH Problems/Health Concerns data element under Problems in USCDI which was added in USCDI v2. Alternately, it could be intended to map to the Health Concerns data element which has been part of USCDI since v1 under different data classes (currently under Health Status Assessments). Please clarify the intent and fix the USCDI version to help make it clear which USCDI element is being mapped.

Referrals data

We propose the inclusion of the following additional data elements:

• Referring Provider
• Reason for Referral

Date of Physician-ordered Start of Care (Resumption of Care) data element

This Is an extremely confusing name, is perhaps trying to capture more than one specific type of data, and is not clearly related to a referral. Please clarify the intent of this data element and provide a name that more clearly indicates what data it is meant to convey. If needed, split it into multiple data element each with a very specific purpose/intent.

Screenings

We propose a screenings category including the following data:

• Date Administered
• Time Administered
• Format (portal, telephone, email, app, onsite, etc)
• Screening Name
• Screening Score
• Ordering Provider
• Screener (person giving the screening, if any)
• Screener Role

We note specific data collected via the screenings may appropriately fit into other categories of either USCDI or USCDI+ for Quality data. We were on the fence about recommending inclusion of the entire screening results and not just the score but ultimately decided it was likely enough of the data would be captured elsewhere to make it superfluous.

Substance data class

It is not at all clear what type of data is expected to be captured here or its potential use

Substance (Non-Medicine) and Substance (Food) data elements

It seems strange to have Substance (Non-Medicine) and Substance (Food) data elements under the Substance data class rather than just Non-Medicine and Food. We also note that food is not medicine, so some clarity around whether the non-medicine data element should explicitly exclude food would be helpful.

Height on Admission (in inches) and Weight on Admission (in pounds) Measure weight consistently according to standard facility practice (e.g., in a.m. after voiding, with shoes off, etc.) data elements

The names of these two data elements are weird. Firstly, they are the only data elements that include the expected unit of measure in their name. Also, we assume the string after the (in pounds) parenthetical for weight is more like a clarifying note that should be part of a description rather than part of the name

Weight/Height on Admission vs Body Weight/Body Height

First, it is a bit surprising to see weight on admission and not the regular Body Weight data element from the USCDI vital signs. We would expect it to be included in the USCDI+ for Quality data set. However, it is unclear why the additional “on admission” data elements are necessary as a regular Body Weight/Body Height instance could just be associated with an admission event. This seems like a more consistent way to handle these measurements.

Vital Signs data

Our Data Governance Collaborative participants felt like the vital signs covered by the USCDI+ for Quality made sense but noted that they need the following additional information about each vital sign:

• Date
• Time
• Taken By

Additional Data Captured by MHDC Quality Measures Specification Not in USCDI+ for Quality

We note that without full descriptions of the data elements in USCDI+ for Quality it is possible that some of this data is intended to be captured in existing fields but we don’t understand the intended mapping. In particular, the granularity and, at times, exact expected use of some of the medication-related data elements is unclear.

We have tried to identify analogous data elements in USCDI when they exist.

Diagnoses/Problems

The MHDC specification includes a Diagnoses data class we are mapping to the Problems data class in USCDI+ for Quality. The existing USCDI+ for Quality data elements in this class support all of our existing Diagnoses data except for a source property. This property is defined as follows:

We feel that a Provenance data element in Problems is the logical mapping and something that would be widely useful for everyone exchanging such data. We would prefer that the values we use be supported, but do not profess they cover all potentially useful options.

Exceptions

The MHDC specification includes a data class called Exceptions that provides data about patients who should be excepted from certain otherwise required quality measures with supporting data showing why.

We see no analog to this data class in USCDI+ for Quality. Portions of our definitions are too specific for a general standard as they reference specific quality measures, but at a higher level here is the content we currently capture:

Again, we do not suppose that we’ve identified all reasonable allowed values for data elements with enumerated lists/value sets. However, we would hope that the values we are currently using would be among those supported by USCDI+ for Quality if the analogous concepts are added.

Immunizations

The MHDC specification includes an Immunizations data class clearly mapping to the Immunizations data class in USCDI+ for Quality. The existing USCDI+ for Quality data elements in this class support all of our existing Diagnoses data except for the following:

We note that the lack of specification of the actual immunization by either name or code/code set pair or both in USCDI+ for Quality seems like an important oversight to correct regardless of whether you decide to support the other data elements present in our existing specification. These would likely map to the Immunizations data element first defined in USCDI v1.

LaboratoryServices/Laboratory

The MHDC specification includes a LaboratoryServices data class we are mapping to the Laboratory data class in USCDI+ for Quality. The existing USCDI+ for Quality data elements in this class support all of our existing LaboratoryServices data except for the following:

We also had a consistent mechanism in our results property for indicating trace amounts that cannot be explicitly measured in a laboratory result. It may be reasonable to add a specific data element, perhaps a Boolean, to capture this data in a cohesive and clear way.

Medications

The MHDC specification includes a Medications data class clearly mapping to the Medications data class in USCDI+ for Quality. The existing USCDI+ for Quality data elements in this class support all of our existing Medications data except for the following:

We note in our system dose is the number of units of the medication taken (number of pills, puffs, injections, spoonfuls, etc) at once (can be fractional to account for pill splitting) so both dose and strength are needed in combination to indicate how much medication a patient uses at one time. The quantity is the number of units included in a single prescription fill and not related to the dosing.

Memberships/Patient Demographics

The MHDC specification includes a Memberships data class we are mapping to the Patient Demographics data class and the Health Insurance/Health Insurance Information data classes in USCDI+ for Quality. The existing USCDI+ for Quality data elements in these classes support all of our existing Memberships data except for the following:

Our specification captured both written and spoken language when both are available. This is useful, distinct information and we believe capturing it when available is useful for not just quality measures but any patient data use case.

Procedures

The MHDC specification includes a Procedures data class clearly mapping to the Procedures data class in USCDI+ for Quality. The existing USCDI+ for Quality data elements in this class support all of our existing Procedures data except for the following:

The results property logically maps to the Procedure Note data element of the Clinical Notes data class introduced in USCDI v1. We feel that a Provenance data element in Procedures is the logical mapping for the source property and something that would be widely useful for everyone exchanging such data. We would prefer that the values we use be supported, but do not profess they cover all potentially useful options.

Specific Observations/Tests

The MHDC specification requires support for certain specific tests and their results. These items fall under existing categories of the USCDI+ for Quality and thus it is unclear if there is any need to note them explicitly, but we are providing a list in case it would be useful to you:

These are technically laboratory results but they are expected to be supported and exchanged using specific results formats by our specification. We are not sure if such things warrant explicitly being called out in USCDI+ for Quality or just generically fall under laboratory data. These tests include:

• A1c
• Albumin
• Hematocrit
• Hemoglobin
• LDL Cholesterol
• Lead test