chore (#123): openmrs mediator e2e test

[lorerod]

Description

#123

Code review checklist

• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[PrjShrestha]

@witash

Note: Good to have for further enhancement:

Is this where we are converting OpenMRS patient to CHT patient? If so:

Can we implement a CHT resource mapper strategy based on deployment-specific patient types, ANC, and pregnancy forms? This strategy will create mappers with particular functions to map FHIR resources to specific sub-resource types in CHT (e.g., patient type A, patient type B), using a strategy suited for that deployment. By doing so, we can write and execute the appropriate mapping logic. This approach will also allow us to accommodate any new patient forms, such as ANC or pregnancy forms, that may differ across deployments.

interface PatientMappingStrategy {
  map(fhirPatient: fhir4.Patient): any;
}

function getPatientMappingStratergy {
  static getStrategy(deploymentType: string): PatientMappingStrategy {
    switch (deploymentType) {
      case 'Gandaki':
        return new PatientWithPhoneMappingStrategy();
     case 'West Africa':
        return new PatientWithNotesInFrench()
      default:
        return new PatientWithoutPhoneMappingStrategy();
    }
  }
}

class PatientWithPhoneMappingStrategy implements PatientMappingStrategy {
  map patient with phone
}

class PatientWithoutMappingStrategy implements PatientMappingStrategy {
  optionalphone
}

Usage: 
const mappingStrategy = getPatientMappingStratergy (deploymentType);

const chtPatient = mappingStrategy.map(fhirPatient);

Note: Seems this can also be integrated into the cht-request-factories that you have created by adding the strategy logic for each resource type the factory produces. Doing that will further allow to handle even more cases like if the same deployments have 2 different configs for the same resource.

[witash]

@lorerod going to merge this so the branches don't diverge again