Important notes:

• No code changes in OC

• All configuration should be via UI. No backend or direct SQLs etc.

• Integration should happen in real-time as much possible. CRF sync'ing can be nightly if there are technical challenges.

• For every object added from OC to OS (patient, site, visit, crf, etc) there should be an entry in an audit log table (this can be a central table e.g. object_type, OC_ID, OS_ID, created_date, last_updated_date)

• OC or OS database should not be accessed directly. All data access should be via APIs.

Error handling:

• An error log table should be present to log all errors.

• Error should be emailed to the system admin too.

• Error should be accompanied with meaningful errors.

Study and Site link

• It should be possible to link an OC study to OS collection protocol. This can be done either by displaying a dropdown of OC studies (via an OC  API to get all studies) OR just giving a text box to enter the OC study code/title.

• Configuration should include OC URL/instance. This will enable different studies to have different OC instances.

• Same for Site.

Patient and visit link

• This is one way link from OC to OS.

• When a patient is registered in OC, it should get automatically registered in OS for the linked study.

• The “study ID” field in OC should be duplicated as PPID field in OS.

• It should be possible to map fields to OC to either static domain object fields or extension fields of OS

• Ditto to Visits.

CRF syncing

Metadata synching

• When a study is linked, its CRFs in OC should be replicated in OS under that study.

• In OC these will be visit level CRFs.

• If a new version of CRF is updated in OC, it should be synced in OS

CRF data syncing

• Each time a CRF is CRUD in OC, it should be synced in OS