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).
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:
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.
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.
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.
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).
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.
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.
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:
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.
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:
In addition, we think the following information would be helpful, although perhaps not in this specific document:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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).
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.
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:
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.
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:
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.
In addition to combining both of the current data groups under Health Insurance Information, we propose inclusion of the following additional data elements:
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.
We propose the inclusion of the following additional data elements:
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.
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:
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.
We propose the inclusion of the following additional data elements:
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.
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.
Our Data Governance Collaborative suggests the following additional data element be supported:
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.
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.
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+ 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.
Instead of specifically collecting the farmworker status of a patient, we recommend collecting the employment category data for all patients.
We propose the inclusion of the following additional demographic data elements:
We propose the inclusion of the following additional data elements:
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:
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.
We propose the inclusion of the following additional data elements:
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.
We propose a screenings category including the following data:
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.
It is not at all clear what type of data is expected to be captured here or its potential use
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.
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
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.
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:
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.
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:
|
Property/data element |
Type |
Description/Allowed Values |
|
Source |
Enumerated list |
Allowed values: billing, encounter, problemList, thirdParty |
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.
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:
|
Property/data element |
Type |
Description/Allowed Values |
|
measureCode |
Enumerated list (but recommend open ended value) |
Identifies which measure the patient should be excepted from. We recommend using Measure Name for USCDI+ for Quality |
|
exceptionCode |
Enumerated list |
The reason the exception is valid. Allowed values: age, medicalHistory, medicallyNotPossible, notAffordable, notApplicable, postponed |
|
Reason |
String |
A more expansive description of why the exception is valid. May be a lengthy note. |
|
Frequency |
String |
Indicates the exception notes a change of frequency of requirements, not a lifting of requirements. For example, colonoscopies may be required for some patients every 2, 3, or 5 years instead of every 10 years. |
|
startDate |
Date |
Date exception begins |
|
endDate |
Date |
Date exception ends (optional) |
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.
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:
|
Property/data element |
Type |
Description/Allowed Values |
|
serviceProviderNpi |
Integer, minimum value= 1000000000. Maximum value= 29999999999 |
NPI of the clinician giving the immunization |
|
immunizationCode |
String |
Code representing the immunization given in the specified code system |
|
codeSystem |
Enumerated list |
Allowed values: cpt, cvx, hcpcs, mapped, snomed (mapped permits use of custom values) |
|
immunizatonName |
String |
The common name of the immunization |
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.
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:
|
Property/data element |
Type |
Description/Allowed Values |
|
orderingProviderNpi |
Integer, minimum value = 1000000000. Maximum value = 29999999999 |
NPI of the clinician ordering the laboratory service |
|
labId |
String |
Name or other identifier for the laboratory processing the results. We explored using one of the available ID standards but they were not widely/consistently enough used at the time |
|
serviceDate |
Date |
Date the test was administered to the patient (blood drawn, urine sampled, etc) |
|
resultDate |
Date |
Date the test results were processed by the laboratory |
|
summaryOfFindings |
String |
Provides a summary of a collection of findings when appropriate. For example, a chemistry blood panel could consist of multiple individual tests with specific results but there may be specific clinical findings dependent on the results of the panel as a whole. We believe this could map to the Result Interpretation data element introduced in USCDI v4 draft. |
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.
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:
|
Property/data element |
Type |
Description/Allowed Values |
|
orderingProviderNpi |
Integer, minimum value = 1000000000. Maximum value = 29999999999 |
NPI of the clinician ordering the medication |
|
endDate |
Date |
Date the patient stopped taking the medication |
|
Status |
Enumerated list |
Allowed values: active, continued, discontinued, increased, patientStopped, refilled, telephoneStart |
|
Frequency |
String |
How often a dose of the medication is taken by the patient |
|
Strength |
String |
The amount of active ingredient in a single item of a medication. Should include both number and unit for that number (ex: 5 mg). If a patient takes 2 pills at a time, this is the strength of a single pill. |
|
deliveryMechanism |
String |
The medication form: pill, liquid, ointment, nasal inhaler, oral inhaler, injection, auto-injector, etc. There was some discussion about turning this into an enumerated list in the future but the current specification allows any value. |
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.
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:
|
Property/data element |
Type |
Description/Allowed Values |
|
spokenLanguage |
String |
Preferred spoken language of the patient. If only one language is available, assume it’s the spoken language. If not supplied, use writtenLanguage if supplied. If no language value is supplied, use English as the default. |
|
writtenLanguage |
String |
Preferred written language of the patient. If not supplied, use spokenLanguage if supplied. If no language value is supplied, use English as the default. |
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.
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:
|
Property/data element |
Type |
Description/Allowed Values |
|
orderingProviderNpi |
Integer, minimum value = 1000000000. Maximum value = 29999999999 |
NPI of the clinician ordering the procedure |
|
serviceProviderNpi |
Integer, minimum value = 1000000000. Maximum value = 29999999999 |
NPI of the clinician performing the procedure |
|
Results |
String |
Clinical note outlining how the procedure went. This is not meant to include later analysis such as biopsies of removed materials; these should be captured in laboratoryServices data. |
|
Source |
Enumerated list |
Allowed values: billing, encounter, problemList, thirdParty |
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.
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: