Discussion on OpenHIE Monitoring and Evaluation design

Hi,

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.

  2. 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 ?)

  2. 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

  3. 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,

Suranga

···


Best Regards,
Suranga

Thanks Suranga.

Please feel free to ask more about poirot and NewRelic; we’ll be glad to explain to whoever is appropriate in OHIE how these tools we have been using (not building) allows us to see how things are working in multi-service environments, maintain health server installations, etc…

I think Martin demo’d some stuff while he was still around. If NewRelic is an option you all want to look into I’d love to do introductions to explore CSR subsidies or pricing - we know the team well and it may be an excellent ROI for MOHs who don’t have large or mature IT teams and operations. We use a lot of advanced features but even without these they may find it beneficial.

~ ej

···

On Feb 6, 2014, at 2:13 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

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,

Suranga


Best Regards,
Suranga

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.

Hi,

Thanks Ed, I did have a good conversation with Mario on this matter.

Unfortunately, we couldn’t actually look at the NewRelic demo in action… i’m also interested in Poirot, which we may be able to use, at least in terms of learning how/what to do.

I’m definitely sure that RHIE would benefit from adopting NewRelic for their FR. Mario thinks that we may be able to use a free account, which is what i’m also rooting for. I will try to raise this matter with the RHIE team, and see their response.

On a separate tangent, it might be useful to find some time on a call, especially to discuss our boundaries/scope, as @Roger pointed out.

Best regards,

Suranga

···

On Thu, Feb 6, 2014 at 3:20 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Suranga.

Please feel free to ask more about poirot and NewRelic; we’ll be glad to explain to whoever is appropriate in OHIE how these tools we have been using (not building) allows us to see how things are working in multi-service environments, maintain health server installations, etc…

I think Martin demo’d some stuff while he was still around. If NewRelic is an option you all want to look into I’d love to do introductions to explore CSR subsidies or pricing - we know the team well and it may be an excellent ROI for MOHs who don’t have large or mature IT teams and operations. We use a lot of advanced features but even without these they may find it beneficial.

~ ej

On Feb 6, 2014, at 2:13 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

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,

Suranga


Best Regards,
Suranga

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.

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.


Best Regards,

Suranga

Hi all,

I do agree that the HIM could provide some common tools to view the health of the HIE. I don’t think that we would have to ship off entire log files but rather have the HIM allow messages to be audited and stored so that we can get a view into what information is travelling through the HIE and report on this information. Even some health checks to some of the services may be useful but perhaps this is the domain of a dedicated tool that monitors system health. I suppose this tool could be thought of as in the HIM ‘box’.

Cheers,

Ryan

···

On Fri, Feb 7, 2014 at 12:19 AM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

Thanks Ed, I did have a good conversation with Mario on this matter.

Unfortunately, we couldn’t actually look at the NewRelic demo in action… i’m also interested in Poirot, which we may be able to use, at least in terms of learning how/what to do.

I’m definitely sure that RHIE would benefit from adopting NewRelic for their FR. Mario thinks that we may be able to use a free account, which is what i’m also rooting for. I will try to raise this matter with the RHIE team, and see their response.

On a separate tangent, it might be useful to find some time on a call, especially to discuss our boundaries/scope, as @Roger pointed out.

Best regards,

Suranga

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.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

On Thu, Feb 6, 2014 at 3:20 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Suranga.

Please feel free to ask more about poirot and NewRelic; we’ll be glad to explain to whoever is appropriate in OHIE how these tools we have been using (not building) allows us to see how things are working in multi-service environments, maintain health server installations, etc…

I think Martin demo’d some stuff while he was still around. If NewRelic is an option you all want to look into I’d love to do introductions to explore CSR subsidies or pricing - we know the team well and it may be an excellent ROI for MOHs who don’t have large or mature IT teams and operations. We use a lot of advanced features but even without these they may find it beneficial.

~ ej

On Feb 6, 2014, at 2:13 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

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,

Suranga


Best Regards,
Suranga

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.

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.


Best Regards,

Suranga

This is a great conversation, to which I would offer a few thoughts.

Recall that there seems to be two distinct ends of the “monitoring” spectrum: at one end of the spectrum “monitoring” relates to tracking systems to ensure they’re functioning as expected (‘technical’ monitoring); the other end of the spectrum is “monitoring” as it pertains to “monitoring and evaluation” (“M&E”) - assessing the impact of systems on clinical and population health (‘clinical’ monitoring). These two senses of the word “monitoring” seem to have clear distinctions, even though they might use overlapping technologies or systems in some parts.

To make early and significant gains, I wonder if it would make sense to begin the “OpenHIE monitoring” discussions with well defined and limited initial scope. I would prefer we begin with an initial scope that focuses primarily on the first sense, “technical” monitoring of the system’s function rather than trying to also digest the more classical clinical M&E sense.

Does that sound like a reasonable way to begin this work?

Best,

Shaun

···

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Thu, Feb 6, 2014 at 5:19 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

Thanks Ed, I did have a good conversation with Mario on this matter.

Unfortunately, we couldn’t actually look at the NewRelic demo in action… i’m also interested in Poirot, which we may be able to use, at least in terms of learning how/what to do.

I’m definitely sure that RHIE would benefit from adopting NewRelic for their FR. Mario thinks that we may be able to use a free account, which is what i’m also rooting for. I will try to raise this matter with the RHIE team, and see their response.

On a separate tangent, it might be useful to find some time on a call, especially to discuss our boundaries/scope, as @Roger pointed out.

Best regards,

Suranga

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.

On Thu, Feb 6, 2014 at 3:20 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Suranga.

Please feel free to ask more about poirot and NewRelic; we’ll be glad to explain to whoever is appropriate in OHIE how these tools we have been using (not building) allows us to see how things are working in multi-service environments, maintain health server installations, etc…

I think Martin demo’d some stuff while he was still around. If NewRelic is an option you all want to look into I’d love to do introductions to explore CSR subsidies or pricing - we know the team well and it may be an excellent ROI for MOHs who don’t have large or mature IT teams and operations. We use a lot of advanced features but even without these they may find it beneficial.

~ ej

On Feb 6, 2014, at 2:13 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

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,

Suranga


Best Regards,
Suranga

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.

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.

Suranga


Best Regards,