Proposal for Results Interpretation Module (RIM) Implementation for G6PD

[f-odhiambo]

In order to deliver on the Results Interpretation Module (RIM) for Quest/G6PD, we have the following tables as a prerequisite for the computation of G6PD enzyme levels thresholds in patients based on the chart below, for clinical decision support and treatment recommendation

G6PD Computation Flow

G6PD Threshold levels based on Gender (Male/Female)

G6PD Workflow design based on FHIR Resources mapping

An editable version of this flow diagram is available here

Acceptance Criteria

1. RIM/ G6PD thresholds should not be computed if

• A person is below 16yrs of age
• Pregnant
• Data entered in N/A or Error mode

2. RIM must have at least the following to compute & retrieve from the ServiceRequest lining the Patient, Observations resources

• Patients Gender
• G6PD thresholds loaded
• Observation details

3. G6PD test results computed and viewed from Patient profile and status added to the patient list

Open Questions

1. Usage of FHIRPath and CQL applicability to make RIM Configurable

• FHIRPath is not yet fully supported on SDK
• CQL will require one to create a CQL Library with thresholds and a CQL Evaluator module to evaluate expressions

2. We cannot get Practioner details until the user details endpoint synced at login is fully scoped to support syncing to details i.e a Practioner ID that has a reference to the Location of facility and Facility details

[f-odhiambo]

We could start by the non RIM components to unlock some end to end pieces such as the profile page with Test results fed from a Diagnostic report /Questionnaire Response if user enter data in Error or N/A mode

The Normal, Intermediate and Deficient results to be done via RIM

[mwkhan1983]

Also we can hard code G6PD thresholds for now and add configurability later when open questions are addressed.

[pld]

1-7 look like they'll be handled by existing features, plus an implementation of the app definition component of #594

[pld]

For 8-11, I think we can generalize this with an additional post-Questionniare submission step, so that our post-Questionnaire process is

I also don't think we need to do step 8, or we can combine it with step 9

1. save QuestionniareResponse, add the app-id from the Questionnaire
2. check if there is any linked extraction (via Definitions in the Questionnaire, StructureMaps, or the third way I can't remember)
   a. if there is, extract the additional resources via all linked methods (there may be multiple), add the app-id from the Questionnaire
3. check if there is any CQL linked to this Questionnaire
   a. if there is, execute the CQL

I guess, my question is, can CQL handle (or can we make it handle) everything that needs to happen in steps 8/9-11?

[f-odhiambo]

This proposal is closely aligned to this https://www.hl7.org/FHIR/diagnostics-module.html

[f-odhiambo]

Some Updates

Update codes to SNOMED instead of LOINC codes to be inline for CQL expression evaluation - DONE
Haemoglobin

1. SNOMED System URL code https://snomedbrowser.com/Codes/Details/259695003
2. SNOMED Concept ID: 259695003
3. Unit = g/DL

G6PD

1. SNOMED System URL code https://snomedbrowser.com/Codes/Details/86859003
2. SNOMED Concept ID: 86859003
3. Unit = U/g Hb

Initial CQL research

1. You can create and test your CQL on this CQL Runner - https://cql-runner.dataphoria.org/
2. Patient being used here - https://cql-sandbox.alphora.com/cqf-ruler-r4/fhir/Patient/P48
3. All related resources to run this CQL for this ☝️ patient https://cql-sandbox.alphora.com/cqf-ruler-r4/fhir/Patient/P48/$everything
4. Sample CQL below
5. CQL computes based on individual extracted resources i.e A Patient + related Observation and Conditions
6. Trying to author a CQL statement - currently able to filter age and if pregnant or not , looking into threshold management
7. Also continuing RnD on FHIRPath application

[pld]

do we need to do any RnD for FHIRPath? Don't we know we can't use it on device in the near-term, doesn't that rule it out?

[f-odhiambo]

@pld FHIRPath expression support is logged here google/android-fhir#803 however we have FHIR Path expressions support inside the StructureMap. So we might not rule this out in the short term. Following up with @ekigamba on this

[pld]

awesome, that's good news, let's chat w/our implementing partner once we have more info on the options and a recommendation. Is there a reason we'd prefer FHIRPath here?

Architecture-wise, we could abstract our post-structure-map "computation" step to execute FHIRPath or CQL based on what resources it sees tied to that step.

[f-odhiambo]

Update

1. We made some breakthroughs on CQL Evaluation - App can evaluate CQL expression for G6PD thresholds. Pending work on how to consume the output of CQL output. Giving correct interim results.
2. Kudos @maimoona K @davison Mghanga Kimigho on the RnD work done so far on the CQLEvaluatorSample app and integration to FHIR Core 🙌:tada. more details here Quest/G6PD - Test CQL statement on CQLEvaluator module and document findings #731 (comment)

G6PD Test Family = Patient + Observations for both Hb and G6PD

1. Mansa Mussa - HHH - Abnormal Hb - Result - N/A https://turn-fhir.smartregister.org/fhir/Patient/4751/$everything
2. Maria Mussa - Pregnant mom - Result - N/A https://turn-fhir.smartregister.org/fhir/Patient/4752/$everything
3. Tom Mussa - Underage Patient - Result - N/A https://turn-fhir.smartregister.org/fhir/Patient/4753/$everything
4. Rick Mussa - Normal Hb Patient - Result - Recommendation https://turn-fhir.smartregister.org/fhir/Patient/4754/$everything
5. Robert Mussa - Intermediate Hb Patient - Result - Recommendation https://turn-fhir.smartregister.org/fhir/Patient/4755/$everything
6. John Mussa - Deficient Hb Patient - Result - Recommendation https://turn-fhir.smartregister.org/fhir/Patient/4778/$everything
7. Jane Mussa - Normal Hb Patient - Result - Recommendation https://turn-fhir.smartregister.org/fhir/Patient/4756/$everything
8. Janet Mussa - Intermediate Hb Patient - Result - Recommendation https://turn-fhir.smartregister.org/fhir/Patient/4757/$everything
9. Jill Mussa - Deficient Hb Patient - Result - Recommendation https://turn-fhir.smartregister.org/fhir/Patient/4758/$everything

Next Steps

1. To update the ticket Proposal for Results Interpretation Module (RIM) Implementation for G6PD #659 with the next steps for RIM implementation

[f-odhiambo]

Proposal for RIM Wokflow - WIP 16th Nov 2021

Updated flow here

1. Register and save clients - add Patient resource
2. Go to G6PD Test - Questionnaire
3. Fill in Survey and Add Image capture of the G6PD test device screen with the determined threshold levels detail. This should also have a loading image via questionnaire for instructions on how to conduct test
4. Submit Response
5. Save Questionnaire response and extract Observation resources for both Haemoglobin and G6PD Enzyme levels with references to the Patient
6. Create a Service Request that tracks the requested procedure
7. Initiate Evaluation via CQL Module
8. Post Evaluation save results onto a Diagnostic report
9. Update Service Request with the ID of new Diagnostic report
10. Create a Medication request based on the reported Diagnostic test results

Design Implementation - https://www.figma.com/file/PDv9RjEun7Y7Xhqzt48EOB/COVID19-FHIR-Future-(All-Sandbox)?node-id=2202%3A11979

1. Evaluation page
2. Reporting page
3. View Previous test results
   NB. Calibration page ** Not confirmed as a hard deliverable

Pending issues

1. Edit patient
2. Filter DOB - Nice to have
3. Filter by Location -Linked to the practitioner (Location mapping/hierarchy requirement)
4. Calibration via Control mode

Other follow up items

1. Standardization of Codes

• SNOMED vs LOINC - Use SNOMED as the preferred system
• SNOMED URL - http://snomed.info/sct

2. 3rd party system to manage CQL authoring

1. Translator Library - CQL to ELM converter
2. Portal to update Library

More comments on CQL Evaluation RnD here and a WIP PR here which should not yet be merged

[pld]

Is the ServiceRequest created through extraction?

[pld]

like via a StructureMap

[f-odhiambo]

Based on this discussion point here #433 seems like this could be a case for StructureMap-based extraction

[pld]

Cool sounds great

[f-odhiambo]

@maimoonak Some thoughts here: Do we need to do the G6PD initial validation on the app via the questionnaire or let CQL do everything as it is currently doing? Somes options

1. Do some screening on app for Error, N/A and High levels
2. Let CQL do everything as it is currently doing this update the questionnaire to only do data collection and not filtering of edge cases i.e point 1

[pld]

Yea worth considering, if we do screening on app how would we encode/configure it? Would that go in a StructureMap or the validation section of a Questionnaire?

Wondering how we'd address (1) without writing custom code

[maimoonak]

The SDK rightnow does not support calculations, hence, we would have to do validations which need complex calculations or are dependent on multiple fields via CQL. StructureMap does not do validation at the moment. Current code after submission just saves the data extracted and ends the flow (if for any reason extracted entities are empty it would end the flow without saving any data). CQL, as we planned was supposed to do the same. i.e. extract the entities and end the flow.

For validation on both, StructureMap, CQL we would have to define a protocol and expect user to follow that.. e.g. signal Success/Error = true within StructureMap/CQL script (FHIR does not define any such thing, this would be our own standard)

Ideally the validation should be as close to presentation layer as possible. So for required, or value range validation we should aim the in-questionnaire validations. For validations needing calculations we can do this in CQL and handle the result. i.e. if CQL flags error=true then show the error message and remain on questionnaire, otherwise do the extraction.

[f-odhiambo]

Cool. This is noted. Will groom this on Monday and start implementation ASAP based on what we have so far. Thanks for the feedback @maimoonak

[f-odhiambo]

Related Tickets

• Configurable Login Page with G6PD logo - Quest v0.1 / G6PD: Authentication  #569, Quest v0.2: Add a configurable login page for the app #605
• Sync G6PD clients - Quest v0.1 / G6PD: Publisher based Questionnaire sync #571, Quest v0.1 / G6PD: Add tags to Questionnaire to link to G6PD specific Patients/Content/Resources #633
• Paginated patient list view with G6PD test status label - Quest v0.1 / G6PD: Patient List View  #568
• Quest v0.2 / G6PD : View G6PD Status on the Patient List view  #777
• Patient registration and Enrollment - Quest v0.1 / G6PD: Patient Registration #567
• Patient Search - Patient search  #20
• Filter and pagination for search  #54
• Patient Profile - Quest v0.1 / G6PD: Patient Profile View #585
• Quest v0.2 / G6PD : View Test Results Page #779
• G6PD test page - show previous results - Quest v0.2 / G6PD : G6PD Administer Test page  #778
• G6PD survey - Questionnaire with Image support, take and upload an image - Quest v0.2 / G6PD: test results questionnaire  #570
• Quest v0.2 / G6PD: Capture responses & submit questionnaire #598
• Quest v0.2/ G6PD: In the G6PD Test questionnaire on press N/A, add High and Low Hemoglobin checkbox #653
• Quest v0.2 / G6PD: Show instructions #596
• Resource Extraction - Quest v0.2 / G6PD: Create FHIR Service Request #597
• Support for RIM and CQL Evaluation - Quest v0.2 / G6PD : Upload revised CQL expression for Evaluation of the G6PD thresholds and Recommendation  #781
• Quest/G6PD - Test CQL statement on CQLEvaluator module and document findings #731
• Quest v0.2 / G6PD : Move CQL Evaluation components into the Single APK Approach/Quest architecture  #780
• G6PD Test Results Page - Review FHIR models & relationships to support scheduling  #77

9

[f-odhiambo]

Updated flow - Jan 3rd 2022
Editable version available here

[f-odhiambo]

Steps 9 to 10 are being executed via CQL

1. ServiceRequest and DiagnosticReport can be created via CQL referenced here
2. Need to chat to the client about

• Control mode
• Device management
• MedicationRequest