ONC USCDI+ for Behavioral Health Draft Dataset
May 9, 2024 •MHDC (DGC)
This document is submitted by the Massachusetts Health Data Consortium (MHDC) and its Data Governance Collaborative (DGC) on May 9, 2024 in response to the ONC USCDI+ for Behavioral Health Dataset draft posted on the USCDI+ website and found here:
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:
- 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
- Education: helping members understand their regulatory obligations, the data and exchange standards they're expected to use, and modern technology and related processes
- Innovation: Identification and development of projects and services needed to make modern health data practices and exchange a reality
General Comments
This section includes general comments on the approach and data included in the USCDI+ for Behavioral Health dataset including the presentation and organization of the set as a whole.
Purpose for Comprehensive Care vs General Healthcare Data Exchange via USCDI
This may be a case of needing more context or guidance on the intent of this use case, but as presented our Data Governance Collaborative is a bit perplexed by both the use case generally and its contents. The goal as stated is laudable – promoting the integration of behavioral and physical healthcare services – but it appears to be a set of general clinical and patient data that mostly (but not entirely) mirrors USCDI proper. If the goal is just to ensure behavioral health professionals obtain relevant clinical and patient data, then in theory USCDI should meet that goal. This is, in fact, the point of USCDI – to define the minimum set of clinical, patient, and other data needed to inform all interested parties, coordinate care, and otherwise feed data into the operations and treatment of healthcare.
If there are missing data elements for coordinating physical health, those should be submitted and promoted through USCDI as they are not specific to behavioral health, but suggestions that were felt useful about care more generally. If trying to integrate data about physical healthcare into behavioral healthcare systems, the same standards should be reasonable as in any other case of care coordination – anything missing is likely missing everywhere.
Further, as implied in some of the remarks above, the use case as defined appears to be primarily about integrating physical healthcare into behavioral health systems – it does not supply behavioral health specific data for use in physical healthcare settings. The behavioral health specific data is, generally speaking, confined to the Behavioral Health – Overarching use case. Our original assumption was that Coordinating Care would be the data needed to support behavioral health in other settings – i.e. integrating behavioral health data into the decision making and other aspects of other care.
We absolutely see benefit in the goal of integrating care and could see the usefulness of defining two sets of data pertinent to behavioral health – the data primarily needed only for behavioral health treatment and the behavioral health data useful to other practitioners treating other conditions to promote integration of care – but that is not what is presented here. Given that, we are having difficulty seeing usefulness in defining a separate Coordinating Care use case/data set.
Context for Dataset Organization
It would be helpful to have more context around why the dataset is organized the way it is. On the surface, it is not clear why certain data groups or data elements are in one use case over the other, and in many cases it makes more sense on the surface for a different decision to prevail. It is also not clear why some data groups were split between the use cases or why certain elements were placed under one use case versus the other.
This may be a side effect of not having enough context on the intent and decision making process used to define USCDI+ for Behavioral Health.
Splitting Data Classes
We strongly suggest that data classes not be split across use cases but classified as part of one or the other or, if appropriate for some reason we do not currently understand, both with identical content.
Organizing Data Across Data Classes
There are several instances where data that is clearly associated with a particular data class has been included in a separate data class either instead or addition to inclusion in the main data class for that type of data. We found this somewhat confusing.
For example, there is a separate and distinct Advance Directives data class but there is also a Proxy Decision Maker data element in the Care Team Members data class and a Treatment Intervention Preferences data element in the Goals and Preferences data class. The Advance Directive data class has exactly these two concepts – but presumably with the requirement of legal documentation backing up the authority. It might make sense to provide references to an existing healthcare proxy document (whether that’s a Durable Medical Power of Attorney or otherwise – see our comments on Advance Directives below) or to an existing Personal Advance Care Plan elsewhere, but it does not make sense to duplicate them or disregard the existence/expectation that the data be part of the other data classes which represent their primary purpose directly.
Similarly, there are specific data elements related to referrals under the Procedures data class and the Recovery Support Services data class but there is also a Referrals data class that doesn’t include all of the same concepts – including at least one concept (reason for referral) that would be widely useful. We will comment further on referrals below.
We recognize that, in some cases, this is happening because those duplicate data elements exist in those data classes in USCDI. However, there are many data classes in USCDI+ for Behavioral Health that carry over some but not all of the existing USCDI data elements in a class that exists in both data sets so this is not a sufficient reason for their inclusion in our view. Further, USCDI does not currently include those overarching data classes and thus must include them elsewhere if including them at all. Our expectation is that, should they be added to USCDI in a future version, the USCDI data would be reorganized to move the current data elements underneath the larger relevant category (this has been done before when new data classes were added to USCDI after some related data already existed under other data classes).
ONC Certification Plans
In order for widespread, consistent support of USCDI+ for Behavioral Health to happen on the provider side, ONC certification programs are likely necessary. Our Data Governance Collaborative urges ONC to consider certification programs against USCDI+ for Behavioral Health (and other USCDI+ data sets).
Links to USCDI Listings
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 Date/Time Element Names
The naming of data elements using dates and times is very inconsistent. Most but not all date-only data elements use the form “Foo Date” but some use “Date of Foo” and still others just “Date Foo”. Some elements only specify “Foo Time” without a corresponding “Foo Date” element (for example, Encounter Time. Most date and time elements specify “Foo Date/Time” while some use only date or only time and one uses its own very different format (Laboratory Results: Date and Timestamp).
As noted above, the choices made for some elements do not accurately reflect the data expected in the element in terms of the date, time, or both. For example, the Date Medication Administered data element is described as either a specific date/time or an interval of time when the medication was administered. At a minimum, this should be labeled as a Date/Time not Date. However, other intervals are captured by separate start and end data elements and we believe there should be three separate data elements: Medication Administered Date, Medication Administered Start Time, and Medication Administered End Time with instructions to omit the end time if the administration is a single, instantaneous event.
In general, we believe the goal should be clear, consistent naming that adequate reflects the intended data to be stored in that element. If this cannot be easily accomplished, it may mean the data element itself is not specific enough. Splitting current data elements into multiple elements that each reflect a very specific concept would be preferable to data elements that may contain a variety of different types of data.
Consistent Casing
We note that most data class and data element names capitalize the first letter of each word, but a few do not and some use non-standard rules for which words should be capitalized when not capitalizing everything (such as capitalizing articles like The but not prepositions or conjunctions). 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: Adverse Event, Referral). The naming rules should be consistently applied unless there is a substantive reason to do something different.
Response to Specific Questions
This section will list specific questions asked in the draft announcement and provide our responses to them
Would it be helpful to combine both use cases in the full USCDI+ for Behavioral Health list?
The current divide between the Comprehensive Care and Behavioral Health – Overarching use cases is not clear. As noted above under our general comments, the stated goal of the Comprehensive Care use case is not reflected well in its contents. If the goal is integrated care, then “behavioral health data for other practitioners” would make sense in addition to a “behavioral health data for behavioral health practitioners” but that’s not what’s presented.
We think combining the existing use cases as constituted into a single “general behavioral health” use case may make sense, but with significant weeding out of only the data that’s truly needed to capture behavioral health data. Leveraging USCDI proper for non-behavioral health data that might be useful for behavioral health practitioners to see should be the general practice. Any additional needs in that area could be added to USCDI+ for Behavioral Health if deemed important, but likely should also be accompanied by an ONDEC entry requesting their addition to USCDI proper – physical health data that a behavioral health practitioner needs to see about a patient in the course of their treatment is not likely to be specific to behavioral health practitioners and likely should be considered for general inclusion in USCDI.
What other behavioral health use cases should we consider?
Some additional clarity on the idea behind having separate use cases rather than just a single behavioral health data set would be helpful to understand what use cases might make sense. Having said that, there might be benefits from defining subsets related to the following:
- General behavioral health care (we see the existing Behavioral Health – Overarching somewhat filling this role)
- Behavioral health data for non-behavioral health practitioners (for integration of care; discussed above)
- Outpatient care (perhaps instead of the general category above if used in conjunction with an inpatient-specific data set)
- Inpatient care
- Substance Use/Addiction treatment
- Court Ordered services (this may be useful to capture specific information about mandated services)
- Group services (this may be useful to capture specifics of group services, but may require careful consideration of consent requirements for data involving multiple patients)
What other guidance about appropriate vocabulary criteria or references to information exchange specifications (e.g., HL7) would help map the data elements currently used in your environment to these USCDI+ BH data elements?
In general, it would be helpful to assign specific code sets, value sets, or other vocabulary constraints to more of the data elements in USCDI+ for Behavioral Health. We realize this took time with USCDI itself, and perhaps there needs to be a similar growing process for this dataset, but having clear, consistent expectations about the type of data expected in as many data elements as possible would be beneficial.
Some data elements on certain topics can be sensitive (for example: questions about domestic violence, gender identity, sexual orientation, sexual history, use of medication-assisted treatment for opioid use disorder, etc.). What guidance should be considered when using these types of data elements?
We note that some of this is already out of the barn door because many of these elements are included in USCDI v3+ which is already in regulations as mandated exchanges, but MHDC and our Data Governance Collaborative feel strongly that patient consent should be explicitly required for many of these more sensitive data elements.
Individual comfort level with sharing certain very private/very sensitive data may vary from practitioner to practitioner. This is particularly true for things like sexual orientation and gender identity where unapproved sharing of information is considered a form of outing the patient by some patients. Automatic sharing of such information – although already mandated via its inclusion in USCDI v3 – could cause certain patients to lose trust in their medical team or otherwise impede their ability/comfort in getting care. Similarly, in the current environment, some individuals might wish to keep their religion quiet or may not wish to advertise their racial identity if it is not visually obvious.
To provide additional examples, someone who is in recovery and has been sober or drug free for a considerable length of time has a justified fear of their history interfering with potential employment, social activities, and other normal activities and may be particularly sensitive about how that information is shared. Further, they may wish to avoid wasting time discussing it with practitioners treating them for unrelated conditions during limited appointment windows or just be tired of having to address it in every single medical encounter they have.
At the same time, there are legitimate times when folks would need to know sensitive and private information. If the only options are to share with no one or share with everyone then we would argue for share with no one and having each practitioner ask when relevant, but we would favor development of a consent system that gives patients the ability to control how and with whom such data is shared at a granular level.
Response to Specific Data Classes and Data Elements and Request for Missing Elements
This section will include comments on specific data classes and data elements in the proposal and comment on potentially missing data.
Advance Directives – Personal Advance Care Plan
We note the type of advance directive documents available to patients vary greatly from jurisdiction to jurisdiction. We believe having this general category to accommodate a variety of options makes sense, but urge addition of a note that not all documents are valid everywhere. For example, living wills are common documents in many locations but are not legally binding, official documents here in Massachusetts. Requirements built around personal advance care plan data should account for these variations. We also suggest capturing whether/where a document is legally binding as part of the data class (see below).
Advance Directives – Durable Medical Power of Attorney
Again, the type of advance directive documents available to patients vary greatly from jurisdiction to jurisdiction. Durable Medical Power of Attorney documents are not legally binding in every jurisdiction, but most jurisdictions do have some type of “proxy decision maker” designation that can be made in some type of legally binding form. For example, here in Massachusetts Durable Medical Power of Attorney is not a legally binding designation but Healthcare Proxy is.
We propose changing the name of this data element to Proxy Decision Maker Documentation (or Document) and noting this could be a Durable Medical Power of Attorney, a Healthcare Proxy document, or any other similar document filling the same niche in a relevant jurisdiction with underlying requirements able to accommodate different specific document types filling this role.
Advance Directives – Legally Binding
Again, the type of advance directive documents available to patients vary greatly from jurisdiction to jurisdiction. A document may be legally binding in New York but not Massachusetts or in New Jersey but not Pennsylvania but individuals may get care across those jurisdictional lines.
Having some indication of where a particular personal advance care planning document is valid seems an essential component of capturing advance directives data.
We know that populating this element may take some effort. Perhaps there needs to be some generally accessible list of which documents are valid in which jurisdictions that can be automatically applied when instances of those types of documents are included in the data.
Advance Directives - usage 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. We 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.
Adverse Events Related Event
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.
Care Team Members – Pharmacy
We propose the inclusion of preferred pharmacy as a care team member.
In keeping with our comments throughout this document, we also intend to suggest its inclusion in USCDI proper via the ONDEC system if it is not already present in the system.
Encounter Information – Level of Care – Behavioral Health
This seems like a general concept that should just be Level of Care and is applicable well beyond behavioral health.
Family Health History and Consent
There are 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.
Health Insurance Information data
We propose inclusion of the following additional data elements:
- Dependent Code
- Plan Name
- Plan Category (HMO, PPO, MA, Medicare FFS, etc)
- Initial Coverage Effective Date
- Plan Rollover Date
In keeping with our comments throughout this document, we also intend to suggest their inclusion in USCDI proper via the ONDEC system if they are not already present in the system.
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. Also, please refer to our note above regarding date and time naming to consider if these are the best names for these data elements.
Medications data
We propose the inclusion of the following additional data elements about medication a patient is taking:
- Pharmacist Filled
- Pharmacy Filled
In keeping with our comments throughout this document, we also intend to suggest their inclusion in USCDI proper via the ONDEC system if they are not already present in the system.
Patient Demographics vs Patient Demographics/Information
We urge consistent naming between USCDI and USCDI+ for Behavioral Health. USCDI uses Patient Demographics/Information as the name of its data class, USCDI+ for Behavioral Health should do the same.
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
In keeping with our comments throughout this document, we also intend to suggest their inclusion in USCDI proper via the ONDEC system if they are not already present in the system.
Vital Signs data
Our Data Governance Collaborative participants felt like the vital signs covered by the USCDI+ for Behavioral Health made sense but noted that they need the following additional information about each vital sign:
- Date
- Time
- Taken By
Work Information – Farmworker Status
Instead of specifically collecting the farmworker status of a patient, we recommend collecting the employment category data for all patients.