Extend openmrs connector to include scheduling data

[ndisha]

@maimoonak worked on the data format for the schedules data:

• the schedule
• when it is due
• when it was fulfilled
• what is the status
• what was action
• who was the receiver of this action
• when it was closed
• what is next to this

Alisa added the following comments:

• the schedule (type & trigger event)
• when it is due (trigger date)
• when it was fulfilled (completion)
• what is the status (due, overdue, given)
• what was action (service provided or schedule edited)
• who was the receiver of this action (client ID)
• who was the provider of this action (User ID)
• when it was closed (expiry date & reason for expiration of schedule other action/close/moved etc)
• what is next to this - what do you mean by this?

Also, if any edits to the schedule are made (ie. manual deletion of schedule for a particular patient) would be good to track this.

For analytics - we will be interested in being able to track numbers of services delivered on time & also pull out cohorts of people that are overdue or nearly overdue and target them with a SMS reminder (these will need to pull info from Schedule, Status & Client ID).

For reporting - we will want to make use of all of these indicators/data also.

@sohelsarder @julkarnain @cagulas @koros @dimasciput Just flagging this format out, does it work for Bangladesh as well? @maimoonak would like to finish on this.

[sohelsarder]

@ndisha these will cover Bangladesh requirements as well, but one items i would like to add, with each schedule data we need to keep trace of its parent schedule reference to browse the total hierarchy of the events.

[ndisha]

@maimoonak the question that Alisa raised on, what is next to this, would that be the flow that would then give us the hierarchy that @sohelsarder is asking for? For example, if the completion of a schedule action is movement to another register, that history can be traced at whatever point?

Please clarify or add the item on the list.

[cafootitt]

Just wanted to flag that the trigger date is NOT when the service is due. The trigger date is the date that is used to trigger the schedule. For example, polio 1 vaccine service schedule is triggered when a child is born; hence, the trigger date is the child's birth date, and it is used to calculate the due date. The due date is: child's birth date + 6 wks. Hope that makes sense. It's small, but important difference.

Also, to give an idea of the types of indicators science teams may want to calculate for service schedules, pls see this spreadsheet that was created for Dristhi. For example:

Indicator 1: On time ANC1 Definition: Of those ANC women who received ANC1 service this month, what proportion was done on time (yellow/blue reminder)?

Indicator 2: Late ANC1 Definition: Of those ANC women who received ANC1 service this month, what proportion was done late (red reminder)?

Indicator 3: Missed ANC1 Definition: Number of women who missed ANC1 this month (reminder expires).

Hope this helps.

[maimoonak]

Below is the complete info of available data in OpenSRP for scheduling and alerts. OpenMRS may require multiple tables for handling the data. The data available can answer following

• the schedule (type & trigger event)
  • (scheduleName & milestone)
• when it is due (trigger date)
  • (referenceDate)
• when it was fulfilled (completion)
  • (fulfillmentDate, completionDate)
• what is the status (due, overdue, given)
  • (alertStatue and EnrollmentStatus)
• what was action (service provided or schedule edited)
  • (I doubt whether its available or not. Also Schedule can not be edited.)
• who was the receiver of this action (client ID)
  • (beneficiaryId)
• who was the provider of this action (User ID)
  • (anmIdentifier/providerId)
• when it was closed (expiry date & reason for expiration of schedule other action/close/moved etc)
  • two types available- alertClosed i.e. completed and Enrollment closed i.e. beneficiary case closed.
• what is next to this -
  • Sohel wanted this but I doubt if its available. We can track hierarchy by dates and schedule names though.

@cagulas The indicator data is not covered in this scheduling part. One can calculate the indicators from encounter data and scheduling data. We can do it via Reporting once scheduling data is made available in OpenMRS..

Entity	Property	Possible Values	Proposed Field Name in OpenMRS
Action	-	-
Action	anmIdentifier	provider uuid or username	providerId
Action	caseID	beneficiary uuid	beneficiaryId
Action	data	allowed to add custom but predefined via ActionData	listed below
Action.data	beneficiaryType	register entities (mother, child, ec)	beneficiaryType
Action.data	scheduleName	schedule name specified in JSON health schedules. (ANC Visit/ lab reminder etc)	scheduleName
Action.data	visitCode	any milestone of specified schedule in JSON.(ANC1/ANC2/ANC3/)	milestone
Action.data	alertStatus	upcoming, normal, urgent, inProcess, complete	alertStatus
Action.data	startDate	startDate of milestone of specified schedule	alertStartDate
Action.data	expiryDate	expiryDate of milestone of specified schedule	alertExpiryDate
Action.data	completionDate	completionDate of milestone OR schedule (weird but closing alert generates a separate Record)	alertCompletionDate
Action.data	reasonForClose	reasonForClose of beneficiary not milestone (weird but generates new Record)	alertCloseReason
Action.data [Action.actionTarget =report]	annualTarget	ignore for now	-
Action.data [Action.actionTarget =report]	monthlySummaries	ignore for now	-
Action	actionTarget	alert, report	-
Action	actionType	createAlert, closeAlert, close, indicator [actionTarget=report]	alertActionType
Action	isActionActive	true, false (alerts marked as inactive on unenrolling beneficiary from schedule)	isAlertActive
Action	timeStamp	alert/action creation time	alertCreationDate
Action	details	did not find the usage anywhere	additionalNote
EnrollmentRecord	externalId	beneficiary uuid	beneficiaryId (used to connect Action with Schedule)
EnrollmentRecord	scheduleName	schedule name in JSON	scheduleName (used to connect Action with Schedule)
EnrollmentRecord	preferredAlertTime	preferred time configured by properties file	preferredTime
EnrollmentRecord	referenceDateTime	trigger date	referenceDate
EnrollmentRecord	enrollmentDateTime	date on which beneficiary enrolled	enrollmentDate
EnrollmentRecord	startingMilestoneName	starting milestone incase earlier ones are missed or skipped	enrollmentMilestone
EnrollmentRecord	earliestStart	earliest window start datetime of current milestone	currentMilestoneEarliestStart
EnrollmentRecord	dueStart	due window start datetime of current milestone	currentMilestoneDueStart
EnrollmentRecord	lateStart	late window start datetime of current milestone	currentMilestoneLateStart
EnrollmentRecord	maxStart	max window start datetime of current milestone	currentMilestoneMaxStart
Enrollment	startOfSchedule	trigger date (not confirmed)	referenceDate
EnrollmentRecord	currentMilestoneName	milestone under process at the moment	currentMilestone
Enrollment	status	ACTIVE, DEFAULTED, COMPLETED, UNENROLLED	enrollmentStatus
EnrollmentRecord	metadata	not used anywhere	-
Enrollment. MilestoneFulfillment	fulfillments	milestones fulfilled for specified schedule	-
MilestoneFulfillment	milestoneName	milestone name in fulfilled milestone list	milestoneName
MilestoneFulfillment	fulfillmentDateTime	milestone fulfillment date in fulfilled milestone list	milestoneFulfillmentDate

[maimoonak]

Thanks Carolyn. This is very important point to keep in mind when designing system and I wasn't aware of it. I would like to mention one thing that is there is difference between the scheduling data and reporting requirements of indicators. Means that scheduling component would allow access to all data regarding scheduling including all types of timestamps, group info , beneficiaries, providers etc. But the indicator info is generated from person event data and scheduling data. It is helpful for us to understand the requirements clearly but scheduling will not be based on indicators. Let me share our understanding of system in next email... then you can provide your input on whether it fulfills all reporting requirements...

[cafootitt]

Thanks @maimoonak. Understood. I just wanted to share that in a comment, so we're aware of likely reporting needs to make sure all data that we need for reporting needs is covered in the connector module. From your response, it seems like everything is covered. Thx.

[maimoonak]

Attached is the diagram of identified entities for OpenMRS scheduler tracker. Since this is priority the scheduletracker would be data store only with REST API. In next phase it would be refined further for scheduling capacity in OpenMRS.

[maimoonak]

@sohelsarder @julkarnain @ndisha the basic arch of schedule data syncing added with completed schedules pushed to openmrs. The functionality although needs detailed testing and more work but can be used to test response to different schedules and to get an idea of hat type of changes you may need to merge in your branch. The functionality is NOT usable in field at the moment. Please test and provide your feedback. The openmrs side omod link is below https://drive.google.com/a/ihsinformatics.com/file/d/0BzS8x1-rizzKOWxVYk5fbHlpdFU/view?usp=sharing and opensrp branch is https://github.com/OpenSRP/opensrp-server/tree/81connectorExtend_mk

Two days of more dedicated work can make the module in stable and releaseable state. Hopefully, by next week we can get it fully done and tested.

[sohelsarder]

@maimoonak thats a excellent initiative, it is understandable some changes required for different schedule requirements. Please let us know while minimal viable things ready for check we would merge then with our branch and send you our observations.

[maimoonak]

@sohelsarder The pull request has been created for the work done. Please test code for your branch. I have added test cases for HH data and as well as different scenarios too. Steps to make it work.

• Download omod from link provided.
• Upload OR Clean and reupload if already exists on server
• Upload Your Json schedule on openmrs schedule tracker from UI.
• Merge with your branch and run war file
• Should push all new schedules to OpenMRS or Log error in error-tracker module.
• NOTE: Old schedules would be ignored.

[sohelsarder]

Thanks for these hard works, I have some quick questions to reconfirm my understanding about the steps you asked to follow.

Download omod from link provided --- i can't download omod, i think you need to allow me permission there.
Upload OR Clean and reupload if already exists on server --- is this mean upload that omod file  into openmrs module directory to install that module.
Upload Your Json schedule on openmrs schedule tracker from UI.---- i think after 1&2 it will clear, just a quick check did you install that openmrs module in ona openmrs instance and i can quick check that UI?
Merge with your branch and run war file--- you mean merging with branch 81connectorExtend_mk?
Should push all new schedules to OpenMRS or Log error in error-tracker module.
NOTE: Old schedules would be ignored.

[maimoonak]

@sohelsarder

• I have re-configured sharing settings. It should be accessible now.
• Yes, it should be uploaded to OpenMRS as a module
• No, I have not uploaded it on Ona dev server yet. Once we merge it with master and have got BD team`s feedback it would be uploaded to dev server along with latest opensrp-web
• Yes, code is in this branch i.e 81connectorExtend_mk

[ndisha]

@sohelsarder, did you manage to install and test the schedules module? Have you done any end to end test from the OpenSRP client side? Any feedback?

@numeranazneen any observations on this?

[sohelsarder]

@ndisha We did not reach openmrs part yet, but we merged the changes and checking whether earlier functional part still working as well with modified forms and after merging of several changes from different branch.

[maimoonak]

84 Done!!