[CYPRESS-1194] Diagnosis modifiers not supported in RIS application Created: 08/29/17 Updated: 05/07/18 Resolved: 09/29/17 |
|
Status: | Closed |
Project: | CYPRESS Issue Tracker |
Component/s: | None |
Type: | Bug/Issue | Priority: | Moderate |
Reporter: | Rhonda Eckstein (Inactive) | Assignee: | David Czulada |
Resolution: | Answered | Votes: | 0 |
Labels: | CQM, QRDA-I, TestData, ValueSet |
Tracker Notification: |
Timothy Bennett (Inactive)
|
Previous Issue Type: | EP Value Sets Implementation Problem |
Description |
I’m an analyst for eRAD RIS, doing CEHRT testing. We found an issue while doing CQM testing in Cypress (manual) with the criteria requested for the test patient. Our RIS software does not support the one data element "Diagnosis: Unilateral Mastectomy, Unspecified Laterality (anatomical location site: Left)" as we do not have the functionality to add modifiers to a Diagnosis code. We can accomplish the same requirement by selecting the diagnosis code specific to the body part and laterality in a single field which is more applicable to radiology. We meet all the other data elements for the test. In our scope of practice, RIS users will always utilize the diagnosis codes specific to the body part/laterality and will not use diagnosis modifiers. Would you consider this single field that represents all required information specific to a radiology practice acceptable to pass this measure? Thank you for any guidance you can provide. |
Comments |
Comment by David Czulada [ 09/27/17 ] |
Rhonda This was a design limitation in Cypress 3.1.0. Cypress 3.2.0 has been updated to allow for ATLs to swap data criteria that can be used synonymously. The case you describe would be a valid substitution since the data elements are used synonymously in the eCQM. AND: Union of:
Even though Cypress 3.1.0 does not provide an automated way to verify swapped data criteria, you should be able to work with your ATL to verify the swapped data criteria in a manual fashion. If the ATL has any questions, please refer them to this ticket. The following guidance has been given to the ATLs regarding swapping data criteria in the C1 Record Sample tests. 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. Hope this helps |