Extend OpenMRS connector to handle integration with multiple systems

[maimoonak]

Extending OpenMRS connector to handle integration with multiple systems is per-requisite to ziggy refactor #71 . The connector rightnow is tightly coupled with OpenMRS and inheriting it for ziggy refactoring would lead to complexity in code and scalibility and refactoring further. Considering tight timelines, the user learning curve and familiarity of current system to Science team the proposal is to leave most of the field names unchanged and introduce new columns to handle external systems.

CASE 1 : (current scenario)

External system (OpenMRS) is intelligent enough to identify the data and can automatically map OpenSRP mappings to System mapping. Also OpenSRP is not introducing any new standard, rather relying on OpenMRS standards and concept dictionary. Changes required are: Remove openmrs_ prefix from all column names i.e.

Survey sheet:

instance::openmrs_entity_parent -------- instance::entity_parent instance::openmrs_entity -------- instance::entity instance::openmrs_entity_id -------- instance::entity_id

Choices sheet:

instance::openmrs_code -------- instance::code

Example sheet

https://docs.google.com/spreadsheets/d/1sSWo8nKx3BgJ2EMbgO85Jd401s3LEYnUWbKvwinoRY0/edit?usp=sharing

CASE 2:

There are two external systems OpenMRS and DHIS, both have different standards and OpenSRP wants to use its own standard for concept maps. External system should know and must implement a handler for different entity types like encounter, person, person_attribute etc.

Example sheet

https://docs.google.com/spreadsheets/d/1-EiGcbMQPQg35vTDVpCtkfLLc4gRRy7ONOzWFfzzM0Y/edit?usp=sharing

Further details and how-to documentation would be shared after development and further analysis. @cagulas @ndisha @sohelsarder @julkarnain

[mahmedyousuf]

i was suggesting that we develop Application where it could add data to different systems . Application will have all the standards for each system and add data to these systems like openmrs . instead of team going through every system and getting concept ids , putting them in xls forms for all systems .we just make one common standard and science team use it . they just define in xlsform in which system should go and system manages all the standards and adding data in different systems . by using this , there wouldnt be any confusion about concept ids . @maimoonak @ndisha

[maimoonak]

@ahmedihs This is not possible.. We can not predict what system could ever need to be integrated in future. Moreover, this is not possible to automatically detect what science team wants mapping with. This has to be mapped via xlsform. Not only this, whether its the concept mapping in openmrs or data element mapping in dhis, both are done by science team. Even if we manage to detach the mappings from xlsforms, this still has to be mapped by science team and by either a mapper file (same as xlsform mapping) or a UI that allows them to map each form variable to different types of concepts of different systems. Its only science team that can understand and validate a concept or data element (from any custom or international dictionary) against any form field. Although UI system that allows them to do all mapping could be something to think through but it would increase their work. They would have to create xlsform and then create all xlsform variables and their mappings again on system using the UI.

[mahmedyousuf]

ok , then case 2 seems a better approach