send communication resource to EHR

[smalho01]

Describe your changes

Check the ETASU status at the dispense authorization endpoint, basic fill in for NCPDP messages using JSON for now (will change to NCPDP XML once we receive spec) and send a communication resource to the FHIR EHR server for the prescriber to see.

Issue ticket number and Jira link

REMS-856

Checklist before requesting a review

• I have performed a self-review of my code
• Ensure the target / base branch for any feature PR is set to dev not main (the only exception to this is releases from dev and hotfix branches)

Checklist for conducting a review

• Review the code changes and make sure they all make sense and are necessary.
• Pull the PR branch locally and test by running through workflow and making sure everything works as it is supposed to.

Workflow

Owner of the Pull Request will be responsible for merge after all requirements are met, including approval from at least one reviewer. Additional changes made after a review will dismiss any approvals and require re-review of the additional updates. Auto merging can be enabled below if additional changes are likely not to be needed. The bot will auto assign reviewers to your Pull Request for you.

In general, to fix this kind of issue you must ensure that user-controlled values used in Mongo/NoSQL queries are interpreted only as literal values, not as query objects or operators. This can be done either by (1) validating/coercing the input so that only expected primitive types (string/number) are allowed, or (2) using an equality operator such as $eq so that even if an object is supplied, it is treated as a literal rather than merged into the query selector.

The best minimal-change fix here is to restrict caseId to a primitive string and reject requests that do not supply a valid string ID. That keeps the existing semantics of “lookup this case by its ID” while preventing query-shaping attacks. Concretely, within handleRemsRequest in src/ncpdp/script.ts, after extracting caseId, add a type check typeof caseId !== 'string' (and optionally a simple sanity check like .trim().length === 0) and return a “denied” response if the value is not valid. Then use caseId as before in findOne. This keeps the control flow and responses consistent with the existing “no case ID” / “case not found” branches and requires no new imports or external libraries.

More specifically:

• In handleRemsRequest, after const caseId = ... and before logging “Extracted case ID”, insert a check ensuring caseId is a string (and not an object), returning a denied response (status 200, like the other validation error) if validation fails.
• Optionally normalize caseId (e.g., const normalizedCaseId = caseId.trim();) and use the normalized version in the query; but to minimize behavior changes we will only check type and emptiness.
• Leave the findOne({ case_number: caseId }) call intact so existing behavior is unchanged for valid string IDs.

No imports or additional methods are needed; all changes are within handleRemsRequest in src/ncpdp/script.ts.

In general, to fix NoSQL injection when building query objects from untrusted data, either (1) enforce that the values used in queries are primitives of the expected types (e.g., strings, dates) and not arbitrary objects, or (2) wrap them with an operator such as $eq so they are always interpreted as literals and not as part of the query structure. Input validation is usually preferable, because it also catches malformed requests earlier.

For this specific code, the safest, minimal-change approach is:

• Extract the relevant fields (patientFirstName, patientLastName, patientDOB, drugNdcCode) into local variables.
• Validate that each of these is of the expected primitive type (string) and not an object.
• If validation fails, respond with a 400 Bad Request and an appropriate error message (as XML, consistent with the rest of the handler) instead of querying the database.
• Pass only the validated primitive values into remsCaseCollection.findOne. Because we now ensure they are strings (or at least non-object primitives), the query object cannot contain malicious operators.

All changes are confined to src/ncpdp/script.ts within the handleRemsInitiation function, around lines 193–215 and just before the catch at line 273. No new imports are required; we can reuse the existing buildErrorResponse, logger, and res handling patterns.

Concretely:

• Modify the section that builds requestInfo and constructs the findOne query to first define patientFirstName, patientLastName, patientDOB, and drugNdcCode variables.
• Add a small validation block that checks typeof each field (and that it is present); on failure, logs and returns a 400 response with buildErrorResponse and content type application/xml.
• Use the validated variables (not direct property access on patient) in the findOne filter.

In general, untrusted values used in MongoDB queries should either be (a) wrapped in an operator like $eq so MongoDB always treats them as literal values, or (b) validated to ensure they are primitive types (e.g., string) and not objects containing query operators before being included in a query object.

For this code, the minimal, safe fix without changing functionality is to change the medicationCollection.findOne query (lines 227–229) to use the $eq operator for ndcCode. That keeps the same semantics (equality match on NDC code) but prevents a crafted object from being interpreted as a query operator. Concretely, we will modify the query in handleRemsInitiation from:

const medication = await medicationCollection.findOne({
  ndcCode: drugNdcCode
});

to:

const medication = await medicationCollection.findOne({
  ndcCode: { $eq: drugNdcCode }
});

This mirrors the "GOOD: using $eq operator" pattern in the background material. No additional imports or helper functions are required; the change is localized to the existing query in src/ncpdp/script.ts.

In general, to fix this type of issue in MongoDB-style queries, you must ensure that any user-controlled values embedded in a query filter are interpreted as literal values, not as query objects. This can be done by either (a) wrapping them with $eq so MongoDB treats them as equality comparisons on a literal, or (b) validating/coercing the values to the expected primitive types (e.g., strings, dates) and rejecting or sanitizing objects.

For this specific case, the simplest change that preserves existing functionality is to make each user-derived field in the findOne filter explicitly use $eq. That way, even if an attacker sends an object like { $ne: null } as drugNdcCode, it will be used as the literal value of the equality comparison instead of being interpreted as an operator. We can keep the rest of the logic intact: still look up by first name, last name, DOB, and NDC when drugNdcCode is present. Concretely, in src/ncpdp/script.ts, in the handleRxFill logic around line 308–314, we should change the findOne call to:

remsCase = await remsCaseCollection.findOne({
  patientFirstName: { $eq: patientInfo.firstName },
  patientLastName: { $eq: patientInfo.lastName },
  patientDOB: { $eq: patientInfo.dob },
  drugNdcCode: { $eq: drugNdcCode }
});

This does not require new imports or helper functions and doesn’t alter the logical behavior for legitimate scalar inputs; it simply hardens the query against operator injection.