[CYPRESS-706] C1 Manual Test requires Data elements to be entered that are not supported by the EHR workflow. Created: 07/28/16  Updated: 05/07/18  Resolved: 09/29/17

Status: Closed
Project: CYPRESS Issue Tracker
Component/s: None

Type: Bug/Issue Priority: Minor
Reporter: Robin Holder (Inactive) Assignee: David Czulada
Resolution: Delivered Votes: 2
Labels: cypress, cypress_guidance

Attachments: Microsoft Word C1 Manual Entry – Synonymous Data Criteria Substitution_4_13_17.docx    
Issue Links:
Duplicate
is duplicated by CYPRESS-974 CMS 144 and 145 LVSD Moderate or Severe Closed
Relates
relates to CYPRESS-1022 for eCQMs the system does not need to... Closed
relates to CYPRESS-993 CMS147 Immunization Administered with... Closed
relates to CYPRESS-1075 CQM Medication Concerns (CMS156v5, CM... Closed
Previous Issue Type: Implementation Problem

 Description   

C1 Manual Test requires Data elements to be entered that are not supported by the EHR workflow. The Denominator specification lists 3 OR conditions for inclusion. The EHR supports 1 of them (marked as B in the spec below), but the Manual Entry test is looking for data elements to be entered for the other 2 conditions (marked as A and C below). Why would we be required to enter data that does not match the EHR workflow?

Denominator =
AND: Initial Population
AND: Union of:
A - "Diagnostic Study, Performed: Ejection Fraction (result < 40 %)"
B - "Diagnosis, Active: Moderate or Severe LVSD"
C - "Diagnosis, Active: Left Ventricular Systolic Dysfunction (severity: Moderate or Severe)"
starts before end of Occurrence A of $CADEncounters145



 Comments   
Comment by David Czulada [ 09/29/17 ]

Cypress 3.2 has been updated to give the test proctors to swap data criteria in a C1 Record Sample test. Test proctors have been given the following guidance on swapping criteria.

The electronic clinical quality measures (eCQMs) code evidence-based, clinical guidelines for use across healthcare setting and health IT systems. Because there is variability across the industry and care systems, it is sometimes necessary to allow systems to code certain kinds of clinical information in multiple ways. For example, a medication allergy can be described as a type of allergy or a type of diagnosis. Similarly, systems may allow the use of more than one vocabulary to describe the same information; the diagnosis of diabetes can be coded in SNOMED-CT or ICD-10-CM. Where there are two different ways of describing patient data that can satisfy the same criteria in a measure, we have called these synonymous data criteria.

Measure developers work hard to provide optionality where appropriate without making the measures overly complicated or allowing patients who are not equivalent to be included or excluded from the measure. Feedback from the community is helpful to determine where the measure should have more or less optionality.

In testing and certification, ONC seeks to ensure that the measure data can be captured, extracted, imported, calculated, filtered, and reported. Certification testing has many procedures that, in combination, can certify a measure’s performance from end to end. In regards to synonymous data criteria, there is a conflicting need: we want systems to be able to read and understand all the criteria in a measure; however, we do not expect systems to allow users to enter the same kind of data in multiple ways. Furthermore, we do not know which of multiple options any one system will make available to users, nor do we seek to mandate this. Therefore, we have identified an approach to allow the appropriate level of flexibility in regards to synonymous data criteria for (c)(1) 2015 Edition Certification testing.

For measures which contain multiple data criteria with the same meaning that satisfy a portion of a measure, systems need only demonstrate that users in (c)(1) manual testing can satisfy one of these criteria options. ATLs have the ability within Cypress to select which option the developer states they have available and may test through that one option. ATLs will only allow optionality where the alternate criteria are equivalent, however. For example, as above, “allergy: medication, aspirin” is equivalent to “diagnosis: medication allergy, aspirin”, but “medical reason: allergy to ACE inhibitor” is not equivalent to “medical reason: renal failure”.

Within the automated portion of Cypress testing for (c)(1), test cases will generally touch all of the possible data criteria in the measure even if they are synonymous. Systems are required to be able to read/store all these criteria but not to allow a user to enter all of these options. We believe this approach allows systems to have the appropriate level of flexibility to support robust testing but without encouraging systems to put onerous and potentially unsafe user data entry options into the interface.

-Dave Czulada

Comment by David Czulada [ 10/21/16 ]

Robin

The document is attached.

Comment by Robin Holder (Inactive) [ 10/20/16 ]

I would also like a copy of the guidance document so that I know what to expect from the proctor. Thanks - Robin Holder

Comment by Robin Holder (Inactive) [ 10/20/16 ]

Appreciate the assistance Samuel. Is that Guidance published? I was not able to find it attached to the case as mentioned by David on 8/08/16. Thanks - Robin

Comment by Samuel Sayer [ 10/20/16 ]

Robin,

We're reaching out to your proctor to check if they'll need to use the guidance. I will forward them a copy of the guidance to document to ensure they have it.

Comment by Robin Holder (Inactive) [ 10/19/16 ]

Our Certification event is Monday 10/24/2016. Our ATL is looking for guidance on how to handle the issue in this case when we do our C1 Manual Entry Test for CMS 145.

Comment by Alex Liu [ 08/09/16 ]

Dave -

We are running into a similar issue with synonymous Data Criteria for "Device, Order not done" within the QDMV $NoDeviceVTEProphylaxisMedicationReason for CMS-108, CMS-114, and CMS-190 for Manual Entry. We have reviewed and are on board with the CQI-approved DSTU comment that states that the supply should be wrapped in a negated act to represent "Device, Order not done." However, we have never seen an Errata actually published by HL7 for the standard HL7 QRDA Category I Release 3. Rather than developing to the released standard HL7 QRDA Category I Release 3.1, we have selected to supress documentation of "Device, Order not done" as to not violate the base CDA schema and since it is synonymous with "Device, Applied not done."

Please let us know if this guidance from ONC can be extended to "Device, Order not done" for manual entry.

Thanks,
Alex Liu

Comment by David Czulada [ 08/08/16 ]

Robin-

Thanks for the additional example. We spoke with ONC and we will be working on a substitution workflow in places where Data Criteria are synonymous. When the guidance is finalized I will attach it to this ticket.

Please feel free to continue adding examples where you've run into this.

-Dave Czulada

Comment by Robin Holder (Inactive) [ 08/08/16 ]

Sorry, forgot to note that the above comment is for CMS91

Comment by Robin Holder (Inactive) [ 08/08/16 ]

Here is another example.
Our workflow tracks all medications by RxNormCode. We use the Medication, Administered workflow in our EHR. We could create a workflow that would capture the SNOMEDCT for the Procedure, Performed criteria, but we do not understand why we would need to do that when we have a valid workflow for the measure.

OR: Union of:
"Medication, Administered: Thrombolytic (t-PA) Therapy"
"Procedure, Performed: Intravenous Thrombolytic (t-PA) Therapy"
<= 2 day(s) starts before start of "Occurrence A of Encounter, Performed: Emergency Department Visit"

Comment by David Czulada [ 07/28/16 ]

Robin-

Thanks for this information. We will discuss this with ONC and will get back to you with guidance.

-Dave Czulada

Comment by Robin Holder (Inactive) [ 07/28/16 ]

Hi David,

Specifically against your questions below:
1) We cannot Enter: Diagnosis, Active: Left Ventricular Systolic Dysfunction (severity: Moderate or Severe) — We use ‘Diagnosis, Active: Moderate or Severe LVSD’
3) We can enter the Ejection Fraction specific value, but we use a range in our workflow. < 40% or >= 40%. If the physician documents <40%, then a ‘Diagnosis, Active: Moderate or Severe LVSD’ is created.

#2) is not an issue we can enter as many different elements as we need on one patient.

Thanks - Robin

Comment by David Czulada [ 07/28/16 ]

Robin-

Is the problem one of the following:

1) The system cannot enter one of the conditions (i.e. cannot enter "Diagnosis, Active: Left Ventricular Systolic Dysfunction (severity: Moderate or Severe)")?
2) The system cannot enter all three (or two of the three) conditions in the same patient?
3) The system could enter all three, but it doesn't make sense from a workflow perspective?

The C1 Manual Test does not require that all of the elements be in a single patient. It is ok to include the information in multiple patients.

-Dave Czulada

Generated at Mon Sep 22 00:13:57 UTC 2025 using Jira 10.3.9#10030009-sha1:eff8913ed2270ee44ab422c3609af4c4f36536d0.