Tuesday, May 22, 2018

Week 1

Design phase 

Currently, sync2 depends on AtomFeed and Fhir/REST modules for synchronizing Patient and related metadata in Openmrs. As a matter of fact that the MergePatientData module will be an improvement of the sync module, I was advised that it should depend on the sync2 module. What basically fails sync2 is synchronizing data that existed before it was running in the OpenMRS context. Since we are depending on sync2, I spent the 1st week trying to gather information and looking at the entire codebase of sync and how it works. I came with a simple design. MergePatientData should checkout all existing synchronize-able data at a given Node(Could be child/parent). If sync is running, get data from sync tables, do a filtration of data and store it in a zip file with some encryption. The module should be able to download the zip file.
In a nutshell, I have encountered the following:
  • I started designing a workflow of how the project will be best implemented.
  • I closely studied and inspected the codebase of the sync module and left at an average understanding of the entire logic.
  • I created a skeleton(an initialization) of the module(mergepatientdata)

Blockers

I don't know whether its quite trivial but in the process of studying sync, All I know it uses AtomFeed module to update it of new events/feeds but I have failed to understand how :( . 

No comments:

Post a Comment