Define G6PD MVP

[vincent-karuri]

There are a few things to keep track of here:

1. Implementation of the standalone IPE module as envisioned here
2. The definition and evaluation of CQL libraries that generate CarePlans based on G6PD device readings
3. Implementation of UI mockups (subject to change) with specific focus on how SDC supports adding custom Questionnaire widgets e.g. ImageView widget, IPE widget
4. Aligning G6PD and Covax to use more generic flows e.g. "what happens after Patient registration, is a CarePlan generated in all cases?". This will help unify the UI components and flows (otherwise, we might need to define a framework for how the UI can be configured https://github.com/opensrp/fhircore/issues/81).
5. Support adding IPE as an opt-in module. Related to https://github.com/opensrp/fhircore/issues/32.
6. Finding a reliable solution to 7-segment display OCR https://github.com/OpenSRP/fhircore/issues/82.

From this list of features, we need to define a subset as going into the MVP.

[vincent-karuri]

If we go with only implementing manual entry for the MVP, we would just need 3 and 4.

If we make the above assumption then a few more things apply:

• The suggestion atm is to also do 6 concurrently but maybe not necessarily include it in the MVP?
• 2 is part of a larger discussion on CQL evaluation on Android and while it wouldn't affect the MVP, is a blocker to the final product.
• I think 5 doesn't need to be implemented for an MVP if we can achieve 4 and hard-code a few things e.g. Resources.
• Implementation of 1 can also be deferred for the MVP as we firm-up discussions on the possible changes in approach

[pld]

• agree, 6 not part of MVP but done concurrently
• agree, 2 not needed for MVP but we can collect all the hard-coded FHIR files (that may later be loaded from FHIR server, or converted to another form, like CQL) for the MVP in a directory
• agree, 1 and 5 not needed for MVP

For (4) I'd say yes, as w/Covax (correct?) we always generate a CarePlan from a (PlanDefinition, Patient) tuple after registration, where the PlanDefinition used to generate CarePlan is configured

[vincent-karuri]

It's not too clear to me what the exact flow is for Covax after registration. From the mockups, it looks like you register a Patient, then fill in a Questionnaire to select a vaccine to be administered to the Patient. What's unclear is if the vaccine selection is supposed to be part of one form or two separate forms. But in the case that it's one, then yes, we should generate the vaccination CarePlan after the registration Questionnaire is submitted. I think it's reasonable to assume most registration flows will lead to the generation of a CarePlan (since some immediate action is most likely expected after registration). We can then use this to standardize flows.

[vincent-karuri]

For 3, multi-step forms will not be supported until this is developed https://github.com/google/android-fhir/issues/186.

[vincent-karuri]

Also for 3, we may want to define widgets with a custom look/feel. Currently, all widgets reside in the FHIR SDK and I don't think there's (can't find) support to override them on the client. If we want to display job aids and embed IPE, we may want to see whether custom support can be added.

@jingtang10, could you please confirm if this is the case and if we have plans to support customization?

[vincent-karuri]

Found this issue as related to above https://github.com/google/android-fhir/issues/447.

[rkodev]

Addressing number 4. In the event that we make the assumption, a CarePlan is automatically generated on Patient Registration, we do have a number of scenarios that will need to be handled as well.

1. Is the assumption that only 1 Plan Definition will be active per campaign? Do we intend to support multiple care plans, this is already possible in the reveal application where Plans are considered Campaigns, active for a duration. In the CHW application, we can consider the different Registers as different CarePlans a Patient can be part of i.e a Patient can be in a Malaria Care Plan and Child Vaccination Care Plan as well.

2. We do have instances where generating a Care Plan would only be considered appropriate because of a deliberate status change i.e when a questionnaire is filled. An example would be when a Woman is registered for services such as ANC / PNC or a child is diagnosed with Malaria.

A more generic flow would be a Patient may or may not have an active CarePlan. Generation of Care Plans would be dependent on whether at least 1 of the triggers and condition defined in the Plans activity definition is met

[pld]

For 3, multi-step forms will not be supported until this is developed google/android-fhir#186.

We can start w/a single-step form for MVP

[pld]

Addressing number 4. In the event that we make the assumption, a CarePlan is automatically generated on Patient Registration, we do have a number of scenarios that will need to be handled as well.

1. Is the assumption that only 1 Plan Definition will be active per campaign? Do we intend to support multiple care plans, this is already possible in the reveal application where Plans are considered **Campaigns**, active for a duration. In the CHW application, we can consider the different Registers as different CarePlans a Patient can be part of i.e a Patient can be in a Malaria Care Plan and Child Vaccination Care Plan as well.

We have options here, but it sounds like the standard pattern is 1 CarePlan per patient, with multiple PlanDefinition resources that are applied to create and update it (keeping a revision history)

[vincent-karuri]

I don't know that having multiple CarePlans is a problem, the PlanDefinition would determine how many to generate after a Patient registration.

Also, my thinking was the opposite, multiple CarePlans can be generated from a single PlanDefinition. I guess we can always have multiple PlanDefinitions but not sure why we'd need them?

[pld]

It's not that it's a problem, it's that it's not what's normally done, but like I said, that doesn't mean we can't do it esp if our use case is very different from the large facility use case FHIR is normally used in.

I think the reasoning behind single CarePlan per patient is that a CarePlan is designed to represent the current state of all the care the patient is receiving, ie looking through the patients CarePlan gives you an insight into anything relevant to them.

You need a PlanDefinition per care service, eg you'd have a PlanDefinition each for ANC, malaria, Covid vax. When the patient is registered for those services you'd update that patients CarePlan to include the portions of that PlanDefinition relevant to them

[pld]

Another perspective on multiple PlanDefinitions, is that each smart guideline is going to be defined (or used analogously to, is my current understanding) a PlanDefinition and there will be a smart guideline per health/care scenario, and you'd want to "combine" them into a single plan providing the relevant care to your patient/client, via their CarePlan

[vincent-karuri]

Ok, so PlanDefinition per service was what I was missing. So do we have logic/an operation specified by FHIR for implementing update of an existing CarePlan or do we define that ourselves?

[pld]

^ cool, this slide that Fred made is helpful to understand this, the blue is the single careplan, the brown on top is a plandef that groups other plandefs (called a strategy or pathway). The different sub-plandefs are invoked as patient is being modified via data points in green that are going into patient and other resources, altering the data used to trigger different parts of the strategy.

To your question, that's unknown currently, but some of that very likely goes in https://github.com/google/android-fhir, we need to work together to figure that out. We'll need something like

while true
    sleep until patient changes
    patient.careplan_history += patient.careplan
    for plandef in patient.valid_plan_defs:
        patient.careplan = update_care_plan(patient, plandef)

[vincent-karuri]

Yea, the state machine comment cool

[rkodev]

@pld The FHIR spec on how to implement the $apply operation is the cause of some of the confusion. The documentation has no reference to an active Care Plan as any of the inputs, this was what led me to the assumption that a Care Plan once generated is in its final state, and is also why I was leaning towards having at least a Questionnaire filled before generating the Care Plan.

Having Care Plans re-evaluated upon every event makes a lot more sense, it feels like breaking the FHIR documentation but its also the most logical implementation

[pld]

Cool, hmm, yea I was thinking of the registration Questionnaire as the one that's completed before we create a CarePlan.

On previous CarePlan, I thought this would get passed to apply by being a reference in the Patient resource that is passed as subject to the $apply. But it seems like this would really depend on how $apply is implemented, so we need to talk to Bryn more about it, so far what he saying makes it sound like $apply will take the Patient's current CarePlan into account, but agree we need to make that clearer.

[vincent-karuri]

And in another side discussion we've had with @rkodev we've come up with a few thoughts:

1. We need a way to mark Tasks in a CarePlan as complete
2. To do so we can tie each Task to a Questionnaire it needs to launch for data collection
3. All QuestionnaireResponses are run through the ResourceMapper (similar to what we have with EventClient processing)
4. Observations generated from 3 are run through the $apply operation to generate a CarePlan

[pld]

And in another side discussion we've had with @rkodev we've come up with a few thoughts:

1. We need a way to mark Tasks in a CarePlan as complete

will task.status handle this?

2. To do so we can tie each Task to a Questionnaire it needs to launch for data collection

Not sure all tasks will require Questionnaire completion, but yea raises the question, where do we store the business logic that modifies task.status PlanDefinition then in CarePlan or is that at a different level? Certainly would need to be in configurable syncable format

3. All QuestionnaireResponses are run through the ResourceMapper (similar to what we have with EventClient processing)

Probably, we got critical feedback from the ThoughtWork's FHIR team that using a Questionnaire and QuestionnaireResponse are a roundabout way to get data into an update arbitrary resource, it's not clear what a good configurable and syncable alternative here is but we should discuss.

4. Observations generated from 3 are run through the $apply operation to generate a CarePlan

Yea, but I'd think not directly, instead via their link to a patient, again tbd w/Bryn to figure this out

[rkodev]

@pld The Encounter can be the one providing the medical context in the $apply. It still feels like a violation of the FHIR Specs to modify a Care Plan, from the FHIR spec

CarePlan represents a specific intent, not a general definition. Protocols and order sets are supported through PlanDefinition.

Also, the property CarePlan.replaces shows an indication that a CarePlan can be replaced in case an Outcome changes activity in a Care Plan.

[vincent-karuri]

yea, if there are other ways to mark Tasks as complete, we'll need to explore them and see if we intend to use them for our use cases. Is there more information/documentation on the ThoughtWorks conversation? It'd also be good to get some documentation of the discussions with Bryn.

[pld]

@pld The Encounter can be the one providing the medical context in the $apply.

OK I see, thanks I missed that, so whenever we see a new encounter, we'd run apply to potentially generate a new (replacement) CarePlan?

It still feels like a violation of the FHIR Specs to modify a Care Plan, from the FHIR spec

CarePlan represents a specific intent, not a general definition. Protocols and order sets are supported through PlanDefinition.

Also, the property CarePlan.replaces shows an indication that a CarePlan can be replaced in case an Outcome changes activity in a Care Plan.

Ah oK cool yea not modify but replace makes sense and was what I was thinking, is that conformant w/the FHIR spec?