[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: |
![]() |
||||||||||||||||||||||||
Issue Links: |
|
||||||||||||||||||||||||
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 = |
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, |
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. OR: Union of: |
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: #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)")? 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 |