Known Bugs/issues

827 views
Skip to first unread message

Ivana Ng

unread,
Aug 29, 2017, 11:38:24 AM8/29/17
to qpp-...@googlegroups.com
We'll be using this thread to track known bugs and their status once resolved. 

Up-to-date as of: March 27, 2018

Known Bugs:

  1. Public sandbox does not respect the "ACI Reweighting Status" mapping in the Provider Profile Stub
Notes:
  1. As a reminder, the API requires case sensitivity which follows standard JSON protocols, such that integrators can expect that "foo" will be treated differently than "FOO". The API also ignores fields that are extraneous in a submission. It essentially accepts a submission with extraneous fields, does not throw an error, and ignores what it does not expect. When a field does not follow the case sensitivity for “optional” fields, which are marked as such in the developer documentation, the API views this as an extraneous field.

    For example, if you send a request to POST / PUT / PATCH /measurement-sets that contains all required fields -- but also contains fields that are not valid, then the API will return a successful 2xx status code, with a response payload that only shows the fields that it has recognized as valid. If you send a request to POST /measurement-sets with the field name 'PerformanceNotMet', the API will ignore that input, because it is not 'performanceNotMet' (lower-case 'p'). Similarly, if you send a request with the field name 'vendorName', the API will ignore that input because it is not a valid field.

    We recommend that when you submit requests to POST / PUT / PATCH /measurement-sets, review the response payload to ensure that the API ingested your request as expected.

Fixed Bugs:

  1. GET /submissions/{id}/score returns a scoring object without ACI measurements if the submission object contains some ACI measurements but doesn't meet minimum reporting requirements:

    { 
    "name": "aci", 
    "title": "ACI component of final score", 
    "detail": "No measurement set to score.", 
    "value": 0, 
    "original": {} 

    }

    Environments impacted:  https://qpp-submissions-sandbox.navapbc.com, https://qpp.cms.gov/api/submissions

  2. XML requests to POST /measurement-sets that contain <measurementSet> tags are malformed, and should return a 400 error. Instead, these types of malformed requests return 201 status code and creates an empty measurement-set (i.e. a measurement-set object with no measurements).
  3. performanceRate for registrySinglePerformanceRate in XML accepting integers, but should accept float number - XML ONLY
  4. If performanceMet + performanceNotMet > eligiblePopulation, the API returns a 500 error.
  5. JSON and XML sample response payloads in Swagger for the POST /submissions endpoint throws 422 error
    • The Bug: Both the XML and JSON sample response payloads in Swagger for the POST /submissions endpoint (https://qpp-submissions-sandbox.navapbc.com/#!/Submissions/createSubmission) returns a 422 error for a number of reasons:
      • The sample payload includes 2 measurement-sets, one of ACI data and one of quality data; however, in both measurement sets, category is specified as 'ia'
      • The API now validates that the submissionMethod specified for a measure is valid, and the sample payload specifies that the submissionMethod for each measurement-set is 'cmsWebInterface', which is not valid for some of the measures in each measurement set.
    • Environments impacted: https://qpp-submissions-sandbox.navapbc.com

  6. `/score-preview` endpoint is defective
  7. 0 / 0 proportion measurement is treated incorrectly in XML requests (but works correctly in JSON requests)
  8. Stratum name validation isn't occurring for multi-performance rate measures
    • The Bug: When submitting data with multiple strata for a given measure, the API currently does not properly validate the names of the "stratum" properties when the data is submitted via the "/submissions" and "/measurement-sets" endpoints. (though the validation does work properly when submitting via the "/measurements" endpoint). Therefore, any string value will be accepted there, even if it's not a valid strata name listed in the QPP Measures Data repository for the given measure).
    • The Expected Behavior: The API should return an error if you attempt to submit data for a multi-performance rate using "stratum" names that don't exist for that measures.
    • Environments impacted: https://qpp-submissions-sandbox.navapbc.com, https://qpp.cms.gov/api/submissions 

  9. Benchmarks for DM-Composite are not showing up when querying the /benchmarks endpoint
    • The Bug: Sending a request to public/benchmarks?measureId=dmComposite&submissionMethod=cmsWebInterface&performanceYear=2017 should return the benchmarks listed here. Instead, it returns:
      {
        "data": {
          "startIndex": 0,
          "itemsPerPage": 10,
          "benchmarks": [
            {
              "benchmarkYear": 2017,
              "performanceYear": 2017,
              "deciles": null,
              "status": "currentInsufficientData",
              "submissionMethod": "cmsWebInterface",
              "measureId": "DM_COMPOSITE"
            }
          ]
        }
      }

    • Environments impacted: https://qpp-submissions-sandbox.navapbc.com, https://qpp.cms.gov/api/submissions

  10. API doesn't validate that performanceStart is before performanceEnd
    • The Bug: It is possible to specify a performanceStart date that occurs after the performanceEnd date. E.g. you can submit a measurement set with performanceStart: 2017-06-01 and performanceEnd: 2017-01-01 
    • The Expected Behavior: The API should return an error if the performanceStart date occurs after the performanceEnd date.
    • Environments impacted: https://qpp-submissions-sandbox.navapbc.com, https://qpp.cms.gov/api/submissions

  11. POST /submissions returns 422 error when a submission object already exists but there are no measurementSets in the database for that submission object
    • The Bug: POST /submissions returns the following error (with 422 status code) when a submission object for the specified TIN/NPI/performanceYear/entityType/entityId already exists but there are no measurementSets in the database for that submission object:
      { "error": {
             "type": "ValidationError",
             "message": "Cannot read property 'map' of undefined"
             }
      }
    • Workaround: POST to the /measurement-sets endpoint. Note that the /measurement-sets endpoint requires you to specify the submission that you want to link the measurement-set to - which you can do by specifying a submission object OR a submissionId. For more information, check out the interactive documentation here: https://qpp-submissions-sandbox.navapbc.com/#!/MeasurementSets/createMeasurementSet
    • Environments impacted: https://qpp-submissions-sandbox.navapbc.com, https://qpp.cms.gov/api/submissions

  12. XML sample response payload in Swagger for the POST /submissions endpoint throws error
    • The Bug: The XML sample response payload in Swagger for the POST /submissions endpoint (https://qpp-submissions-sandbox.navapbc.com/#!/Submissions/createSubmission) returns this error:
    • <?xml version="1.0"?>
      <error>
      <type>ValidationError</type>
      <message>invalid submission object</message>
      <details>field 'measurements' in Submission.measurementSets is invalid: measurements[0] with measureId of 391 does not support measure set allergyImmunology, measurements[1] with measureId of 093 does not support measure set allergyImmunology</details>
      </error>
    • Environments impacted: https://qpp-submissions-sandbox.navapbc.com

  13. 0 / 0 single/multi-performance rate is treated incorrectly in XML requests (but works correctly in JSON requests)
    • The Bug: When submitting data for a single-performance rate or multi-performance rate measure with performanceMet == 0 in XML, the API calculates performanceRate as NULL and returns an error to the user.
    • The Expected Behavior: The API should calculate performanceRate as 0, and process the request successfully.
    • Environments impacted: https://qpp-submissions-sandbox.navapbc.com, https://qpp.cms.gov/api/submissions

  14. Values for strata that contain the character "<" is not recognized by the APIs when the request is in QPP XML format.
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages