generic "alerts" capability

[Roger_Friedman]

Apparently the listserv does not do attachments, see below

···

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

[Eduardo_Jezierski]

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

···

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

[Carl_Leitner1]

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

···

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

[Eduardo_Jezierski]

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

···

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

[Carl_Leitner1]

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

···

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

[ryan]

Hi all,

Just a quick comment. I agree on the general concept of alerting that have been presented here. However, I’m not sure an email server would be the best option for communicating with dispatch systems. I’d rather some sort of feed API be used. We could expose something like an ATOM feed (or a number of ATOM feeds) that represents an alert queue. Dispatch systems could query this feed for alerts they are interested in and send out alerts based on the contents. We could then decouple the central storage of alerts for the HIE from the systems (and therefore mechanisms) from which they are sent. It would be interesting to see if there are any other IHE profiles we could use for this instead however, I don’t know of any off-hand.

Cheers

Ryan

···

On Fri, May 23, 2014 at 3:16 PM, Carl Leitner litlfred@gmail.com wrote:

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

[Carl_Leitner1]

Hi Ryan,

I think there are two questions here that we are mixing: what are the internal (to the HIE) needs of messaging/alert system and what is exposed externally for various use cases, particularly the dispatch system. A lot of the discussion, has focused on the later, and not necessarily the former. A couple of questions to consider:

• do we have the need to archive the alerts?
• In particular, should client alerts end up in the SHR? If so what IHE standards would facilitate this (e.g. XDM)
• are there existing message alerting/queuing technologies that will scale nationally "as-is” and without requiring further software development?
• what type of content needs to be sent in an alert. we have mentioned SMS and voice. what about other enriched content such a letter documenting the need for a referral? what about a health worker taking a picture of a lesion and sending it along with a referral… In particular, will we need to create new mobile apps for HWs to create and submit alerts with enriched content?

Leveraging a mail-server as our “work-horse” does seem relatively robust and can speak readily to the above questions.

If we were to use something like a mail server under the hood, the IL could could create an ATOM facade, and achieve the decoupling. There are a fair number of google hits for integrating IMAP and ATOM (or RSS). For example:

https://apps.ubuntu.com/cat/applications/natty/feed2imap/

http://yard.ruby-doc.org/stdlib-2.1.0/Net/IMAP/Atom.html

In addition, Gmail also support various feeds of new messages:

https://developers.google.com/gmail/gmail_inbox_feed

BTW, if we did want to expose an ATOM feed for messages, we should really also have a way to publish that way as well. Does anyone have any direct experience with AtomPub?

http://bitworking.org/projects/atom/rfc5023.html

Cheers,
-carl

···

On Fri, May 23, 2014 at 3:16 PM, Carl Leitner litlfred@gmail.com wrote:

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

[bobj]

Carl I think you have a very good point here. I wouldn’t have warmed to it instantly, but on reflection I think a relatively simple MTA can (and has) addressed most of the decoupling, filtering and spooling challenges that we might face. And for all their arcaneness, the standards are really mature with a myriad of tools and gateways to be had.

(Of course if you really want to go down an alley, uucp was also a really good system for queueing, addressing and shunting of messages around which has a long and venerable history in Southern Africa where it proved really useful for those many environments which were very occasionally connected with very dodgy twisted pairs of copper and certainly couldn’t guarantee a kosher ip address for using tcp/ip and smtp. In fact I believe I could point to an effective ehealth usage for early warning alerting dating to the late eighties or early nineties)

Sadly - or perhaps not - uucp is no longer really with us, but I do agree - I think running postfix (or my preferred exim) along with something like dovecott as a local hie service would give you an impressive tool that can solve more problems out-of-the-box than I could care to imagine. And the chances are the IL box is probably running an MTA anyway to deal with internal sysadmin alerting. At least I always do on dhis boxes.

Just don’t use sendmail.

···

On 28 May 2014 17:01, Carl Leitner litlfred@gmail.com wrote:

Hi Ryan,

I think there are two questions here that we are mixing: what are the internal (to the HIE) needs of messaging/alert system and what is exposed externally for various use cases, particularly the dispatch system. A lot of the discussion, has focused on the later, and not necessarily the former. A couple of questions to consider:

• do we have the need to archive the alerts?
• In particular, should client alerts end up in the SHR? If so what IHE standards would facilitate this (e.g. XDM)
• are there existing message alerting/queuing technologies that will scale nationally "as-is” and without requiring further software development?
• what type of content needs to be sent in an alert. we have mentioned SMS and voice. what about other enriched content such a letter documenting the need for a referral? what about a health worker taking a picture of a lesion and sending it along with a referral… In particular, will we need to create new mobile apps for HWs to create and submit alerts with enriched content?

Leveraging a mail-server as our “work-horse” does seem relatively robust and can speak readily to the above questions.

If we were to use something like a mail server under the hood, the IL could could create an ATOM facade, and achieve the decoupling. There are a fair number of google hits for integrating IMAP and ATOM (or RSS). For example:

https://apps.ubuntu.com/cat/applications/natty/feed2imap/

http://yard.ruby-doc.org/stdlib-2.1.0/Net/IMAP/Atom.html

In addition, Gmail also support various feeds of new messages:

https://developers.google.com/gmail/gmail_inbox_feed

BTW, if we did want to expose an ATOM feed for messages, we should really also have a way to publish that way as well. Does anyone have any direct experience with AtomPub?

http://bitworking.org/projects/atom/rfc5023.html

Cheers,
-carl

On May 28, 2014, at 9:44 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

Just a quick comment. I agree on the general concept of alerting that have been presented here. However, I’m not sure an email server would be the best option for communicating with dispatch systems. I’d rather some sort of feed API be used. We could expose something like an ATOM feed (or a number of ATOM feeds) that represents an alert queue. Dispatch systems could query this feed for alerts they are interested in and send out alerts based on the contents. We could then decouple the central storage of alerts for the HIE from the systems (and therefore mechanisms) from which they are sent. It would be interesting to see if there are any other IHE profiles we could use for this instead however, I don’t know of any off-hand.

Cheers

Ryan

–

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/d/optout.

On Fri, May 23, 2014 at 3:16 PM, Carl Leitner litlfred@gmail.com wrote:

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

[Eduardo_Jezierski]

ATOM or RSS containers formats being relatively semantically equivalent, RSS is more of the lingua franca for alerting tools.

I personally also prefer the notion of distributed observer feeds obviously, you’ve seen me defend them all the time (where sources of alerts expose the alerts they expect to be sent, and then observers act on that state) but as was pointed out before in this thread, actively pushed messages (eg URL POSTs) play a stronger role in the field.

···

On Fri, May 23, 2014 at 3:16 PM, Carl Leitner litlfred@gmail.com wrote:

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

[Carl_Leitner1]

Hi Bob,

Just as an FYI, I ran across this issue with exim and load-balancing:

http://en.wikipedia.org/wiki/Exim#Performance

Cheers,
-carl

···

On 28 May 2014 17:01, Carl Leitner litlfred@gmail.com wrote:

Hi Ryan,

I think there are two questions here that we are mixing: what are the internal (to the HIE) needs of messaging/alert system and what is exposed externally for various use cases, particularly the dispatch system. A lot of the discussion, has focused on the later, and not necessarily the former. A couple of questions to consider:

• do we have the need to archive the alerts?
• In particular, should client alerts end up in the SHR? If so what IHE standards would facilitate this (e.g. XDM)
• are there existing message alerting/queuing technologies that will scale nationally "as-is” and without requiring further software development?
• what type of content needs to be sent in an alert. we have mentioned SMS and voice. what about other enriched content such a letter documenting the need for a referral? what about a health worker taking a picture of a lesion and sending it along with a referral… In particular, will we need to create new mobile apps for HWs to create and submit alerts with enriched content?

Leveraging a mail-server as our “work-horse” does seem relatively robust and can speak readily to the above questions.

If we were to use something like a mail server under the hood, the IL could could create an ATOM facade, and achieve the decoupling. There are a fair number of google hits for integrating IMAP and ATOM (or RSS). For example:

https://apps.ubuntu.com/cat/applications/natty/feed2imap/

http://yard.ruby-doc.org/stdlib-2.1.0/Net/IMAP/Atom.html

In addition, Gmail also support various feeds of new messages:

https://developers.google.com/gmail/gmail_inbox_feed

BTW, if we did want to expose an ATOM feed for messages, we should really also have a way to publish that way as well. Does anyone have any direct experience with AtomPub?

http://bitworking.org/projects/atom/rfc5023.html

Cheers,
-carl

On May 28, 2014, at 9:44 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

Just a quick comment. I agree on the general concept of alerting that have been presented here. However, I’m not sure an email server would be the best option for communicating with dispatch systems. I’d rather some sort of feed API be used. We could expose something like an ATOM feed (or a number of ATOM feeds) that represents an alert queue. Dispatch systems could query this feed for alerts they are interested in and send out alerts based on the contents. We could then decouple the central storage of alerts for the HIE from the systems (and therefore mechanisms) from which they are sent. It would be interesting to see if there are any other IHE profiles we could use for this instead however, I don’t know of any off-hand.

Cheers

Ryan

–

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/d/optout.

On Fri, May 23, 2014 at 3:16 PM, Carl Leitner litlfred@gmail.com wrote:

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

[bobj]

Could be. Possibly you were carrying enormous amounts of spam

Interesting from the same article “In January 2013 in a study performed by E-Soft, Inc.,^[2] approximately 48% of the publicly reachable mail-servers on the Internet ran Exim”.

My use of exim is simply a result of being brought up using “smail” because it’s configuration made much more sense to human beings than sendmail. And exim4 on FreeBSD was the MTA in use in the SA Gov Dept of Science and Technology. Ironically acting mostly as a filter/anti-virus gateway for the internal MS Exchange server. So you know the stuff you know

But I guess discussion on the merits and otherwise of different MTAs is a bit off topic. The central question is whether the system of internet mail with accompanying standards is a suitable base for meeting alerting requirements. I suspect it is. Of course there is always temptation to build something cooler with the likes of apache activemq, camel, mule even node.js etc etc.

Of course it might also be possible to describe alerting requirements and interfaces without the assumption of an underlying MTA, but still implemented that way. But the semantics of mail, addressing, attachments, gateways etc are so well understood that I think there is quite a lot to be gained by milking the mail metaphor more.

···

On 29 May 2014 13:29, Carl Leitner litlfred@gmail.com wrote:

Hi Bob,
Just as an FYI, I ran across this issue with exim and load-balancing:

http://en.wikipedia.org/wiki/Exim#Performance

Cheers,
-carl

On May 28, 2014, at 12:27 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Carl I think you have a very good point here. I wouldn’t have warmed to it instantly, but on reflection I think a relatively simple MTA can (and has) addressed most of the decoupling, filtering and spooling challenges that we might face. And for all their arcaneness, the standards are really mature with a myriad of tools and gateways to be had.

(Of course if you really want to go down an alley, uucp was also a really good system for queueing, addressing and shunting of messages around which has a long and venerable history in Southern Africa where it proved really useful for those many environments which were very occasionally connected with very dodgy twisted pairs of copper and certainly couldn’t guarantee a kosher ip address for using tcp/ip and smtp. In fact I believe I could point to an effective ehealth usage for early warning alerting dating to the late eighties or early nineties)

Sadly - or perhaps not - uucp is no longer really with us, but I do agree - I think running postfix (or my preferred exim) along with something like dovecott as a local hie service would give you an impressive tool that can solve more problems out-of-the-box than I could care to imagine. And the chances are the IL box is probably running an MTA anyway to deal with internal sysadmin alerting. At least I always do on dhis boxes.

Just don’t use sendmail.

–

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/d/optout.

On 28 May 2014 17:01, Carl Leitner litlfred@gmail.com wrote:

Hi Ryan,

I think there are two questions here that we are mixing: what are the internal (to the HIE) needs of messaging/alert system and what is exposed externally for various use cases, particularly the dispatch system. A lot of the discussion, has focused on the later, and not necessarily the former. A couple of questions to consider:

• do we have the need to archive the alerts?
• In particular, should client alerts end up in the SHR? If so what IHE standards would facilitate this (e.g. XDM)
• are there existing message alerting/queuing technologies that will scale nationally "as-is” and without requiring further software development?
• what type of content needs to be sent in an alert. we have mentioned SMS and voice. what about other enriched content such a letter documenting the need for a referral? what about a health worker taking a picture of a lesion and sending it along with a referral… In particular, will we need to create new mobile apps for HWs to create and submit alerts with enriched content?

Leveraging a mail-server as our “work-horse” does seem relatively robust and can speak readily to the above questions.

If we were to use something like a mail server under the hood, the IL could could create an ATOM facade, and achieve the decoupling. There are a fair number of google hits for integrating IMAP and ATOM (or RSS). For example:

https://apps.ubuntu.com/cat/applications/natty/feed2imap/

http://yard.ruby-doc.org/stdlib-2.1.0/Net/IMAP/Atom.html

In addition, Gmail also support various feeds of new messages:

https://developers.google.com/gmail/gmail_inbox_feed

BTW, if we did want to expose an ATOM feed for messages, we should really also have a way to publish that way as well. Does anyone have any direct experience with AtomPub?

http://bitworking.org/projects/atom/rfc5023.html

Cheers,
-carl

On May 28, 2014, at 9:44 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

Just a quick comment. I agree on the general concept of alerting that have been presented here. However, I’m not sure an email server would be the best option for communicating with dispatch systems. I’d rather some sort of feed API be used. We could expose something like an ATOM feed (or a number of ATOM feeds) that represents an alert queue. Dispatch systems could query this feed for alerts they are interested in and send out alerts based on the contents. We could then decouple the central storage of alerts for the HIE from the systems (and therefore mechanisms) from which they are sent. It would be interesting to see if there are any other IHE profiles we could use for this instead however, I don’t know of any off-hand.

Cheers

Ryan

–

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/d/optout.

On Fri, May 23, 2014 at 3:16 PM, Carl Leitner litlfred@gmail.com wrote:

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

[Carl_Leitner1]

Hi All,

Roger pointed out to me that I had subsumed Derek’s original definition of alerts (as being a messaged triggered by a state of the HIE and going HIE->client or HIE->health worker ) with more generic messaging (e.g. health worker->client, client->health worker, or health worker → health worker) where the trigger for the “alert" was human initiated.

Nevertheless, I think it would be good if both types of alert (HIE triggered vs human triggered) should use the same messaging backbone within the HIE. At least, I don’t see any good reason not too.

Under consideration for our messaging backbone should probably be the following use cases for a proposed pilot system for Ambulance dispatch

Key features of transportation dispatch system:

•  Real time data access: Record key information about transportation dispatched

•  Decision support system: Provide protocols to assist healthcare providers to determine level of risk of emergency case called into dispatch center; develop prompt for which health facility to refer patient

•  Payment disbursement: Disburse mobile money through MPesa to private transport providers in a transparent, traceable way

I think this hits on a lot of key pieces we are considering. I dug into this a bit more and came across these two standards for emergency alerts:

• Emergency Data Exchange Language (EDXL) http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf from Oasis

•                   IEEE 1512 -2000 Common Incident Management Message Sets for Use by Emergency Management Centers [http://grouper.ieee.org/groups/scc32/imwg/](http://grouper.ieee.org/groups/scc32/imwg/)
  

(The former is open access. The later is behind a pay-wall.) I took a brief look at EDXL and EDXL-DE and they look pretty interesting and are setup to work internationally. Take a look at "B.2 EDXL-DE With Multiple Encrypted Payloads”.

I am not saying that we need to necessarily provide explicit support for one of these standards, but I do think that our messaging system should be robust enough to eventually handle this without a major over-haul. Besides the use cases above an emergency alert system could be the appropriate method used to, for example, alert CHWs that there is an ebola outbreak in their district and provide updated diagnosis and care protocols.

In any case, I think that it would be really cool if OpenHIE were to enable the inclusion of CHWs and other front-line HWs in an emergency response system.

Cheers,
-carl

···

On 29 May 2014 13:29, Carl Leitner litlfred@gmail.com wrote:

Hi Bob,
Just as an FYI, I ran across this issue with exim and load-balancing:

http://en.wikipedia.org/wiki/Exim#Performance

Cheers,
-carl

On May 28, 2014, at 12:27 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Carl I think you have a very good point here. I wouldn’t have warmed to it instantly, but on reflection I think a relatively simple MTA can (and has) addressed most of the decoupling, filtering and spooling challenges that we might face. And for all their arcaneness, the standards are really mature with a myriad of tools and gateways to be had.

(Of course if you really want to go down an alley, uucp was also a really good system for queueing, addressing and shunting of messages around which has a long and venerable history in Southern Africa where it proved really useful for those many environments which were very occasionally connected with very dodgy twisted pairs of copper and certainly couldn’t guarantee a kosher ip address for using tcp/ip and smtp. In fact I believe I could point to an effective ehealth usage for early warning alerting dating to the late eighties or early nineties)

Sadly - or perhaps not - uucp is no longer really with us, but I do agree - I think running postfix (or my preferred exim) along with something like dovecott as a local hie service would give you an impressive tool that can solve more problems out-of-the-box than I could care to imagine. And the chances are the IL box is probably running an MTA anyway to deal with internal sysadmin alerting. At least I always do on dhis boxes.

Just don’t use sendmail.

–

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/d/optout.

On 28 May 2014 17:01, Carl Leitner litlfred@gmail.com wrote:

Hi Ryan,

I think there are two questions here that we are mixing: what are the internal (to the HIE) needs of messaging/alert system and what is exposed externally for various use cases, particularly the dispatch system. A lot of the discussion, has focused on the later, and not necessarily the former. A couple of questions to consider:

• do we have the need to archive the alerts?
• In particular, should client alerts end up in the SHR? If so what IHE standards would facilitate this (e.g. XDM)
• are there existing message alerting/queuing technologies that will scale nationally "as-is” and without requiring further software development?
• what type of content needs to be sent in an alert. we have mentioned SMS and voice. what about other enriched content such a letter documenting the need for a referral? what about a health worker taking a picture of a lesion and sending it along with a referral… In particular, will we need to create new mobile apps for HWs to create and submit alerts with enriched content?

Leveraging a mail-server as our “work-horse” does seem relatively robust and can speak readily to the above questions.

If we were to use something like a mail server under the hood, the IL could could create an ATOM facade, and achieve the decoupling. There are a fair number of google hits for integrating IMAP and ATOM (or RSS). For example:

https://apps.ubuntu.com/cat/applications/natty/feed2imap/

http://yard.ruby-doc.org/stdlib-2.1.0/Net/IMAP/Atom.html

In addition, Gmail also support various feeds of new messages:

https://developers.google.com/gmail/gmail_inbox_feed

BTW, if we did want to expose an ATOM feed for messages, we should really also have a way to publish that way as well. Does anyone have any direct experience with AtomPub?

http://bitworking.org/projects/atom/rfc5023.html

Cheers,
-carl

On May 28, 2014, at 9:44 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

Just a quick comment. I agree on the general concept of alerting that have been presented here. However, I’m not sure an email server would be the best option for communicating with dispatch systems. I’d rather some sort of feed API be used. We could expose something like an ATOM feed (or a number of ATOM feeds) that represents an alert queue. Dispatch systems could query this feed for alerts they are interested in and send out alerts based on the contents. We could then decouple the central storage of alerts for the HIE from the systems (and therefore mechanisms) from which they are sent. It would be interesting to see if there are any other IHE profiles we could use for this instead however, I don’t know of any off-hand.

Cheers

Ryan

–

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/d/optout.

On Fri, May 23, 2014 at 3:16 PM, Carl Leitner litlfred@gmail.com wrote:

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

[Carl_Leitner1]

Picking up this conversation again, I found the following report on the interplay of emergency response within an IHE from ONC quite interesting:

http://www.healthit.gov/sites/default/files/hiefordisasterresponse_final_04232014.pdf

Several IHE profiles are mentioned.
Cheers,
-carl

···

On 29 May 2014 13:29, Carl Leitner litlfred@gmail.com wrote:

Hi Bob,
Just as an FYI, I ran across this issue with exim and load-balancing:

http://en.wikipedia.org/wiki/Exim#Performance

Cheers,
-carl

On May 28, 2014, at 12:27 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Carl I think you have a very good point here. I wouldn’t have warmed to it instantly, but on reflection I think a relatively simple MTA can (and has) addressed most of the decoupling, filtering and spooling challenges that we might face. And for all their arcaneness, the standards are really mature with a myriad of tools and gateways to be had.

(Of course if you really want to go down an alley, uucp was also a really good system for queueing, addressing and shunting of messages around which has a long and venerable history in Southern Africa where it proved really useful for those many environments which were very occasionally connected with very dodgy twisted pairs of copper and certainly couldn’t guarantee a kosher ip address for using tcp/ip and smtp. In fact I believe I could point to an effective ehealth usage for early warning alerting dating to the late eighties or early nineties)

Sadly - or perhaps not - uucp is no longer really with us, but I do agree - I think running postfix (or my preferred exim) along with something like dovecott as a local hie service would give you an impressive tool that can solve more problems out-of-the-box than I could care to imagine. And the chances are the IL box is probably running an MTA anyway to deal with internal sysadmin alerting. At least I always do on dhis boxes.

Just don’t use sendmail.

–

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/d/optout.

On 28 May 2014 17:01, Carl Leitner litlfred@gmail.com wrote:

Hi Ryan,

I think there are two questions here that we are mixing: what are the internal (to the HIE) needs of messaging/alert system and what is exposed externally for various use cases, particularly the dispatch system. A lot of the discussion, has focused on the later, and not necessarily the former. A couple of questions to consider:

• do we have the need to archive the alerts?
• In particular, should client alerts end up in the SHR? If so what IHE standards would facilitate this (e.g. XDM)
• are there existing message alerting/queuing technologies that will scale nationally "as-is” and without requiring further software development?
• what type of content needs to be sent in an alert. we have mentioned SMS and voice. what about other enriched content such a letter documenting the need for a referral? what about a health worker taking a picture of a lesion and sending it along with a referral… In particular, will we need to create new mobile apps for HWs to create and submit alerts with enriched content?

Leveraging a mail-server as our “work-horse” does seem relatively robust and can speak readily to the above questions.

If we were to use something like a mail server under the hood, the IL could could create an ATOM facade, and achieve the decoupling. There are a fair number of google hits for integrating IMAP and ATOM (or RSS). For example:

https://apps.ubuntu.com/cat/applications/natty/feed2imap/

http://yard.ruby-doc.org/stdlib-2.1.0/Net/IMAP/Atom.html

In addition, Gmail also support various feeds of new messages:

https://developers.google.com/gmail/gmail_inbox_feed

BTW, if we did want to expose an ATOM feed for messages, we should really also have a way to publish that way as well. Does anyone have any direct experience with AtomPub?

http://bitworking.org/projects/atom/rfc5023.html

Cheers,
-carl

On May 28, 2014, at 9:44 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

Just a quick comment. I agree on the general concept of alerting that have been presented here. However, I’m not sure an email server would be the best option for communicating with dispatch systems. I’d rather some sort of feed API be used. We could expose something like an ATOM feed (or a number of ATOM feeds) that represents an alert queue. Dispatch systems could query this feed for alerts they are interested in and send out alerts based on the contents. We could then decouple the central storage of alerts for the HIE from the systems (and therefore mechanisms) from which they are sent. It would be interesting to see if there are any other IHE profiles we could use for this instead however, I don’t know of any off-hand.

Cheers

Ryan

–

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/d/optout.

On Fri, May 23, 2014 at 3:16 PM, Carl Leitner litlfred@gmail.com wrote:

Hi Ed,
(Sorry I missed the bit in your email about voice. Glad we are thinking along the same lines.) What I was suggesting would largely play part of the role of DISPATCH as well as how GENERATE would communicate its output.

Can you post some links to the standards used to hook up the disparate systems. It would be great if we all could look at them and evaluate them together.

Can you talk a bit about the “many proven reasons”? As I am not an expert in this area, I am not sure what you have in mind, but presumably they were technical considerations. As we are considering different architectures (and technology stacks) it would be good if we could evaluate them against the same criteria. If you could share these, that would be great.

The primary criteria that I know of for any part of the OpenHIE, and discussed in the Indy meeting, was roughly:

• are there any existing standards to meet the use cases?
• are there existing open-source and deployable solutions that adhere to these standards

So, to answer your main question:

What requirements would be met better this way?

I am not asserting that an email server is the better/best way (beside the ones I mentioned above we have not yet determined any other criteria evaluation). Instead, I was offering an alternative that meets the above two criteria that we have collectively established. I offered this as an option as it seemed to me that by An appropriate service for this can expose a uniform API”, you were indicating a custom/home-grown API. If I am mistaken, and you were there is a standard API you were thinking of here, can you please send some links/documentation.

To be a bit more precise on what I was intending, here are the standards I think we can exploit:

• IMF (rfc 5322) for the structure of the message.
• SMTP (rfc 5321) for message dispatching. Note that as we scale, there are several MTAs (e.g. sendmail and postfix) that can load-balance. May also want to look at LMTP (rfc 2033).
• IMAP/IMAPS (rfc 3501). could be useful if we want to enable a pull mechanism against the queued messages.
• XDM - an IHE profile about cross-enterprise media exchange including via SMTP. This could handle voice, referral letters and the such. Although it may seem a bit top heavy for simple SMS, I think it is still worth looking at, and this could be mitigated by the IL and a custom API or the standards compliant use of an X- header in the mail message. Thinking out load, an alternative here is to allow several email address per provider (or client) at differing domains — one domain to send SMS messages, one to send voice messages, etc.

In addition to standards, the open-source technology stacks to implement these are ubiquitous, readily swappable, highly dependable and certainly deployable in LMICs. Going this route, the amount of new technology we need to develop is quite minimal or even non-existent.

Again, not saying an email based solution is the best solution — I would like to see other proposals. However, it does meet to of the primary considerations I know of for the architecture.

Cheers,
-carl

PS. I never intended to say we needed SOAP over SMTP. The direct project link speaks about some broader considerations in the use of SOAP in other IHE profiles.

On May 22, 2014, at 11:13 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for the suggestions -

Agree we need to make sure “smsifying” an alert architecture discussion doesn’t happen; I wastrying to raise (and address) the same concern in my email.

The architecture I mentioned considers the gamut of messaging options regardless of format including voice, SMS, USSD, email, twitter, and even chat protocols like XMPP (Jabber /“Google chat”), MSN messenger - all of these fulfill goals that can be relevant to LMICs.

There are standards that are used all the time to hook up disparate systems that never saw each other in this problem space- why not use those instead of making one up?

There’s many proven reasons why specifically email is not used in these scenarios; why SOAP over SMTP (which resembles more what I sense you are suggesting) is not a killer queuing transport etc. What requirements would be met better this way? What evidence exists that it has been better to do that?

~ ej

On May 22, 2014, at 5:44 AM, Carl Leitner litlfred@gmail.com wrote:

Hi All,
So far, our discussion about alerts have been largely driven by SMS use cases. Agreeing that this is our primary use case, at the moment, I think we need to ensure that whatever system that we put in place is robust enough to withstand future use cases. In particular where more robust content would need to be sent. Essentially, I think we need to consider a more “document-centric” viewpoint for our messaging/alert system.

There have been a few proposal put forward, and one common feature seems to be the need to have someone type of message queue associated to an individual. Here is perhaps a naive suggestion: why not simply set up an internal email server for the HIE within which there is an email address associated to each client and provider based on something like their enterprise ID.

If you wish to queue an SMS to send to someone, then you can send an email with a header like

X-OHIE-SMS: Content of SMS Message

Here is an example of integrating postfix with an SMS gateway:

http://tools.rebel-it.com.au/sms-transport/

(not saying this is the solution, just that it can be done)

The “Alert Generator” actors (after resolving the email address to use via the IL) would then simply send an email message with appropriate headers to in mail server.

If there are things that need to support for the likes of "referral?patient =2345&clinic=789”, then it would be the responsibility of IL to make the translation to an email message.

I don’t what the implications here would be in relation to XDR but I saw this:

http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version

I am sure someone on this list would be better than me to comment on this.

My question is: what use cases under consideration for alerting could not be represented in the above (or similar) setup?

Cheers,
-carl

On May 21, 2014, at 4:22 PM, Eduardo Jezierski edjez@instedd.org wrote:

I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs

First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:

1. REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them

2. GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.

In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.

Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.

Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.

The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)

3. DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.

#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)

As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.

I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,

We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.

Will send an update soon with a diagram to illustrate it better-

~ ej

On May 21, 2014, at 9:37 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:

Apparently the listserv does not do attachments, see below

The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.

Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).

At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.

–

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/d/optout.

–

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/d/optout.

–

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/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org