[REMS-290] Prefetch changes

[KeeyanGhoreshi]

This PR makes some simple changes to the prefetch generation of the request generator to have it match what is currently accepted by the REMS CRD app. To test it you can send a hook and see that it contains the intended prefetch, though the CRD app currently does not use it. I am going to write a small essay now about the prefetch, next steps, and how everything works so that in the future we can refer back here.

Notes

Prefetch is defined in a hook as a series of key/value pairs where the value is typically of the form:

      "prefetch": {
        "patientToGreet": "Patient/{{context.patientId}}"
      }

Here, context stands in for the actual context section of the hook. More info here: https://cds-hooks.hl7.org/1.0/#context

Context is a property of the "hook", which means it isn't actually defined anywhere in the discovery endpoint. For example order-sign, which is what we generally use, has a context defined here: https://cds-hooks.org/hooks/order-sign/

This context is contained in the request generators finished hook which it sends off to CRD but it is missing the userId, which is currently just set to Practitioner/Example. Moreover, we don't even use the context to fill out the prefetch, the prefetch is generated independently.

Prefetch generation in request generator as it currently stands is initiated in PatientBox.js which uses the PrefetchTemplate class to fill out the prefetch tokens. For example, it is here where Patient/{{context.patientId}} would be converted into Patient/pat1234.

Completed "tokens", which is the name given to the {{context.patientId}} elements, are then given to PatientBox to make a request off the base EHR url, and then put into a map which is later used to populate the prefetch. The map contains both the key, which in our example is patientToGreet and the fetched resource, which in this case is the Patient that is currently in context.

Prior to this pull request, keys like patientToGreet were not used, but rather ignored and the prefetch was constructed based solely on the type of request being given to the requestGenerator. Medication requests and Device requests would trigger different prefetch construction.

With this PR, the prefetch is constructed according to the key-value pairs given to it, so the patient resource will now show up in the completed prefetch as:

prefetch: {
  patientToGreet: {
    resource...
  }
}

Ideally, this set of key-value pairs is given by the cds-service discovery endpoint, which in our case defines three elements:

const prefetch: OrderSignPrefetch = {
  patient: 'Patient/{{context.patientId}}',
  request:'MedicationRequest?_id={{context.draftOrders.MedicationRequest.id}}',
  practitioner: 'Practitioner/{{context.userId}}'
}

But we do not fetch the discovery endpoint. In the request generator, with this PR, on line 101 of the patient box, the keys are given directly to the prefetch template. Their values are again coded into the request generator here, where we redefine what is already defined above:

const PRACTITIONER_PREFETCH = new PrefetchTemplate(
      "{{context.userId}}");
    const REQUEST_PREFETCH = new PrefetchTemplate(
      "MedicationRequest/{{context.medications.MedicationRequest.id}}");
    const PATIENT_PREFETCH = new PrefetchTemplate("{{context.patientId}}");

Making the keys and values automatically obtained from the discovery endpoint is an area for further work.

When the prefetchTemplate goes to fill out the context, it does not pull it from the hooks context field as intended. Instead, context paths like {{context.medications.MedicationRequest.id}} are mapped here. You will notice that the context path is paired with a list. The list is the path to the information that is desired, but through the request resource.

So {{context.medications.MedicationRequest.id}} gets mapped to ['id'], which is the path starting from MedicationRequest. The same thing can be seen with context.patientId, which is mapped to ['subject', 'reference'], which is how you would get to the patient ID associated with a MedicationRequest. This way, the values still get filled, just from the MedicationRequest resource, not the context, which again doesn't really exist on the request generator as of now.

Another area for further work would be to make and use the actual context as defined by the hook, instead of this mapping.

So, to get things working according to spec, the request generator needs to retrieve (or cache) the cds-service discovery endpoints hook, which defines the prefetch tokens required. Then it needs to build its context for real and use it to satisfy the prefetch tokens before making queries to the EHR.

Changing things as they are currently

If we want to change the prefetch as it stands in this PR without making any of the above changes, the way to do it would be to first modify the type in the CRD app OrderSignRequestPrefetch, which defines what is expected in the prefetch. Then, the patient box would need to be updated with any new keys here and the prefetch template would need to define the path to the resource being requested here, the key added to the map here, and if any further info from the context is needed it needs to be added here.

These are all very minor changes, maybe a line or two. This will add a property or remove one from the prefetch. The Hook can be updated to reflect this change in the OrderSignPrefetch and then in rems.hook.ts but since we don't fetch the hook from the discovery endpoint anyway, it doesn't actually do anything.