Update automated tests for CHT and OpenMRS endpoints in the mediator

[witash]

Automated tests cover only FHIR endpoints.
Now that there are additional endpoints for OpenMRS and CHT, these need to be added to automated tests.

[andrablaj]

At this moment, tests should be added to the openmrs-mediator branch, pending the merge of #115.

Per discussion in Slack, Binod suggests:

it would be nice to have end to end tests similar to the ones we have:

• e2e-test.sh
• ltfu-flow.spec.js

[andrablaj]

The current workflows:

[lorerod]

@witash, I'm starting to work on this so you can focus on other needed developments.
Let me know if this is ok with you.

[lorerod]

@witash I have a question about the CHT Patient to OpenMRS diagram. Is the entire flow triggered only by the creation of the patient in the CHT?

[witash]

Yes, it was, but #124 and #125 changed this; the point was to decoupe cht and openmrs, so cht only sends requests to the FHIR Server, and the same for OpenMRS; neither one knows or cares that the other side exists. So for patients, the only difference between this branch and the LTFU is that cht is sending raw documents instead of already FHIR formatted requests. And it creates Observation Resources as part of Encounters when CHT forms are submitted.

updated sequence diagrams:
for patients created in cht
for form submissions in cht

Then, for OpenMRS, it doesn't have any subscription or event based messaging yet, so the mediator needs to poll it.
here is the sequence diagram for that. Its also supposed to be a two-way sync, so in adddition to sending new resources from FHIR to OpenMRS, it gets new resources from OpenMRS to FHIR. theres no diagram for that yet.

So. for end to end tests we need

1. Patient Document sent from outbound push gets saved in FHIR Server

• [ document and add cht configs to configurator]
• [ postman collections for outbound push requests ]

3. Encounter Document sent from outbound push gets saved in FHIR Server (w/ fields encoded as observations)

• [ document and add cht configs to configurator]
• [ postman collections for outbound push requests ]

4. New Patients in FHIR are sent to OpenMRS
5. New Patients in OpenMRS are sent to FHIR
6. New Encounters in FHIR are sent to OpenMRS - there's a different format and patient ids may be different

• [ document different format ]
• [ postman collections ]

8. New Encounters in OpenMRS are sent FHIR
9. New Encounters in FHIR are sent to CHT - with observations attached and coded to cht form fields

• [ document and add cht configs to configurator]
• [ postman collections for incoming form ]

11. New Patients in FHIR are sent to CHT - with the right patient_ids and parent_id (place_id).

• [ document and add cht configs to configurator]
• [ postman collections for outbound push requests ]

[lorerod]

Okay, thanks. Independent of the point of decoupling cht and openers, does it still make sense to implement e2e test scenarios representing the entire workflow?

CHT to OpenMRS workflow

1. Patient Document sent from outbound push gets saved in FHIR Server
2. New Patients in FHIR are sent to OpenMRS
3. Encounter Document sent from outbound push gets saved in FHIR Server (w/ fields encoded as observations)
4. New Encounters in FHIR are sent to OpenMRS - there's a different format and patient ids may be different

OpenMRS to CHT workflow

1. New Patients in OpenMRS are sent to FHIR
2. New Patients in FHIR are sent to CHT - with the right patient_ids and parent_id (place_id).
3. New Encounters in OpenMRS are sent FHIR
4. New Encounters in FHIR are sent to CHT - with observations attached and coded to cht form fields

And also, does it make sense to combine both? for example: New Patient in OpenMRS with New Encounter in CHT, testing the entire flow.

[lorerod]

Also, do your comments on "add cht configs to configurator" mean those are pending tasks you will implement? Or do I need to add the outbound push config as a precondition in the e2e tests?

[witash]

Also, do your comments on "add cht configs to configurator" mean those are pending tasks you will implement? Or do I need to add the outbound push config as a precondition in the e2e tests?
Those are pending tasks for me to implement.

And also, does it make sense to combine both? for example: New Patient in OpenMRS with New Encounter in CHT, testing the entire flow.
Yes it easiest to combine them since encounters have dependencies on patients.

[lorerod]

More questions, @witash.
Do we also need to create an endpoint, organization, and serviceRequest to trigger the process for the newly created patient, as in the LTFU workflow?
When we talk about Form submission in CHT, are we reusing the interop_follow_up form? I could use some clarification on this.
Thanks in advance, and I'm sorry if this was stated in a documentation that I missed.

Will all of this be replaced by the outbound push configuration?

[witash]

endpoint and organization are not required; they don't have any functional significance. serviceRequests are not synced in this workflow; cht can create tasks from transitions after the patient form is submitted. if necessary, but they are not created by openmrs or any interoperability thing.

By Form submission in CHT I meant something like pregnancy registration; this is an addition to the LTFU workflow where if a CHW submits a pregnancy registration, or any other form thats configured with outbound push, it sends it to the mediator which converts it into an encounter, and the values to observations.

the equivalent of inter_follow_up form is a form created in CHT config, for incoming data; if someone on OpenMRS submits a form that is being tracked in CHT, the mediator goes the other way and converts the Observations and Encounter to the records api. Currently one of these has to be created for every corresponding form in OpenMRS, and also for incoming patients

[lorerod]

@witash, this post is failing
POST openhim-core:5001/mediator/openmrs/patient
Do I need to add any extra steps or config to set up openmrs?

[witash]

POST openhim-core:5001/mediator/openmrs/patient this is not used anymore
for requests to openmrs this commit gets the configurator set up scripts to add the OpenMRS channel automatically. but not going through any mediator so just like POST openhim-core:5001/openmrs/patient

[lorerod]

Ok, I got the latest commits from the openmrs-mediator branch and:
POST openhim-core:5001/openmrs/Patient is giving 500 Internal Server Error: connect ECONNREFUSED 172.21.0.13:8090
I also tried with POST openhim-core:5001/openmrs/patient.
The channel looks ok:

The transaction log after creating a patient:

The failed transaction:

I understand this is a work in progress, and I hope this manual testing has been beneficial.

[lorerod]

I added this element to outbound in cht-config/app_settings.json:

"OPENMRS_patient": {
      "relevant_to": "doc.type === 'person' && doc.role == 'patient'",
      "destination": {
        "base_url": "http://openhim-core:5001",
        "path": "/openmrs/patient",
        "auth": {
          "type": "basic",
          "username": "interop-client",
          "password_key": "openhim1"
        }
      },
      "mapping": {
        "resourceType": {
          "expr": "'Patient'"
        },
        "identifier": {
          "expr": "[{ \"system\": \"cht\", \"use\": \"official\", \"value\": doc._id }]",
          "optional": false
        },
        "name": {
          "expr": "[ { \"use\":\"official\", \"family\": doc.name , \"given\": [ doc.short_name ] } ]",
          "optional": false
        },
        "gender": "doc.sex",
        "birthDate": "doc.date_of_birth"
      }
    }

[andrablaj]

After discussion with @witash, he mentioned some cases that would need tests, once the current e2e tests in the openmrs-mediator branch pass:

• Tests for the edge cases in the sync process, e.g. ensuring no duplicates are created.
• e2e tests for reports.