Discussion on OpenHIE Monitoring and Evaluation design

Suranga, I have no idea what the discussion has been about, but I think the second bullet of M&E is out of the present scope. It would require an indicator metadata registry and an indicator data repository, as well as data exchange protocols. It would also require a certain amount of versioning within the CSD (for example, when facility hierarchies change).

At an earlier stage, I proposed, rather than store individual patient records in the shared medical record, that the patient records be passed through a chain of processors, each of which would be dedicated to extracting and storing the data necessary for that processor’s subject matter domain (e.g. HIV cases, malaria cases), producing case reports or aggregate reports; the final processor would archive the patient-level data. People did not seem particularly interested in this.

Saludos, Roger



During Wednesday’s session of the OpenHIE architecture meeting we were able to briefly discuss OpenHIE monitoring and evaluation methods.

Since a number of people were unable to attend this session, I thought that i’d list down our observations so that we could discuss / decide on a common path forward.

So basically,

  1. We need to determine boundaries for Monitoring and Evaluation, and what they represent.
  1. Monitoring and evaluation includes,
  • Server performance / up time (hardware / software issues)
  • Clinical evaluation (etc. number of HIV positive patients not receiving appropriate treatment)
  1. Standards base : Our approach should adhere to standards wherever possible (question: what standards are available/usable ?)
  1. Adaptability / re-usability (can we re-use ? Note : Can we re-use any of the monitoring tools Instedd already uses / is building for certain tasks ? etc. newRelic and Poirot
  1. Need to evaluate adherence to guideline based care

One of many potential solutions discussed were to centralize logging / monitoring for all components within the HIM. This implies that the results / log for what each transaction undergoes at each component is transferred back to the HIM, and stored there.

On the plus side, this makes debugging very easy because each transaction can be seen as a single unit. On the negative side, moving heavy logs back to the HIM requires even more bandwidth usage, which may not work well :slight_smile:

I just wanted to share this here and make some waves so that we could schedule some more time to discuss this at length later.

Best regards,


Best Regards,

-----Original Message-----

From: Suranga Kasthurirathne

Sent: Feb 6, 2014 2:13 PM

To: ohie-architecture@googlegroups.com

Subject: Discussion on OpenHIE Monitoring and Evaluation design

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.