United States Core Data for Interoperability (USCDI)

CAPComments_USCDI.02

This field is for general comments on the USCDI. To submit new USCDI data classes and/or data elements, please use the USCDI ONDEC system: https://healthit.gov/ONDEC

CAPComments_USCDI.02_CDC-NPCR_vFNL_0.pdf

Comments re: USCDI v2 DRAFT

Summit Healthcare Association submits its comments to the proposed USCDI v2:

• Under the data class “Encounter Information,” data element “Encounter Type” – how does one indicate observation status?  It does not appear to fall under any listed SNOMED encounter type.
• Under the data class “Problems,” data element “Date of Resolution” – This may be problematic for routine, acute conditions such as the common cold or flu, for which  patient is seen for treatment, but is not seen follow up.  Therefore, in this instance, how would one determine the date of resolution?

Redox Engine Comments on Draft USCDI v2

Redox is a platform for healthcare applications to integrate to healthcare organizations regardless of EHR, as well as nationwide networks like Carequality, HIEs, and state registries. Our interest in USCDI is based on being well-positioned to see existing gaps for the most common workflows across this broad variety of stakeholders.

General comments on updates

We feel the proposed changes are appropriate but decidedly conservative and iterative. The change represents minor updates to two data classes (Care Team Members and Problems) and two net new data classes (Encounters and Imaging)  

• For the updates to existing classes, we feel these should already be implicit when implemented. For instance, Problems are represented as Conditions in FHIR, which have the facet of OnsetDate already, so these updates in USCDI v2 are just prescriptive requirements to guide imprecise or careless vendors.  
• In regards to the creation of Encounters class, we would expect to see this data class extended to properly encompass a patient’s outpatient appointments. With the current data class and element definitions, we do not feel that vendors will necessarily expose the Appointment resource or sufficient detail around scheduled encounters, such as scheduled provider or visit type (which may differ/be more granular than encounter type). Giving patients access and visibility into their appointment, both historic and future, adds tremendous power to patient facing applications in helping them understand and manage those administrative details (and benefits healthcare organizations in perhaps reducing no-show rates).
• In regards to the creation of Diagnostic Imaging class, we support and endorse this addition. We would like to see the further addition of the image itself. Although we recognize the difficulty of expanding scope to data included in the PACS system of the healthcare organization, the impact for patients will be tremendous. Allowing portability of radiology and other imaging will drastically change the current CD/DVD driven workflows and ease transitions of care between organizations. We also support exposing all clinical images/files (not just diagnostic) stored to the patient chart.

Data elements already available commonly and standardly in EHRs

Several data classes in Level 2 that are not in USCDI V2 such as Social History or Orders are made available standardly to patients and other providers today (and for several years) via the VDT provisions of Meaningful Use and CDA exchange via Carequality and Commonwell. There are also additional Level 2 elements that should be readily available in EHR systems such as Encounter Location. We believe that these would be low lift for healthcare providers and their vendors, but of value for the patient.

Data elements offering largest value to patients still missing

We strongly believe that to increase the value of USCDI to healthy but unengaged patients, core administrative data is among the most important to define and expose, such as the aforementioned Appointment information. Additionally, Insurance (defined in Level 2), Advanced Directives (Level 1), Referral (comment), additional patient demographics (multiple levels) and financial information are core to the patient experience and have the greatest potential to increase patient engagement in healthcare activities once exposed, aggregated and understood. We strongly believe that to increase the value of USCDI to the sickest, most chronic patients, specialty-specific data is also among the most important to define and expose, such as the Ophthalmic Data (Level 2), pregnancy/obstetrics data (comment under Observation), and oncology data (comment under Observation)

Public Health considerations

Much of the commentary surrounds public health response and tracking trends at the population level but the updates do little to help in that regard. With the inclusion of the Level 2 proposed elements on Immunizations and Laboratory sections, the USCDI updates could make an impact in the ongoing efforts to fight the pandemic and expected improvements to public health infrastructure to come. Given this dataset will also be implemented for bulk data exchange, this may also be beneficial for CEHRT requirements, in that some could be replaced by relatively small USCDI expansion (Syndromic surveillance, vaccine registries, etc.)

UCSF's Center for Digital Health Innovation on USCDI v2

The University of California, San Francisco’s Center for Digital Health Innovation submitted the attached comments on new data classes and elements for version 2 of the U.S. Core Data for Interoperability.  These comments were submitted October 23, 2020.  Now that ONC has published its draft of USCDI v2 for public comment, UCSF's CDHI may submit additional comments as well. We appreciate the considerable work that ONC has devoted to the Common Clinical Data Set (CCDS) and its next evolution, the U.S. Core Data for Interoperability version 1.  Version 1, however, was only a “modest expansion” of the Common Clinical Data Set.   As a health care provider, we urge ONC to add numerous additional data elements now so that they, too, become available for better health care, for key national use cases such as COVID-19 and virtual care, and for the nationwide learning health system we need.  According to ONC, technical specifications are already available for 46 of 50 data classes ONC listed for candidate and emerging status, and all 50 are “critical to achieving nationwide interoperability.” To illustrate the importance of adding the missing data elements now, we tested them against two COVID-19 use cases and asked which missing structured data elements are necessary or important now for health care in the midst of the COVID-19 pandemic.  Not surprisingly, most were necessary or important. If you or your staff have any thoughts or questions about these comments, please feel free to contact me at Mark.Savage@ucsf.edu. Yours truly, Mark Savage

UCSF CDHI to ONC on USCDI v2 (10-22-2020).pdf

Kaiser Permanente Comments on USCDI Version 2

Overall Comments -- Definitions: ONC should more clearly define data elements in the USCDI master document (both USCDI v1 and USCDI v2). ONC does not provide any ‘data dictionary’ reference for data elements.  Also, having no applicable standard reduces the value of the USCDI and creates confusion in how health care organizations interpret each data element.  Thus, we strongly recommend that ONC develop and publish specific, detailed definitions for every data element in the USCDI.  We also recommend that ONC identify applicable standards for elements currently lacking them.  As an example, when implementing USDCI v1, we had trouble interpreting what qualifies as a progress note, what’s required for provenance, and other definitional issues. The USCDI seems to assume there is a common set of terminology used across the industry that is universally understood.  As we discovered, that is not the case.  Being that USCDI is now intended for the masses, it would be great if it could be made easier to use by including definitions.  Organizations shouldn’t have to depend on health care coding experts to understand what is required. -- Coordination: We are concerned about the relationship among the ONC ISA, the USCDI, and requirements for eHI (electronic health information) into the future. According to final regulations, the USCDI will be superseded by eHI starting October 2022, when it is likely ONC would have issued a Version 3 of the USCDI.  ONC should address the relationship between these newer versions and the eHI. -- ONDEC submission system improvements and USCDI Portal:  There is valuable information included in the new proposed data classes and data elements (a use case description, estimated number of stakeholders using data element, health care aims, applicable standards, additional specifications). However, all that information seems to get lost when the data element becomes part of the formal USCDI Version.  Additionally, it is worth noting that the URL links of several data classes and data elements in the USCDI portal under “V2” and “Level 2” sections do not work. -- Submission Evaluation Criteria: ONC and HITAC considered four main criteria to evaluate each of the data classes/data elements submitted for consideration: 1) Maturity of Current Standards; 2) Maturity of Current Use; 3) Maturity of Current Exchange; and 4) Use Cases (# Stakeholders Impacted). The threshold for classifying data classes and data elements as Level 1 or Level 2 is too low. For example, limited production in 1 or 2 systems, or exchange between 2 or 3 organizations with different EHRs will get a data class/element to become classified as Level 1; and in production in more than 2 systems, or exchange between 4 or more organizations with different EHRs would get a data class/element to be classified as Level 2.  Those thresholds should be much higher, particularly for Level 2 elements (as a suggestion, consider for Level 1, Data Classes/Data Elements with limited production in 9 or 10 systems, or exchange between at least 10 organizations with different EHRs; and for Level 2, Data Classes/Data Elements in production in more than 10 systems, or exchange between 11 or more organizations with different EHRs).  We also recommend ONC consider the value of data elements for the end users, including consumers, primarily, but also providers, public health, health plans and others). -- Recommendations regarding Version 3 submission cycle: We are concerned that the evolution of the USCDI is moving too fast to allow appropriate stakeholder consideration, transition, implementation, and evaluation.  We are also concerned with the possible regulatory adoption of a future version of USCDI and the jump from Version 1 to a Version 3 or Version 4 (as an example) will be quite significant, costly, and unduly burdensome.  Lastly, we are concerned that the new Diagnostic Imaging and Encounter Information data classes will be complex to enable the functionality needed, time consuming and costly. Question 1 – Was the extent and scope of the proposed change appropriate?  Changes to USCDI v2 -- New “Diagnostic Imaging” Class and Data Elements:  The data class seems to be appropriate, as it is available from systems.  With respect to the data elements, the difference between Diagnostic Imaging Narrative and Diagnostic Imaging Report is not clear. Thus, we recommend ONC clarify the difference between the two. If there is no difference, ONC should combine these into a single element. -- New “Encounter Information” Class and Data Elements: We have no concerns about adding this new class; however, we are concerned about the Encounter Type element, as the proposal includes multiple different types of applicable code standards (SNOMED, ICD-10, HL7 Value Set, Discharge Disposition code set, VSAC code set).  Mapping encounter types across organizations will be challenging. For Encounter Time, it will be important to clarify if this will be the start time, length of appointment, scheduled time versus actual time, or scheduled length versus actual length. It will also be important to clarify what does Encounter time look like for Inpatient, ED and Ambulatory. -- New data elements under “Care Team Member(s)” data class: Under “Provider Identifier” there are two separate and unrelated applicable standards referenced: 1) NPI and 2) Provider Taxonomy.  These two codes refer to two distinct characteristics of providers and should not be combined within a single element.  Also, we want to point out that displaying the correct taxonomy code of a provider will require complex logic, given that many providers have multiple taxonomy codes, due to multiple specialty services they provide. -- New data elements under “Problems” data class: As we noted above in our overall comments, the data element, “Problem,” does not have a definition that covers both past and current problems.  In many instances, organizations distinguish these; the “Current Problem” list is readily available as having more immediate clinical relevance. It will be important to add a definition to the data element “Problem” and clarify whether it includes past and present conditions. Level 2 Data Classes and Data Elements -- We are concerned with the significant expansion of data classes and data elements in the Level 2 category, described as “data classes/elements that demonstrate extensive use in systems and exchange between systems, use cases that show significant value to current and potential users, and would clearly improve nationwide interoperability.”  While some of the classes and elements may be valuable in specific cases, they currently have limited collection, use, and exchange in existing systems (e.g., travel information, social history, social determinants of health, health insurance). -- We reiterate our concern that all classes and elements should have clear definitions. Level 1 and Comment Sections No comments at this time. Question 2 – Were the right data classes and elements added in the proposed new version?  -- The two new classes, and the reclassification of certain clinical notes into other classes are appropriate Question 3 – Are any of the proposed additional data classes, elements, or standards problematic? -- Our primary concerns are that some elements lack clear definition, and there is no mapping between the applicable standard and the documentation in the electronic system of the organization.  For example, organizations have noted difficulties interpreting what qualifies as a clinical note (a progress note, for example), what is required for provenance, etc. -- Diagnostic Imaging and Encounter Information Data classes need detailed information for an Organization to implement the technical solution. Current information and standard provided is not enough for achieving a successful implementation. Question 4 – Are there additional data classes or elements that have been categorized by ONC as Level 2 or even Level 1 that you believe should be added to USCDI V2?  None at this time.  

USCDI Draft v2: Comments from Patient & Carepartner Perspective

General Overview

• Based on the comments and feedback received to date on this entire body of work, what is the approximate percentage of responses by stakeholder category? For example, how much feedback and guidance has been received from vendors, payors, representatives from the government, clinicians, and actual patients, carepartners, and respective patient, non-profit advocacy groups? A simple pie chart would be helpful in defining this with more transparency. The suggestion, prioritization, and implementation of new data classes and data elements will be a direct consequence of the representation of stakeholders. If patients, carepartners, and advocates have not been well represented, the USCDI expansion will not be inclusive of diverse voices nor represent the unmet needs of patients and their families. 
• When presenting USCDI draft versions for feedback from the public, v2 or future versions moving forward, it would be helpful, on pages 5-14, to see specific examples of how each respective data class and data element is represented using synthetic data.
• Disability status or need for accessibility support is not captured. Over 61 million (roughly 1 in 4) adults in the United States live with a disability. https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html#:~:text=61%20million%20adults%20in%20the,is%20highest%20in%20the%20South. If we are going to improve the lives and care of individuals living with disabilities, we must prioritize capturing and sharing this data accordingly.
• Page 4:  Does not list Data Class "Goals" and Data Element "Patient Goals"; page 8 does.
• Imaging and pathology are recognized as data elements. Where are surgical/operative reports/notes reflected?
• It is gravely concerning to see that critical end-of-life care information, such as Advance Directives, Do Not Resuscitate (DNR) orders, Physician Orders for Life-Sustaining Treatment (POLST), are not included in the USCDI draft v2. These are essential to be documented. Throughout the COVID-19 pandemic, we witnessed reports of potential needs to ration care due to surging numbers of COVID-19 positive patients. Many patients with life-altering, life-limiting conditions were strongly encouraged to have their end-of-life wishes documented as a precaution. Pandemic and beyond, it is unethical that end-of-life care information that has the power to actionably communicate an individual's wishes at their end of life not only does not appear in draft v2 but also is only prioritized at level 1. By not including end-of-life care information, such as Advance Directives, DNRs, and POLST, the draft document sends the message that USCDI is prioritizing vendor and billing priorities rather than data elements and data classes that have universal applicability to every human being and doing right by the patient.
• The element "Diagnostic Imaging Narrative" as a separate entity from "Diagnostic Imaging Report" is unclear and confusing. Diagnostic Imaging Reports often have "Impressions," "Findings," "Summary," or "Observations" noted and should be referred to as such for consistency when discussed in the USCDI work. Impressions, Findings, Summaries, and Observations should not be codified to enable extraction from an imaging report without other essential elements of the respective report as this is not only counterproductive but can cause harm to inpatient care. Elements
• There are 61 data elements in total listed in USCDI draft v2; 25 data elements (41%)  have no applicable standards listed. Some of these elements are self-explanatory and straightforward, while others have more room for interpretation and are vague, such as Patient's Goals, Date of Resolution, Care Team Members. Applicable, available standards should be assigned, and any remaining vagueness directly addressed so as to avoid amplifying confusion on implementation. The following do not have standards listed as of yet: 
  1. Assessment and Plan of Treatment
  2. Care Team Members
  3. Provider Name
  4. Provider Identifier
  5. Encounter Type
  6. Encounter Time
  7. Patient's Goals
  8. Health Concerns
  9. Values/Results
  10. Laboratory Report Narrative
  11. Pathology Report Narrative
  12. First Name
  13. Last Name
  14. Previous Name
  15. Middle Name
  16. Suffix
  17. Date of Birth
  18. Current Address
  19. Previous Address
  20. Phone Number Type
  21. Email Address
  22. Date of Diagnosis
  23. Date of Resolution
  24. Author Time Stamp
  25. Author Organization

Specific Feedback Allergies & Intolerance: Many people are allergic to things that are not a medication that they can encounter in a clinical setting, such as latex. This won't have a medication name or drug class. Assessment & Plan of Treatment: Is this only capturing the clinical treatment plan? Is this capturing social determinants of health (SDoH)? If a health professional is not aware of various prominent barriers a patient is living with, the clinical treatment plan that is documented will fully fail the patient. For example, prescribing an expensive infusion treatment that is not covered by a patient's insurance company may cause significant harm to the patient as treatment is not affordable or accessible. If this is not understood before the patient leaves the clinic, a patient may learn about the treatment being not covered and simply not come back to the clinic and give up. This leads to disease progression and exacerbation of symptoms with the potential for eventually needing emergency room care. By understanding what SDoH factors may negatively impact a clinical treatment plan, adjustments may be made proactively as well as connecting the patient to community support and financial assistance resources. Recommend building a framework to capture elements of social determinants of health (SDoH) for future draft versions for prioritization from level 2. Care Team Members: Is this only capturing clinical care team members? To be progressive, we must capture and include a patient's primary carepartner, advocate, executor of their estate, personal representative, etc. as the majority of care, especially in the chronic, life-altering, life-limiting settings, happens outside of the four walls of medicine requiring the support of non-clinical care team members. The Care Team Members Data Class and Data Element need more detail in the USCDI draft v2 description on page 6 to clarify ambiguity. Clinical Notes: Operative notes are critical to patient continuity of care and patient safety. It is important to emphasize that operative notes are one of the only pieces of information that alert patients and their carepartners to the fact that tissue and biological samples may have been harvested during surgery and have been submitted for pathology and/or laboratory analysis. Operative notes need to be included under Clinical Notes in draft v2. Diagnostic Imaging Narrative: An Imaging Narrative should not be available to be extracted without all the accompanying essential components of the imaging report. The concept of an Imaging Narrative is also unclear. Data Elements should be reflective of the wording used in the real world. An Imaging Narrative is typically referred to as the Findings/Impressions/Summary section of the imaging report and should be referred to as such for consistency. Immunizations: Essential public health safety, reporting, and information exchange throughout the pandemic & for post-pandemic public health monitoring.

• Date- Include in draft v2 to monitor COVID19 vaccination doses and potential boosters
• Type- Consider adding vaccine type (brand/manufacturer) to draft v2 as COVID-19 vaccines requiring at least two doses currently can not be mixed and matched until clinical trial data proves heterologous prime-boost is safe and effective.

Laboratory:

• Laboratory Report Narrative- It is unclear what exactly a laboratory narrative is. A Laboratory Narrative should not be available to be extracted without all the accompanying essential components of the laboratory report.
• Pathology Report Narrative- A Pathology Report Narrative should not be available to be extracted without all the accompanying essential components, such as the microscopic analysis and diagnosis, of the laboratory report.
• Units of Measure- Laboratory values/results must have units of measure included. Draft v2 should include units of measure if Values/Results do not include them.
• Autopsy Report- This is an essential piece of reporting to bring peace and closure to families grieving the loss of loved ones, as well as essential information for public health and scientific understanding of the COVID-19 pandemic. Draft v2 should include information from autopsy reports

Medications:

• Dose- This is critical for patient safety, prevention of medication errors, and continuity of care purposes. Draft v2 should include medication dose; add to USCDI v2
• Prescribed By- Medications often have the most variation and inconsistency in documentation as prescriptions are frequently discontinued for numerous reasons. Patients may have 20+ medications in their medication history but may only be actively currently taking 2 or 3. There is currently no way to flag a medication as discontinued. Patients are frequently told by their care team that if they did not prescribe the medication, they could not delete or remove it from their medication list in the EHR. Medication corrections are a frequent reason for patients wanting to correct their medical records. Inaccurate medication lists upon patient intake, at patient discharge, and in pre-admission for surgery can be tedious/impossible for staff and patients to review and may endanger patient safety. Draft v2 should include information on who prescribed a medication; add to USCDI v2.
• Status- This is critical for patient safety, prevention of medication errors, and a frequent request for medical record addendums that would be of great importance to address proactively. Draft v2 should include information on whether a medication is active or discontinued. Add to USCDI v2

Problems: Date of Resolution is not broadly applicable to people living with chronic illness, life-altering, life-limiting conditions, disability, rare disease, terminal illness, and active death care and end-of-life. This is a vague data element that can bring great harm to patients should it be documented incorrectly or incompletely. The TF must be conscious of the potentially severe negative impact on patients' lives with respect to matters such as disability benefits should the data element be captured incorrectly or not comprehensively. Recommend removing from USCDI draft v2. Procedures: Do surgical/operative reports/notes currently fall under this category? Smoking Status: Tobacco Use more accurately describes the spectrum of individual behavior being captured in a less stigmatizing manner. TF should consider revising the data class and element name to "Tobacco Use". Other:

• End of Life Care- End of Life Care is often intentionally distinct from routine care and should be reflected as such. Recommend adding "End of Life Care" as a distinct new data class.
• Advance Directive- Pandemic and beyond, it is unethical that end-of-life care information that has the power to actionably communicate an individual's wishes at their end of life not only does not appear in draft v2 but also is only prioritized at level 1. By not including end-of-life care information, such as Advance Directives, DNRs, and POLST, the draft document sends the message that USCDI is prioritizing vendor and billing priorities rather than data elements and data classes that have universal applicability to every human being and doing right by the patient. Recommend moving from L1 to draft v2.
• Blood Type- Blood type is an essential laboratory test that is often repetitively ordered throughout women's lives due to pregnancy and the lives of patients, such as those in need of a transfusion. It would be beneficial to capture this and reduce the need for repeat testing.
• Coverage Type- Due to the pandemic, millions of individuals have lost health coverage. In order to connect people to public resources as quickly as possible to ensure people have affordable, meaningful access to health care, information on Health Insurance Coverage Type must be prioritized.

             

CMS Comment on USCDI draft V2

On behalf of The Centers for Medicare and Medicaid Services (CMS) and The Center for Clinical Standards and Quality (CCSQ) we submit comment on the USCDI draft version 2, attached.   CMS supports a broader vision for the USCDI, where the USCDI standard serves as the central mechanism for exposing usable, standardized interoperable data for multiple use cases, including quality measurement. We are committed to working collaboratively with ONC to ensure the USCDI meets stakeholder needs. We specifically urge ONC to add additional data elements to USCDI version 2 that are critical for data sharing and addressing emerging public health needs as well as health equity, highlighted in the attached comment response.

USCDI Draft Version 2 CMS Public Comment Responsev1.pdf

This field is for general…

I've now review draft version two of the USCDI document you sent and thank you for the opportunity. My overall my main recommendation is that somewhere there needs to be a very clear indication of functional assessment. Function in terms of the ability to do ADLs and  IADLs  and what we, with IHI refer to as the 4M assessment of  age friendly health systems which includes “what matters mentation medication and  mobility. The opportunity to have interoperability is critical and this work is vital. I am always concerned when we focus on conditions instead of the capacity a person has within the context of conditions. Lots of people have heart failure and some are playing tennis while others are lying in bed. So functional assessment.     

I've now review draft…

I've now review draft version two of the USCDI document you sent and thank you for the opportunity. My overall my main recommendation is that somewhere there needs to be a very clear indication of functional assessment. Function in terms of the ability to do ADLs and  IADLs  and what we, with IHI refer to as the 4M assessment of  age friendly health systems which includes “what matters mentation medication and  mobility. The opportunity to have interoperability is critical and this work is vital. I am always concerned when we focus on conditions instead of the capacity a person has within the context of conditions. Lots of people have heart failure and some are playing tennis while others are lying in bed. So functional assessment.

Referral Data Class

The Referral Data Class is much more mature than this Comment level characterizes.  The Referral Note document type has been recommended for Certified EHR Technology along with CCD and Discharge Summary since Meaningful Use Stage 1.  Further more, the IHE 360X Profile has been demonstrating it's use of multiple years at HIMSS Show Case demonstrations and other ONC, IHE  and DirectTrust events.  This March at the IHE Connectathon three well known EHRs and one HIE solution vendor successfully tested/demonstrated their support of the 360X profile and they were generating Referral Note documents containing all the proposed data elements within:  

• Reason for referral
• Referral code
• Referral requestor

  Referral Coverage information in really "insurance information" typically categorized as "Payer Information"  in the C-CDA paradigm.  This data element faces challenges because to date there is not a national identification system to indicate what health plan is providing the coverage. Until this larger problem gets solved, representing coverage information will be challenging.