Expand SoF Client list configuration to include logic check for availability

[pbugni]

Extend the SoF client list configuration to include optional logic check - a bit of {fhirpath, CQL, TBD} dynamically run per patient, which evaluates {true, false} for display of the respective SoF client launch button, on each respective patient. We have configuration to plug in multiple SoF clients. But not all patients should expose all configured SoF clients. We need a mechanism to determine if respective SoF client launch buttons should be enabled/visible on a per client basis.

For example, ISACC should include:

• [Enrollment] only if the FHIR query CarePlan?category=isacc-message-plan&subject=Patient/{patient.id} returns zero results
• [Messaging] only if the FHIR query CarePlan?category=isacc-message-plan&subject=Patient/{patient.id}&status=active returns positive results

Or for DCW:

• [Longitudinal] only if FHIR query QuestionnaireResponse?subject=Patient/{patient.id} returns positive results

This logic check should also apply to the buttons available or default action when filling in the search boxes. Example: ISACC new patient should go directly into the enrollment client, rather than the current flow that creates a patient and then requires a second user action to click the enroll.

[lober]

https://app.diagrams.net/#G1gQ8HXK9NOBJcTraXX0S_NXpAS2hMm7ID

https://drive.google.com/file/d/1gQ8HXK9NOBJcTraXX0S_NXpAS2hMm7ID/view?usp=sharing

Drawing for reconfiguring screen items (not sure which of the above will work)

[mcjustin]

@pbugni as we discussed today, some clients should be conditionally available in the patient list. For example, the longitudinal QuestionnaireResponse report client (repo coming soon from @achen2401 ) should only be linked from fEMR if there is at least one QR for the patient.

[pbugni]

Note, this same logic check will probably be desired for more menu options, which should most likely also become SoF client launch URLs...