RapidSMS...

[Paul Biondich-2]

Andy and/or other colleagues,

I am looking for development lead contacts at RapidSMS.  Whom should I  
speak with?  Any ideas?

-Paul

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Andrew Kanter]

Paul,

You should talk to Matt Berg at Columbia... he is heading up the modifications we are making to the RapidSMS core for UNICEF. Are you interested in a technical contact or a political one ;)?

Andy
 --------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: Paul Biondich <[hidden email]>
To: [hidden email]
Sent: Mon, November 2, 2009 4:49:37 PM
Subject: [OPENMRS-DEV] RapidSMS...

Andy and/or other colleagues,

I am looking for development lead contacts at RapidSMS.  Whom should I speak with?  Any ideas?

-Paul

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Paul Biondich-2]

Hi, thanks for this... what is his email address?

I should have given more background... the need is arising on multiple  
fronts to support interfaces with SMS / telephony applications within  
OpenMRS and I want to pre-empt what might end up being fractured work  
by encouraging an open dialogue with stakeholder groups like  
FrontlineSMS and RapidSMS to consider agreeing on a standard interface  
protocol for interaction with OpenMRS vs. multiple adhoc interfaces.

Hope this makes sense... figured since you as well as others have  
committed at some level to RapidSMS that we consider them.

In short, I remembered our conversation... ;)

-Paul

On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:

> Paul,
>
> You should talk to Matt Berg at Columbia... he is heading up the  
> modifications we are making to the RapidSMS core for UNICEF. Are you  
> interested in a technical contact or a political one ;)?
>
> Andy
> --------------------
> Andrew S. Kanter, MD MPH
>
>
> - Director of Health Information Systems/Medical Informatics
> Millennium Villages Project, Earth Institute, Columbia University
> - Asst. Prof. of Clinical Biomedical Informatics and Clinical  
> Epidemiology
> Columbia University
>
>
> Email: [hidden email]
> Mobile: [phone]
> Office: [phone]
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
>
> ----- Original Message ----
> From: Paul Biondich <[hidden email]>
> To: [hidden email]
> Sent: Mon, November 2, 2009 4:49:37 PM
> Subject: [OPENMRS-DEV] RapidSMS...
>
> Andy and/or other colleagues,
>
> I am looking for development lead contacts at RapidSMS.  Whom should  
> I speak with?  Any ideas?
>
> -Paul
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Carl Fourie]

Some javascript/style in this post has been disabled (why?)

Hi Paul,

I can also suggest Kieran Sharpey-Schafer [hidden email] from Cell-life here in Cape Town. He was at the OpenMRS Meeting and has been interested in connecting mobile to OpenMRS for a while. He has been working on the OpenROSA project and may provide a good entry into the mobile community if needed.

Cheers,
Carl

Paul Biondich wrote:

Hi, thanks for this... what is his email address?

I should have given more background... the need is arising on multiple fronts to support interfaces with SMS / telephony applications within OpenMRS and I want to pre-empt what might end up being fractured work by encouraging an open dialogue with stakeholder groups like FrontlineSMS and RapidSMS to consider agreeing on a standard interface protocol for interaction with OpenMRS vs. multiple adhoc interfaces.

Hope this makes sense... figured since you as well as others have committed at some level to RapidSMS that we consider them.

In short, I remembered our conversation... ;)

-Paul

On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:

Paul,

You should talk to Matt Berg at Columbia... he is heading up the modifications we are making to the RapidSMS core for UNICEF. Are you interested in a technical contact or a political one ;)?

Andy
--------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: Paul Biondich [hidden email]
To: [hidden email]
Sent: Mon, November 2, 2009 4:49:37 PM
Subject: [OPENMRS-DEV] RapidSMS...

Andy and/or other colleagues,

I am looking for development lead contacts at RapidSMS.  Whom should I speak with?  Any ideas?

-Paul

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[[hidden email]]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[[hidden email]]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[[hidden email]]

---

[hidden email] from OpenMRS Developers' mailing list

[Andrew Kanter]

Paul,
I will let Matt respond himself, but I believe the current MVP intent is to continue to use the Xforms module as the way in to OpenMRS by creating a wrapper around the SMS. I know the module can accept some strictly formatted SMS messages but we envision a more robust two way API. I think this should be considered by others as well. One thing raised by this interface is the need for a shorter patient code which can be used instead of longer patient IDs typical for EMRs. We'd like to have OpenMRS autogenerate a short code (hex for example) which could be used by SMS messages more easily. Daniel's code does allow patients to be searched and downloaded, but when creating a message from scratch, shorter ids are better...

Andy

 --------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: Paul Biondich <[hidden email]>
To: [hidden email]
Sent: Mon, November 2, 2009 8:02:07 PM
Subject: Re: [OPENMRS-DEV] RapidSMS...

Hi, thanks for this... what is his email address?

I should have given more background... the need is arising on multiple fronts to support interfaces with SMS / telephony applications within OpenMRS and I want to pre-empt what might end up being fractured work by encouraging an open dialogue with stakeholder groups like FrontlineSMS and RapidSMS to consider agreeing on a standard interface protocol for interaction with OpenMRS vs. multiple adhoc interfaces.

Hope this makes sense... figured since you as well as others have committed at some level to RapidSMS that we consider them.

In short, I remembered our conversation... ;)

-Paul

On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:

> Paul,
>
> You should talk to Matt Berg at Columbia... he is heading up the modifications we are making to the RapidSMS core for UNICEF. Are you interested in a technical contact or a political one ;)?
>
> Andy
> --------------------
> Andrew S. Kanter, MD MPH
>
>
> - Director of Health Information Systems/Medical Informatics
> Millennium Villages Project, Earth Institute, Columbia University
> - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
> Columbia University
>
>
> Email: [hidden email]
> Mobile: [phone]
> Office: [phone]
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
>
> ----- Original Message ----
> From: Paul Biondich <[hidden email]>
> To: [hidden email]
> Sent: Mon, November 2, 2009 4:49:37 PM
> Subject: [OPENMRS-DEV] RapidSMS...
>
> Andy and/or other colleagues,
>
> I am looking for development lead contacts at RapidSMS.  Whom should I speak with?  Any ideas?
>
> -Paul
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Paul Biondich-2]

I'll look forward to hearing from Matt, but just a point of  
clarification while we wait:

So, imagine the use case where we might want an OpenMRS instance to  
send out a single SMS alert to a patient.  Would you imagine sending  
that SMS to RapidSMS at this point with an XForm?

-Paul

On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:

> Paul,
> I will let Matt respond himself, but I believe the current MVP  
> intent is to continue to use the Xforms module as the way in to  
> OpenMRS by creating a wrapper around the SMS. I know the module can  
> accept some strictly formatted SMS messages but we envision a more  
> robust two way API. I think this should be considered by others as  
> well. One thing raised by this interface is the need for a shorter  
> patient code which can be used instead of longer patient IDs typical  
> for EMRs. We'd like to have OpenMRS autogenerate a short code (hex  
> for example) which could be used by SMS messages more easily.  
> Daniel's code does allow patients to be searched and downloaded, but  
> when creating a message from scratch, shorter ids are better...
>
> Andy
>
> --------------------
> Andrew S. Kanter, MD MPH
>
>
> - Director of Health Information Systems/Medical Informatics
> Millennium Villages Project, Earth Institute, Columbia University
> - Asst. Prof. of Clinical Biomedical Informatics and Clinical  
> Epidemiology
> Columbia University
>
>
> Email: [hidden email]
> Mobile: [phone]
> Office: [phone]
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
>
> ----- Original Message ----
> From: Paul Biondich <[hidden email]>
> To: [hidden email]
> Sent: Mon, November 2, 2009 8:02:07 PM
> Subject: Re: [OPENMRS-DEV] RapidSMS...
>
> Hi, thanks for this... what is his email address?
>
> I should have given more background... the need is arising on  
> multiple fronts to support interfaces with SMS / telephony  
> applications within OpenMRS and I want to pre-empt what might end up  
> being fractured work by encouraging an open dialogue with  
> stakeholder groups like FrontlineSMS and RapidSMS to consider  
> agreeing on a standard interface protocol for interaction with  
> OpenMRS vs. multiple adhoc interfaces.
>
> Hope this makes sense... figured since you as well as others have  
> committed at some level to RapidSMS that we consider them.
>
> In short, I remembered our conversation... ;)
>
> -Paul
>
> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>
>> Paul,
>>
>> You should talk to Matt Berg at Columbia... he is heading up the  
>> modifications we are making to the RapidSMS core for UNICEF. Are  
>> you interested in a technical contact or a political one ;)?
>>
>> Andy
>> --------------------
>> Andrew S. Kanter, MD MPH
>>
>>
>> - Director of Health Information Systems/Medical Informatics
>> Millennium Villages Project, Earth Institute, Columbia University
>> - Asst. Prof. of Clinical Biomedical Informatics and Clinical  
>> Epidemiology
>> Columbia University
>>
>>
>> Email: [hidden email]
>> Mobile: [phone]
>> Office: [phone]
>> Skype: akanter-ippnw
>> Yahoo: andy_kanter
>>
>>
>>
>> ----- Original Message ----
>> From: Paul Biondich <[hidden email]>
>> To: [hidden email]
>> Sent: Mon, November 2, 2009 4:49:37 PM
>> Subject: [OPENMRS-DEV] RapidSMS...
>>
>> Andy and/or other colleagues,
>>
>> I am looking for development lead contacts at RapidSMS.  Whom  
>> should I speak with?  Any ideas?
>>
>> -Paul
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-
>> mail to [hidden email] with "SIGNOFF openmrs-devel-l"  
>> in the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-
>> mail to [hidden email] with "SIGNOFF openmrs-devel-l"  
>> in the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Ime Asangansi]

A couple of months ago Kieran pointed me to Mobilisr - whic
Yes, Carl!

A couple of months ago Kieran pointed me to Mobilisr - which is an attractive option as it is java web as OpenMRS and DHIS are. (Being enterprise Java surely gives an advantage in this regard)

I've been looking at two-way integration with OpenMRS and DHIS, and have been discussing how to join efforts with Vikram Bindal who will be migrating it from JDBC to hibernate pretty soon.

See more on Mobilisr at:
http://www.open-mobile.org/technologies/mobilisr-enterprise-open-source-mobile-messaging
http://www.mobilisr.org/

I'm keen to discuss further on this as we are looking at integrating all these into our current mobile solutions.
...and also with the cool SMS features that are currently in the xforms module

(Vikram, any response?)

Cheers,
Ime Asangansi


--- On Tue, 11/3/09, Carl Fourie <[hidden email]> wrote:

> Hi Paul,
>
> I can also suggest Kieran Sharpey-Schafer
> <[hidden email]>
> from Cell-life here in Cape Town. He
> was at the OpenMRS Meeting and has been interested in
> connecting mobile
> to OpenMRS for a while. He has been working on the OpenROSA
> project and
> may provide a good entry into the mobile community if
> needed.
>
>
>
> Cheers,
>
> Carl
>
>
>
> Paul Biondich wrote:
> Hi, thanks for this... what is his email
> address?
>  
>
>  
>
> I should have given more background... the need is arising
> on multiple
> fronts to support interfaces with SMS / telephony
> applications within
> OpenMRS and I want to pre-empt what might end up being
> fractured work
> by encouraging an open dialogue with stakeholder groups
> like
> FrontlineSMS and RapidSMS to consider agreeing on a
> standard interface
> protocol for interaction with OpenMRS vs. multiple adhoc
> interfaces.
>  
>
>  
>
> Hope this makes sense... figured since you as well as
> others have
> committed at some level to RapidSMS that we consider them.
>  
>
>  
>
> In short, I remembered our conversation... ;)
>  
>
>  
>
> -Paul
>  
>
>  
>
> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>  
>
>  
>
>   Paul,
>    
>
>    
>
> You should talk to Matt Berg at Columbia... he is heading
> up the
> modifications we are making to the RapidSMS core for
> UNICEF. Are you
> interested in a technical contact or a political one ;)?
>    
>
>    
>
> Andy
>    
>
> --------------------
>    
>
> Andrew S. Kanter, MD MPH
>    
>
>    
>
>    
>
> - Director of Health Information Systems/Medical
> Informatics
>    
>
> Millennium Villages Project, Earth Institute, Columbia
> University
>    
>
> - Asst. Prof. of Clinical Biomedical Informatics and
> Clinical
> Epidemiology
>    
>
> Columbia University
>    
>
>    
>
>    
>
> Email: [hidden email]
>    
>
> Mobile: [phone]
>    
>
> Office: [phone]
>    
>
> Skype: akanter-ippnw
>    
>
> Yahoo: andy_kanter
>    
>
>    
>
>    
>
>    
>
> ----- Original Message ----
>    
>
> From: Paul Biondich <[hidden email]>
>    
>
> To: [hidden email]
>    
>
> Sent: Mon, November 2, 2009 4:49:37 PM
>    
>
> Subject: [OPENMRS-DEV] RapidSMS...
>    
>
>    
>
> Andy and/or other colleagues,
>    
>
>    
>
> I am looking for development lead contacts at
> RapidSMS.  Whom should I
> speak with?  Any ideas?
>    
>
>    
>
> -Paul
>    
>
>    
>
> _________________________________________
>    
>
>    
>
> To unsubscribe from OpenMRS Developers' mailing list,
> send an e-mail to
> [hidden email]
> with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>    
>
>    
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>    
>
>    
>
> _________________________________________
>    
>
>    
>
> To unsubscribe from OpenMRS Developers' mailing list,
> send an e-mail to
> [hidden email]
> with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>    
>
>    
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>    
>
>  
>  
>
> _________________________________________
>  
>
>  
>
> To unsubscribe from OpenMRS Developers' mailing list,
> send an e-mail to
> [hidden email]
> with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>  
>
>  
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>  
>
>  
>
>
>
>
> --
>
>
> Carl Fourie
>
> Jembi-General Manager,
>
>
>
> website:  http://www.jembi.org
>
> e-mail:   [hidden email]
>
> Skype:    carl.fourie17
>
> cell:        +27 (0)71
> 540 4477
>
>
>
>
>
>  
>
>
>
> Click
> here to unsubscribe from OpenMRS Developers' mailing
> list
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Daniel Kayiwa]

The xforms module sms functionality is only a way for filling forms.
It is a one way route, where the sms is parsed and used to fill an existing xform.

So it does not do things like alerts, etc

On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email]> wrote:

I'll look forward to hearing from Matt, but just a point of clarification while we wait:

So, imagine the use case where we might want an OpenMRS instance to send out a single SMS alert to a patient.  Would you imagine sending that SMS to RapidSMS at this point with an XForm?

-Paul

On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:

Paul,
I will let Matt respond himself, but I believe the current MVP intent is to continue to use the Xforms module as the way in to OpenMRS by creating a wrapper around the SMS. I know the module can accept some strictly formatted SMS messages but we envision a more robust two way API. I think this should be considered by others as well. One thing raised by this interface is the need for a shorter patient code which can be used instead of longer patient IDs typical for EMRs. We'd like to have OpenMRS autogenerate a short code (hex for example) which could be used by SMS messages more easily. Daniel's code does allow patients to be searched and downloaded, but when creating a message from scratch, shorter ids are better...

Andy

--------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: Paul Biondich <[hidden email]>
To: [hidden email]
Sent: Mon, November 2, 2009 8:02:07 PM
Subject: Re: [OPENMRS-DEV] RapidSMS...

Hi, thanks for this... what is his email address?

I should have given more background... the need is arising on multiple fronts to support interfaces with SMS / telephony applications within OpenMRS and I want to pre-empt what might end up being fractured work by encouraging an open dialogue with stakeholder groups like FrontlineSMS and RapidSMS to consider agreeing on a standard interface protocol for interaction with OpenMRS vs. multiple adhoc interfaces.

Hope this makes sense... figured since you as well as others have committed at some level to RapidSMS that we consider them.

In short, I remembered our conversation... ;)

-Paul

On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:

Paul,

You should talk to Matt Berg at Columbia... he is heading up the modifications we are making to the RapidSMS core for UNICEF. Are you interested in a technical contact or a political one ;)?

Andy
--------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: Paul Biondich <[hidden email]>
To: [hidden email]
Sent: Mon, November 2, 2009 4:49:37 PM
Subject: [OPENMRS-DEV] RapidSMS...

Andy and/or other colleagues,

I am looking for development lead contacts at RapidSMS.  Whom should I speak with?  Any ideas?

-Paul

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

---

[hidden email] from OpenMRS Developers' mailing list

[sunbiz]

I do feel that using another application (RapidSMS) for sending alert for a single patient, is an overkill... A simplistic module in OpenMRS should be able to do this...

I agree a standard way to do it and aligning forces is a good thing to do, but for the above mentioned use-case, sounds like an overkill.

---
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

2009/11/3 Daniel Kayiwa <[hidden email]>

The xforms module sms functionality is only a way for filling forms.
It is a one way route, where the sms is parsed and used to fill an existing xform.

So it does not do things like alerts, etc

On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email]> wrote:

I'll look forward to hearing from Matt, but just a point of clarification while we wait:

So, imagine the use case where we might want an OpenMRS instance to send out a single SMS alert to a patient.  Would you imagine sending that SMS to RapidSMS at this point with an XForm?

-Paul

On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:

Paul,
I will let Matt respond himself, but I believe the current MVP intent is to continue to use the Xforms module as the way in to OpenMRS by creating a wrapper around the SMS. I know the module can accept some strictly formatted SMS messages but we envision a more robust two way API. I think this should be considered by others as well. One thing raised by this interface is the need for a shorter patient code which can be used instead of longer patient IDs typical for EMRs. We'd like to have OpenMRS autogenerate a short code (hex for example) which could be used by SMS messages more easily. Daniel's code does allow patients to be searched and downloaded, but when creating a message from scratch, shorter ids are better...

Andy

--------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: Paul Biondich <[hidden email]>
To: [hidden email]
Sent: Mon, November 2, 2009 8:02:07 PM
Subject: Re: [OPENMRS-DEV] RapidSMS...

Hi, thanks for this... what is his email address?

I should have given more background... the need is arising on multiple fronts to support interfaces with SMS / telephony applications within OpenMRS and I want to pre-empt what might end up being fractured work by encouraging an open dialogue with stakeholder groups like FrontlineSMS and RapidSMS to consider agreeing on a standard interface protocol for interaction with OpenMRS vs. multiple adhoc interfaces.

Hope this makes sense... figured since you as well as others have committed at some level to RapidSMS that we consider them.

In short, I remembered our conversation... ;)

-Paul

On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:

Paul,

You should talk to Matt Berg at Columbia... he is heading up the modifications we are making to the RapidSMS core for UNICEF. Are you interested in a technical contact or a political one ;)?

Andy
--------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: Paul Biondich <[hidden email]>
To: [hidden email]
Sent: Mon, November 2, 2009 4:49:37 PM
Subject: [OPENMRS-DEV] RapidSMS...

Andy and/or other colleagues,

I am looking for development lead contacts at RapidSMS.  Whom should I speak with?  Any ideas?

-Paul

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Andrew Kanter]

Paul,
I don't think that sending out a single alert via SMS needs to go through RapidSMS... however, there are a lot of workflow issues which group messaging and tasking through RapidSMS makes sense. The important points will be to identify the specific use cases, functionality gaps and development requirements to complete the circle. MVP will be rolling out an integrated Community Health Worker information system which flows through OpenMRS into other systems (such as DHIS, etc.). I think the ecosystem of solutions including SMS, CommCare/OpenROSA, ODK, etc. is starting to come together... but the actual use cases will be dictated by partners such as PIH and MVP which need to roll-out scalable and sustainable systems across multiple locations...

Perhaps this should also be discussed at AMIA?

-Andy
 --------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: Paul Biondich <[hidden email]>
To: [hidden email]
Sent: Tue, November 3, 2009 8:59:23 AM
Subject: Re: [OPENMRS-DEV] RapidSMS...

I'll look forward to hearing from Matt, but just a point of clarification while we wait:

So, imagine the use case where we might want an OpenMRS instance to send out a single SMS alert to a patient.  Would you imagine sending that SMS to RapidSMS at this point with an XForm?

-Paul

On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:

> Paul,
> I will let Matt respond himself, but I believe the current MVP intent is to continue to use the Xforms module as the way in to OpenMRS by creating a wrapper around the SMS. I know the module can accept some strictly formatted SMS messages but we envision a more robust two way API. I think this should be considered by others as well. One thing raised by this interface is the need for a shorter patient code which can be used instead of longer patient IDs typical for EMRs. We'd like to have OpenMRS autogenerate a short code (hex for example) which could be used by SMS messages more easily. Daniel's code does allow patients to be searched and downloaded, but when creating a message from scratch, shorter ids are better...
>
> Andy
>
> --------------------
> Andrew S. Kanter, MD MPH
>
>
> - Director of Health Information Systems/Medical Informatics
> Millennium Villages Project, Earth Institute, Columbia University
> - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
> Columbia University
>
>
> Email: [hidden email]
> Mobile: [phone]
> Office: [phone]
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
>
> ----- Original Message ----
> From: Paul Biondich <[hidden email]>
> To: [hidden email]
> Sent: Mon, November 2, 2009 8:02:07 PM
> Subject: Re: [OPENMRS-DEV] RapidSMS...
>
> Hi, thanks for this... what is his email address?
>
> I should have given more background... the need is arising on multiple fronts to support interfaces with SMS / telephony applications within OpenMRS and I want to pre-empt what might end up being fractured work by encouraging an open dialogue with stakeholder groups like FrontlineSMS and RapidSMS to consider agreeing on a standard interface protocol for interaction with OpenMRS vs. multiple adhoc interfaces.
>
> Hope this makes sense... figured since you as well as others have committed at some level to RapidSMS that we consider them.
>
> In short, I remembered our conversation... ;)
>
> -Paul
>
> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>
>> Paul,
>>
>> You should talk to Matt Berg at Columbia... he is heading up the modifications we are making to the RapidSMS core for UNICEF. Are you interested in a technical contact or a political one ;)?
>>
>> Andy
>> --------------------
>> Andrew S. Kanter, MD MPH
>>
>>
>> - Director of Health Information Systems/Medical Informatics
>> Millennium Villages Project, Earth Institute, Columbia University
>> - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
>> Columbia University
>>
>>
>> Email: [hidden email]
>> Mobile: [phone]
>> Office: [phone]
>> Skype: akanter-ippnw
>> Yahoo: andy_kanter
>>
>>
>>
>> ----- Original Message ----
>> From: Paul Biondich <[hidden email]>
>> To: [hidden email]
>> Sent: Mon, November 2, 2009 4:49:37 PM
>> Subject: [OPENMRS-DEV] RapidSMS...
>>
>> Andy and/or other colleagues,
>>
>> I am looking for development lead contacts at RapidSMS.  Whom should I speak with?  Any ideas?
>>
>> -Paul
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Ime Asangansi]

Yes, Saptarshi. Such simplicity was the idea when I started coding http://openmrs.org/wiki/SMS_Server_Module

But then its never that simple :)

After wanting to send alerts for a single patient today, tomorrow you would want to send to a cohort
...and then later you would want to be able to schedule the alerts, provide intelligent alerts. Then you find that you would want to provide a 2-way system (like we are rolling out pretty soon)...and you find your self building a whole new SMS system :)

You may want to build a module that integrates with an existing system like RapidSMS (in django)...and my thinking is that a RESTful (service) to RapidSMS may just suffice...(I am doing this using a similar system though proprietary in this case)
or better still if the system is in Java (like mobilisr), you can embed it in OpenMRS and call its service through a module

just some thoughts

Cheers,
Ime Asangansi

--- On Tue, 11/3/09, Saptarshi Purkayastha <[hidden email]> wrote:

> I do feel that using another application
> (RapidSMS) for sending alert for a single patient, is an
> overkill... A simplistic module in OpenMRS should be able to
> do this...
> I agree a standard way to do it and
> aligning forces is a good thing to do, but for the above
> mentioned use-case, sounds like an overkill.
>
>
> ---
> Regards,
> Saptarshi PURKAYASTHA
> Director R & D, HISP India
> Health Information Systems Programme
>
> My Tech Blog:  http://sunnytalkstech.blogspot.com
>
>
> You Live by CHOICE, Not by CHANCE
>
>
>
> 2009/11/3 Daniel Kayiwa <[hidden email]>
>
>
>
> The xforms module sms functionality is only a way for
> filling forms.
> It is a one way route, where the sms is parsed and used to
> fill an existing xform.
>
> So it does not do things like alerts, etc
>
>
>
>
>
> On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email]>
> wrote:
>
>
>
> I'll look forward to hearing from Matt, but just a
> point of clarification while we wait:
>
>
>
> So, imagine the use case where we might want an OpenMRS
> instance to send out a single SMS alert to a patient.
>  Would you imagine sending that SMS to RapidSMS at this
> point with an XForm?
>
>
>
> -Paul
>
>
>
> On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:
>
>
>
>
> Paul,
>
> I will let Matt respond himself, but I believe the current
> MVP intent is to continue to use the Xforms module as the
> way in to OpenMRS by creating a wrapper around the SMS. I
> know the module can accept some strictly formatted SMS
> messages but we envision a more robust two way API. I think
> this should be considered by others as well. One thing
> raised by this interface is the need for a shorter patient
> code which can be used instead of longer patient IDs typical
> for EMRs. We'd like to have OpenMRS autogenerate a short
> code (hex for example) which could be used by SMS messages
> more easily. Daniel's code does allow patients to be
> searched and downloaded, but when creating a message from
> scratch, shorter ids are better...
>
>
>
>
>
>
> Andy
>
>
>
> --------------------
>
> Andrew S. Kanter, MD MPH
>
>
>
>
>
> - Director of Health Information Systems/Medical
> Informatics
>
> Millennium Villages Project, Earth Institute, Columbia
> University
>
> - Asst. Prof. of Clinical Biomedical Informatics and
> Clinical Epidemiology
>
> Columbia University
>
>
>
>
>
> Email: [hidden email]
>
> Mobile: [phone]
>
> Office: [phone]
>
> Skype: akanter-ippnw
>
> Yahoo: andy_kanter
>
>
>
>
>
>
>
> ----- Original Message ----
>
> From: Paul Biondich <[hidden email]>
>
> To: [hidden email]
>
> Sent: Mon, November 2, 2009 8:02:07 PM
>
> Subject: Re: [OPENMRS-DEV] RapidSMS...
>
>
>
> Hi, thanks for this... what is his email address?
>
>
>
> I should have given more background... the need is arising
> on multiple fronts to support interfaces with SMS /
> telephony applications within OpenMRS and I want to pre-empt
> what might end up being fractured work by encouraging an
> open dialogue with stakeholder groups like FrontlineSMS and
> RapidSMS to consider agreeing on a standard interface
> protocol for interaction with OpenMRS vs. multiple adhoc
> interfaces.
>
>
>
>
>
>
> Hope this makes sense... figured since you as well as
> others have committed at some level to RapidSMS that we
> consider them.
>
>
>
> In short, I remembered our conversation... ;)
>
>
>
> -Paul
>
>
>
> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>
>
>
>
> Paul,
>
>
>
> You should talk to Matt Berg at Columbia... he is heading
> up the modifications we are making to the RapidSMS core for
> UNICEF. Are you interested in a technical contact or a
> political one ;)?
>
>
>
> Andy
>
> --------------------
>
> Andrew S. Kanter, MD MPH
>
>
>
>
>
> - Director of Health Information Systems/Medical
> Informatics
>
> Millennium Villages Project, Earth Institute, Columbia
> University
>
> - Asst. Prof. of Clinical Biomedical Informatics and
> Clinical Epidemiology
>
> Columbia University
>
>
>
>
>
> Email: [hidden email]
>
> Mobile: [phone]
>
> Office: [phone]
>
> Skype: akanter-ippnw
>
> Yahoo: andy_kanter
>
>
>
>
>
>
>
> ----- Original Message ----
>
> From: Paul Biondich <[hidden email]>
>
> To: [hidden email]
>
> Sent: Mon, November 2, 2009 4:49:37 PM
>
> Subject: [OPENMRS-DEV] RapidSMS...
>
>
>
> Andy and/or other colleagues,
>
>
>
> I am looking for development lead contacts at RapidSMS.
>  Whom should I speak with?  Any ideas?
>
>
>
> -Paul
>
>
>
> _________________________________________
>
>
>
> To unsubscribe from OpenMRS Developers' mailing list,
> send an e-mail to [hidden email]
> with "SIGNOFF openmrs-devel-l" in the  body (not
> the subject) of your e-mail.
>
>
>
>
>
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
>
> _________________________________________
>
>
>
> To unsubscribe from OpenMRS Developers' mailing list,
> send an e-mail to [hidden email]
> with "SIGNOFF openmrs-devel-l" in the  body (not
> the subject) of your e-mail.
>
>
>
>
>
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
>
>
> _________________________________________
>
>
>
> To unsubscribe from OpenMRS Developers' mailing list,
> send an e-mail to [hidden email]
> with "SIGNOFF openmrs-devel-l" in the  body (not
> the subject) of your e-mail.
>
>
>
>
>
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
>
> _________________________________________
>
>
>
> To unsubscribe from OpenMRS Developers' mailing list,
> send an e-mail to [hidden email]
> with "SIGNOFF openmrs-devel-l" in the  body (not
> the subject) of your e-mail.
>
>
>
>
>
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
>
>
> _________________________________________
>
>
>
> To unsubscribe from OpenMRS Developers' mailing list,
> send an e-mail to [hidden email]
> with "SIGNOFF openmrs-devel-l" in the  body (not
> the subject) of your e-mail.
>
>
>
>
>
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
>
>
> --
> If we keep uppermost in our minds the unkind and unjust
> acts of others, we shall find it impossible to love them as
> Christ has loved us; but if our thoughts dwell upon the
> wondrous love and pity of Christ for us, the same spirit
> will flow out to others.
>
>
>
>
>
>
> Click
> here to unsubscribe from OpenMRS Developers' mailing
> list
>
>
>
>
> Click
> here to unsubscribe from OpenMRS Developers' mailing
> list
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Paul Biondich-2]

Grin, this is what I get for being obtuse. :)

A couple of things to unpack here:

1)  My example is not an actual use case... I just wanted to  
understand how a simple SMS alert might be done communicated  
technically through a package like FrontlineSMS and/or RapidSMS.  One  
could argue that RapidSMS is overkill for an imagined use case like  
this when viewed in isolation, but you could also imagine an instance  
of OpenMRS & a SMS framework serving multiple use cases in an  
environment, and I'm pretty confident that none of you would suggest  
building a separate line of code in support of "one at a time SMSs" or  
even "cohort blast SMSs" when the existing SMS generating applications  
can do a lot of this work already.

2)  My goal is to think about ways in which we can essentially treat,  
as my colleague pointed out this morning, these SMS telephony  
applications as "black boxes", and create the most efficient,  
lightweight interface to them in OpenMRS for real, not perceived use  
cases.

I should add that AMPATH in Eldoret is about to embark on a fairly  
substantive outreach project where we intend to remind patients about  
upcoming appointments as a way of increasing visit compliance via SMS  
messages.  But I will leave that to my colleagues to describe more.  :)

Best,
-Paul

On Nov 3, 2009, at 9:21 AM, Andrew Kanter wrote:

> Paul,
> I don't think that sending out a single alert via SMS needs to go  
> through RapidSMS... however, there are a lot of workflow issues  
> which group messaging and tasking through RapidSMS makes sense. The  
> important points will be to identify the specific use cases,  
> functionality gaps and development requirements to complete the  
> circle. MVP will be rolling out an integrated Community Health  
> Worker information system which flows through OpenMRS into other  
> systems (such as DHIS, etc.). I think the ecosystem of solutions  
> including SMS, CommCare/OpenROSA, ODK, etc. is starting to come  
> together... but the actual use cases will be dictated by partners  
> such as PIH and MVP which need to roll-out scalable and sustainable  
> systems across multiple locations...
>
> Perhaps this should also be discussed at AMIA?
>
> -Andy
> --------------------
> Andrew S. Kanter, MD MPH
>
>
> - Director of Health Information Systems/Medical Informatics
> Millennium Villages Project, Earth Institute, Columbia University
> - Asst. Prof. of Clinical Biomedical Informatics and Clinical  
> Epidemiology
> Columbia University
>
>
> Email: [hidden email]
> Mobile: [phone]
> Office: [phone]
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
>
> ----- Original Message ----
> From: Paul Biondich <[hidden email]>
> To: [hidden email]
> Sent: Tue, November 3, 2009 8:59:23 AM
> Subject: Re: [OPENMRS-DEV] RapidSMS...
>
> I'll look forward to hearing from Matt, but just a point of  
> clarification while we wait:
>
> So, imagine the use case where we might want an OpenMRS instance to  
> send out a single SMS alert to a patient.  Would you imagine sending  
> that SMS to RapidSMS at this point with an XForm?
>
> -Paul
>
> On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:
>
>> Paul,
>> I will let Matt respond himself, but I believe the current MVP  
>> intent is to continue to use the Xforms module as the way in to  
>> OpenMRS by creating a wrapper around the SMS. I know the module can  
>> accept some strictly formatted SMS messages but we envision a more  
>> robust two way API. I think this should be considered by others as  
>> well. One thing raised by this interface is the need for a shorter  
>> patient code which can be used instead of longer patient IDs  
>> typical for EMRs. We'd like to have OpenMRS autogenerate a short  
>> code (hex for example) which could be used by SMS messages more  
>> easily. Daniel's code does allow patients to be searched and  
>> downloaded, but when creating a message from scratch, shorter ids  
>> are better...
>>
>> Andy
>>
>> --------------------
>> Andrew S. Kanter, MD MPH
>>
>>
>> - Director of Health Information Systems/Medical Informatics
>> Millennium Villages Project, Earth Institute, Columbia University
>> - Asst. Prof. of Clinical Biomedical Informatics and Clinical  
>> Epidemiology
>> Columbia University
>>
>>
>> Email: [hidden email]
>> Mobile: [phone]
>> Office: [phone]
>> Skype: akanter-ippnw
>> Yahoo: andy_kanter
>>
>>
>>
>> ----- Original Message ----
>> From: Paul Biondich <[hidden email]>
>> To: [hidden email]
>> Sent: Mon, November 2, 2009 8:02:07 PM
>> Subject: Re: [OPENMRS-DEV] RapidSMS...
>>
>> Hi, thanks for this... what is his email address?
>>
>> I should have given more background... the need is arising on  
>> multiple fronts to support interfaces with SMS / telephony  
>> applications within OpenMRS and I want to pre-empt what might end  
>> up being fractured work by encouraging an open dialogue with  
>> stakeholder groups like FrontlineSMS and RapidSMS to consider  
>> agreeing on a standard interface protocol for interaction with  
>> OpenMRS vs. multiple adhoc interfaces.
>>
>> Hope this makes sense... figured since you as well as others have  
>> committed at some level to RapidSMS that we consider them.
>>
>> In short, I remembered our conversation... ;)
>>
>> -Paul
>>
>> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>>
>>> Paul,
>>>
>>> You should talk to Matt Berg at Columbia... he is heading up the  
>>> modifications we are making to the RapidSMS core for UNICEF. Are  
>>> you interested in a technical contact or a political one ;)?
>>>
>>> Andy
>>> --------------------
>>> Andrew S. Kanter, MD MPH
>>>
>>>
>>> - Director of Health Information Systems/Medical Informatics
>>> Millennium Villages Project, Earth Institute, Columbia University
>>> - Asst. Prof. of Clinical Biomedical Informatics and Clinical  
>>> Epidemiology
>>> Columbia University
>>>
>>>
>>> Email: [hidden email]
>>> Mobile: [phone]
>>> Office: [phone]
>>> Skype: akanter-ippnw
>>> Yahoo: andy_kanter
>>>
>>>
>>>
>>> ----- Original Message ----
>>> From: Paul Biondich <[hidden email]>
>>> To: [hidden email]
>>> Sent: Mon, November 2, 2009 4:49:37 PM
>>> Subject: [OPENMRS-DEV] RapidSMS...
>>>
>>> Andy and/or other colleagues,
>>>
>>> I am looking for development lead contacts at RapidSMS.  Whom  
>>> should I speak with?  Any ideas?
>>>
>>> -Paul
>>>
>>> _________________________________________
>>>
>>> To unsubscribe from OpenMRS Developers' mailing list, send an e-
>>> mail to [hidden email] with "SIGNOFF openmrs-devel-l"  
>>> in the  body (not the subject) of your e-mail.
>>>
>>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>>
>>> _________________________________________
>>>
>>> To unsubscribe from OpenMRS Developers' mailing list, send an e-
>>> mail to [hidden email] with "SIGNOFF openmrs-devel-l"  
>>> in the  body (not the subject) of your e-mail.
>>>
>>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-
>> mail to [hidden email] with "SIGNOFF openmrs-devel-l"  
>> in the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-
>> mail to [hidden email] with "SIGNOFF openmrs-devel-l"  
>> in the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Paul Biondich-2]

Yes, you're on the money here Ime, as always... this is my thinking as  
well.

-Paul

On Nov 3, 2009, at 9:27 AM, Ime Asangansi wrote:

> Yes, Saptarshi. Such simplicity was the idea when I started coding http://openmrs.org/wiki/SMS_Server_Module
>
> But then its never that simple :)
>
> After wanting to send alerts for a single patient today, tomorrow  
> you would want to send to a cohort
> ...and then later you would want to be able to schedule the alerts,  
> provide intelligent alerts. Then you find that you would want to  
> provide a 2-way system (like we are rolling out pretty soon)...and  
> you find your self building a whole new SMS system :)
>
> You may want to build a module that integrates with an existing  
> system like RapidSMS (in django)...and my thinking is that a RESTful  
> (service) to RapidSMS may just suffice...(I am doing this using a  
> similar system though proprietary in this case)
> or better still if the system is in Java (like mobilisr), you can  
> embed it in OpenMRS and call its service through a module
>
> just some thoughts
>
> Cheers,
> Ime Asangansi
>
> --- On Tue, 11/3/09, Saptarshi Purkayastha <[hidden email]> wrote:
>
>> I do feel that using another application
>> (RapidSMS) for sending alert for a single patient, is an
>> overkill... A simplistic module in OpenMRS should be able to
>> do this...
>> I agree a standard way to do it and
>> aligning forces is a good thing to do, but for the above
>> mentioned use-case, sounds like an overkill.
>>
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>> Director R & D, HISP India
>> Health Information Systems Programme
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>>
>>
>> You Live by CHOICE, Not by CHANCE
>>
>>
>>
>> 2009/11/3 Daniel Kayiwa <[hidden email]>
>>
>>
>>
>> The xforms module sms functionality is only a way for
>> filling forms.
>> It is a one way route, where the sms is parsed and used to
>> fill an existing xform.
>>
>> So it does not do things like alerts, etc
>>
>>
>>
>>
>>
>> On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email]
>> >
>> wrote:
>>
>>
>>
>> I'll look forward to hearing from Matt, but just a
>> point of clarification while we wait:
>>
>>
>>
>> So, imagine the use case where we might want an OpenMRS
>> instance to send out a single SMS alert to a patient.
>>  Would you imagine sending that SMS to RapidSMS at this
>> point with an XForm?
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>> I will let Matt respond himself, but I believe the current
>> MVP intent is to continue to use the Xforms module as the
>> way in to OpenMRS by creating a wrapper around the SMS. I
>> know the module can accept some strictly formatted SMS
>> messages but we envision a more robust two way API. I think
>> this should be considered by others as well. One thing
>> raised by this interface is the need for a shorter patient
>> code which can be used instead of longer patient IDs typical
>> for EMRs. We'd like to have OpenMRS autogenerate a short
>> code (hex for example) which could be used by SMS messages
>> more easily. Daniel's code does allow patients to be
>> searched and downloaded, but when creating a message from
>> scratch, shorter ids are better...
>>
>>
>>
>>
>>
>>
>> Andy
>>
>>
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 8:02:07 PM
>>
>> Subject: Re: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Hi, thanks for this... what is his email address?
>>
>>
>>
>> I should have given more background... the need is arising
>> on multiple fronts to support interfaces with SMS /
>> telephony applications within OpenMRS and I want to pre-empt
>> what might end up being fractured work by encouraging an
>> open dialogue with stakeholder groups like FrontlineSMS and
>> RapidSMS to consider agreeing on a standard interface
>> protocol for interaction with OpenMRS vs. multiple adhoc
>> interfaces.
>>
>>
>>
>>
>>
>>
>> Hope this makes sense... figured since you as well as
>> others have committed at some level to RapidSMS that we
>> consider them.
>>
>>
>>
>> In short, I remembered our conversation... ;)
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>>
>>
>> You should talk to Matt Berg at Columbia... he is heading
>> up the modifications we are making to the RapidSMS core for
>> UNICEF. Are you interested in a technical contact or a
>> political one ;)?
>>
>>
>>
>> Andy
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 4:49:37 PM
>>
>> Subject: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Andy and/or other colleagues,
>>
>>
>>
>> I am looking for development lead contacts at RapidSMS.
>>  Whom should I speak with?  Any ideas?
>>
>>
>>
>> -Paul
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> --
>> If we keep uppermost in our minds the unkind and unjust
>> acts of others, we shall find it impossible to love them as
>> Christ has loved us; but if our thoughts dwell upon the
>> wondrous love and pity of Christ for us, the same spirit
>> will flow out to others.
>>
>>
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Zeshan Rajput]

Hi everyone. I'm a new medical informatics fellow at Regenstrief working with Paul, and I'm trying to make my focus patient-facing applications in OpenMRS. As Paul mentioned elsewhere, I'm beginning to work with the AMPATH Outreach program on using SMS to remind patients of appointments, and thus came to this conversation.

I've been thinking along the lines of the 'black box' approach, as was mentioned on a call earlier this morning. In short, various modules and functions in OpenMRS that require asynchronous communication with a user could interact with a 'communications module'. In that interaction, the requesting module will need to reference a concept for an interaction (i.e. ask patient if he will make an appointment). The communications module would need to know the preferred method for reaching a user (SMS message, email, perhaps automated telephone system, courier pigeon, etc). The communications module would then interact in a standard fashion with the preferred communications module - that interaction would include the message from the originally referenced concept, the intended recipient's name, the relevant address, and a unique ID for this message.

The communications module may also need to conduct information back into the original requesting module. It would then need to receive in a standard fashion the original unique ID and the response message (or 'not deliverable'). The communications module would then reference the original concept and introduce the relevant answer to the requesting module.

Questions:
1) Does this model address everyone's use cases? What use cases do you have interest in? (For example, one use case on my desk is to send an SMS message to a patient reminding them of an appointment. Another is to collect point-of-care lab values from field workers, again via SMS likely. A third was possibly 'flashing' a patient's phone to remind them, rather than incurring SMS messaging costs.)
2) Is there a standard for the communications module - preferred communications module interaction that everyone prefers?
3) This module infers some complexity - at the worst case, you're talking about a requesting module, a communications 'hub' module, and separate modules to interact with the various communications methods (i.e. an OpenMRS-Frontline:SMS module), not including the communications methods themselves. Is this complexity needed? Is this the least complex solution possible?
4) What issues are going to arise here?
5) Does anyone have thoughts (or perhaps even code) already done along these lines?

I appreciate everyone's time and interest on this. Based on the responses, I'll put together some entries on the wiki and plan logistics. I'll also write the implementer's list and see if they have any more use cases to contribute. Thanks again!
-Zeshan

Zeshan A. Rajput, MD
Medical Informatics Fellow, Regenstrief Institute
Health Information and Translational Sciences (HITS) Building
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
IU Campus Mail:  HS 2000
Phone: [phone]


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Biondich
Sent: Tuesday, November 03, 2009 10:40 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Yes, you're on the money here Ime, as always... this is my thinking as  
well.

-Paul

On Nov 3, 2009, at 9:27 AM, Ime Asangansi wrote:

> Yes, Saptarshi. Such simplicity was the idea when I started coding http://openmrs.org/wiki/SMS_Server_Module
>
> But then its never that simple :)
>
> After wanting to send alerts for a single patient today, tomorrow  
> you would want to send to a cohort
> ...and then later you would want to be able to schedule the alerts,  
> provide intelligent alerts. Then you find that you would want to  
> provide a 2-way system (like we are rolling out pretty soon)...and  
> you find your self building a whole new SMS system :)
>
> You may want to build a module that integrates with an existing  
> system like RapidSMS (in django)...and my thinking is that a RESTful  
> (service) to RapidSMS may just suffice...(I am doing this using a  
> similar system though proprietary in this case)
> or better still if the system is in Java (like mobilisr), you can  
> embed it in OpenMRS and call its service through a module
>
> just some thoughts
>
> Cheers,
> Ime Asangansi
>
> --- On Tue, 11/3/09, Saptarshi Purkayastha <[hidden email]> wrote:
>
>> I do feel that using another application
>> (RapidSMS) for sending alert for a single patient, is an
>> overkill... A simplistic module in OpenMRS should be able to
>> do this...
>> I agree a standard way to do it and
>> aligning forces is a good thing to do, but for the above
>> mentioned use-case, sounds like an overkill.
>>
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>> Director R & D, HISP India
>> Health Information Systems Programme
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>>
>>
>> You Live by CHOICE, Not by CHANCE
>>
>>
>>
>> 2009/11/3 Daniel Kayiwa <[hidden email]>
>>
>>
>>
>> The xforms module sms functionality is only a way for
>> filling forms.
>> It is a one way route, where the sms is parsed and used to
>> fill an existing xform.
>>
>> So it does not do things like alerts, etc
>>
>>
>>
>>
>>
>> On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email]
>> >
>> wrote:
>>
>>
>>
>> I'll look forward to hearing from Matt, but just a
>> point of clarification while we wait:
>>
>>
>>
>> So, imagine the use case where we might want an OpenMRS
>> instance to send out a single SMS alert to a patient.
>>  Would you imagine sending that SMS to RapidSMS at this
>> point with an XForm?
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>> I will let Matt respond himself, but I believe the current
>> MVP intent is to continue to use the Xforms module as the
>> way in to OpenMRS by creating a wrapper around the SMS. I
>> know the module can accept some strictly formatted SMS
>> messages but we envision a more robust two way API. I think
>> this should be considered by others as well. One thing
>> raised by this interface is the need for a shorter patient
>> code which can be used instead of longer patient IDs typical
>> for EMRs. We'd like to have OpenMRS autogenerate a short
>> code (hex for example) which could be used by SMS messages
>> more easily. Daniel's code does allow patients to be
>> searched and downloaded, but when creating a message from
>> scratch, shorter ids are better...
>>
>>
>>
>>
>>
>>
>> Andy
>>
>>
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 8:02:07 PM
>>
>> Subject: Re: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Hi, thanks for this... what is his email address?
>>
>>
>>
>> I should have given more background... the need is arising
>> on multiple fronts to support interfaces with SMS /
>> telephony applications within OpenMRS and I want to pre-empt
>> what might end up being fractured work by encouraging an
>> open dialogue with stakeholder groups like FrontlineSMS and
>> RapidSMS to consider agreeing on a standard interface
>> protocol for interaction with OpenMRS vs. multiple adhoc
>> interfaces.
>>
>>
>>
>>
>>
>>
>> Hope this makes sense... figured since you as well as
>> others have committed at some level to RapidSMS that we
>> consider them.
>>
>>
>>
>> In short, I remembered our conversation... ;)
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>>
>>
>> You should talk to Matt Berg at Columbia... he is heading
>> up the modifications we are making to the RapidSMS core for
>> UNICEF. Are you interested in a technical contact or a
>> political one ;)?
>>
>>
>>
>> Andy
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 4:49:37 PM
>>
>> Subject: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Andy and/or other colleagues,
>>
>>
>>
>> I am looking for development lead contacts at RapidSMS.
>>  Whom should I speak with?  Any ideas?
>>
>>
>>
>> -Paul
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> --
>> If we keep uppermost in our minds the unkind and unjust
>> acts of others, we shall find it impossible to love them as
>> Christ has loved us; but if our thoughts dwell upon the
>> wondrous love and pity of Christ for us, the same spirit
>> will flow out to others.
>>
>>
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Anand, Vibha]

We have a use case - currently it is to use smart phones to collect survey data and GPS coordinates of the phone from the participants at a regular interval, send reminders (SMS) to answer the survey and get general good health indicators of the phone. The survey itself can be served as a page that can be accessed using the browser on the smart phones or using advanced form technologies (XForm). We would like to use OpenMRS as backend for collecting the data and generating the surveys which initially are static but will become dynamic using our atd module and the logic engine.

I am currently exploring the FrontlineSMS framework for its capabilities and certainly am interested in knowing how these features get built into the OpenMRS framework.

Vibha

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Zeshan Rajput
Sent: Tuesday, November 03, 2009 12:18 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Hi everyone. I'm a new medical informatics fellow at Regenstrief working with Paul, and I'm trying to make my focus patient-facing applications in OpenMRS. As Paul mentioned elsewhere, I'm beginning to work with the AMPATH Outreach program on using SMS to remind patients of appointments, and thus came to this conversation.

I've been thinking along the lines of the 'black box' approach, as was mentioned on a call earlier this morning. In short, various modules and functions in OpenMRS that require asynchronous communication with a user could interact with a 'communications module'. In that interaction, the requesting module will need to reference a concept for an interaction (i.e. ask patient if he will make an appointment). The communications module would need to know the preferred method for reaching a user (SMS message, email, perhaps automated telephone system, courier pigeon, etc). The communications module would then interact in a standard fashion with the preferred communications module - that interaction would include the message from the originally referenced concept, the intended recipient's name, the relevant address, and a unique ID for this message.

The communications module may also need to conduct information back into the original requesting module. It would then need to receive in a standard fashion the original unique ID and the response message (or 'not deliverable'). The communications module would then reference the original concept and introduce the relevant answer to the requesting module.

Questions:
1) Does this model address everyone's use cases? What use cases do you have interest in? (For example, one use case on my desk is to send an SMS message to a patient reminding them of an appointment. Another is to collect point-of-care lab values from field workers, again via SMS likely. A third was possibly 'flashing' a patient's phone to remind them, rather than incurring SMS messaging costs.)
2) Is there a standard for the communications module - preferred communications module interaction that everyone prefers?
3) This module infers some complexity - at the worst case, you're talking about a requesting module, a communications 'hub' module, and separate modules to interact with the various communications methods (i.e. an OpenMRS-Frontline:SMS module), not including the communications methods themselves. Is this complexity needed? Is this the least complex solution possible?
4) What issues are going to arise here?
5) Does anyone have thoughts (or perhaps even code) already done along these lines?

I appreciate everyone's time and interest on this. Based on the responses, I'll put together some entries on the wiki and plan logistics. I'll also write the implementer's list and see if they have any more use cases to contribute. Thanks again!
-Zeshan

Zeshan A. Rajput, MD
Medical Informatics Fellow, Regenstrief Institute
Health Information and Translational Sciences (HITS) Building
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
IU Campus Mail:  HS 2000
Phone: [phone]


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Biondich
Sent: Tuesday, November 03, 2009 10:40 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Yes, you're on the money here Ime, as always... this is my thinking as  
well.

-Paul

On Nov 3, 2009, at 9:27 AM, Ime Asangansi wrote:

> Yes, Saptarshi. Such simplicity was the idea when I started coding http://openmrs.org/wiki/SMS_Server_Module
>
> But then its never that simple :)
>
> After wanting to send alerts for a single patient today, tomorrow  
> you would want to send to a cohort
> ...and then later you would want to be able to schedule the alerts,  
> provide intelligent alerts. Then you find that you would want to  
> provide a 2-way system (like we are rolling out pretty soon)...and  
> you find your self building a whole new SMS system :)
>
> You may want to build a module that integrates with an existing  
> system like RapidSMS (in django)...and my thinking is that a RESTful  
> (service) to RapidSMS may just suffice...(I am doing this using a  
> similar system though proprietary in this case)
> or better still if the system is in Java (like mobilisr), you can  
> embed it in OpenMRS and call its service through a module
>
> just some thoughts
>
> Cheers,
> Ime Asangansi
>
> --- On Tue, 11/3/09, Saptarshi Purkayastha <[hidden email]> wrote:
>
>> I do feel that using another application
>> (RapidSMS) for sending alert for a single patient, is an
>> overkill... A simplistic module in OpenMRS should be able to
>> do this...
>> I agree a standard way to do it and
>> aligning forces is a good thing to do, but for the above
>> mentioned use-case, sounds like an overkill.
>>
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>> Director R & D, HISP India
>> Health Information Systems Programme
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>>
>>
>> You Live by CHOICE, Not by CHANCE
>>
>>
>>
>> 2009/11/3 Daniel Kayiwa <[hidden email]>
>>
>>
>>
>> The xforms module sms functionality is only a way for
>> filling forms.
>> It is a one way route, where the sms is parsed and used to
>> fill an existing xform.
>>
>> So it does not do things like alerts, etc
>>
>>
>>
>>
>>
>> On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email]
>> >
>> wrote:
>>
>>
>>
>> I'll look forward to hearing from Matt, but just a
>> point of clarification while we wait:
>>
>>
>>
>> So, imagine the use case where we might want an OpenMRS
>> instance to send out a single SMS alert to a patient.
>>  Would you imagine sending that SMS to RapidSMS at this
>> point with an XForm?
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>> I will let Matt respond himself, but I believe the current
>> MVP intent is to continue to use the Xforms module as the
>> way in to OpenMRS by creating a wrapper around the SMS. I
>> know the module can accept some strictly formatted SMS
>> messages but we envision a more robust two way API. I think
>> this should be considered by others as well. One thing
>> raised by this interface is the need for a shorter patient
>> code which can be used instead of longer patient IDs typical
>> for EMRs. We'd like to have OpenMRS autogenerate a short
>> code (hex for example) which could be used by SMS messages
>> more easily. Daniel's code does allow patients to be
>> searched and downloaded, but when creating a message from
>> scratch, shorter ids are better...
>>
>>
>>
>>
>>
>>
>> Andy
>>
>>
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 8:02:07 PM
>>
>> Subject: Re: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Hi, thanks for this... what is his email address?
>>
>>
>>
>> I should have given more background... the need is arising
>> on multiple fronts to support interfaces with SMS /
>> telephony applications within OpenMRS and I want to pre-empt
>> what might end up being fractured work by encouraging an
>> open dialogue with stakeholder groups like FrontlineSMS and
>> RapidSMS to consider agreeing on a standard interface
>> protocol for interaction with OpenMRS vs. multiple adhoc
>> interfaces.
>>
>>
>>
>>
>>
>>
>> Hope this makes sense... figured since you as well as
>> others have committed at some level to RapidSMS that we
>> consider them.
>>
>>
>>
>> In short, I remembered our conversation... ;)
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>>
>>
>> You should talk to Matt Berg at Columbia... he is heading
>> up the modifications we are making to the RapidSMS core for
>> UNICEF. Are you interested in a technical contact or a
>> political one ;)?
>>
>>
>>
>> Andy
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 4:49:37 PM
>>
>> Subject: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Andy and/or other colleagues,
>>
>>
>>
>> I am looking for development lead contacts at RapidSMS.
>>  Whom should I speak with?  Any ideas?
>>
>>
>>
>> -Paul
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> --
>> If we keep uppermost in our minds the unkind and unjust
>> acts of others, we shall find it impossible to love them as
>> Christ has loved us; but if our thoughts dwell upon the
>> wondrous love and pity of Christ for us, the same spirit
>> will flow out to others.
>>
>>
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Andrew Kanter]

One further complication that we have in a similar workflow is that some of the data coming over the phone is household related and not person related. The current data model does not support non-person meta data. I believe that Saptarshi has a solution, and we will want to be able to take our Xforms and split data between the OBS table and potentially a household obs table....

-Andy
 --------------------
Andrew S. Kanter, MD MPH


- Director of Health Information Systems/Medical Informatics
Millennium Villages Project, Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: [phone]
Office: [phone]
Skype: akanter-ippnw
Yahoo: andy_kanter



----- Original Message ----
From: "Anand, Vibha" <[hidden email]>
To: [hidden email]
Sent: Wed, November 4, 2009 11:21:06 AM
Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

We have a use case - currently it is to use smart phones to collect survey data and GPS coordinates of the phone from the participants at a regular interval, send reminders (SMS) to answer the survey and get general good health indicators of the phone. The survey itself can be served as a page that can be accessed using the browser on the smart phones or using advanced form technologies (XForm). We would like to use OpenMRS as backend for collecting the data and generating the surveys which initially are static but will become dynamic using our atd module and the logic engine.

I am currently exploring the FrontlineSMS framework for its capabilities and certainly am interested in knowing how these features get built into the OpenMRS framework.

Vibha



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Zeshan Rajput
Sent: Tuesday, November 03, 2009 12:18 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Hi everyone. I'm a new medical informatics fellow at Regenstrief working with Paul, and I'm trying to make my focus patient-facing applications in OpenMRS. As Paul mentioned elsewhere, I'm beginning to work with the AMPATH Outreach program on using SMS to remind patients of appointments, and thus came to this conversation.

I've been thinking along the lines of the 'black box' approach, as was mentioned on a call earlier this morning. In short, various modules and functions in OpenMRS that require asynchronous communication with a user could interact with a 'communications module'. In that interaction, the requesting module will need to reference a concept for an interaction (i.e. ask patient if he will make an appointment). The communications module would need to know the preferred method for reaching a user (SMS message, email, perhaps automated telephone system, courier pigeon, etc). The communications module would then interact in a standard fashion with the preferred communications module - that interaction would include the message from the originally referenced concept, the intended recipient's name, the relevant address, and a unique ID for this message.

The communications module may also need to conduct information back into the original requesting module. It would then need to receive in a standard fashion the original unique ID and the response message (or 'not deliverable'). The communications module would then reference the original concept and introduce the relevant answer to the requesting module.

Questions:
1) Does this model address everyone's use cases? What use cases do you have interest in? (For example, one use case on my desk is to send an SMS message to a patient reminding them of an appointment. Another is to collect point-of-care lab values from field workers, again via SMS likely. A third was possibly 'flashing' a patient's phone to remind them, rather than incurring SMS messaging costs.)
2) Is there a standard for the communications module - preferred communications module interaction that everyone prefers?
3) This module infers some complexity - at the worst case, you're talking about a requesting module, a communications 'hub' module, and separate modules to interact with the various communications methods (i.e. an OpenMRS-Frontline:SMS module), not including the communications methods themselves. Is this complexity needed? Is this the least complex solution possible?
4) What issues are going to arise here?
5) Does anyone have thoughts (or perhaps even code) already done along these lines?

I appreciate everyone's time and interest on this. Based on the responses, I'll put together some entries on the wiki and plan logistics. I'll also write the implementer's list and see if they have any more use cases to contribute. Thanks again!
-Zeshan

Zeshan A. Rajput, MD
Medical Informatics Fellow, Regenstrief Institute
Health Information and Translational Sciences (HITS) Building
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
IU Campus Mail:  HS 2000
Phone: [phone]


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Biondich
Sent: Tuesday, November 03, 2009 10:40 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Yes, you're on the money here Ime, as always... this is my thinking as  
well.

-Paul

On Nov 3, 2009, at 9:27 AM, Ime Asangansi wrote:

> Yes, Saptarshi. Such simplicity was the idea when I started coding http://openmrs.org/wiki/SMS_Server_Module
>
> But then its never that simple :)
>
> After wanting to send alerts for a single patient today, tomorrow  
> you would want to send to a cohort
> ...and then later you would want to be able to schedule the alerts,  
> provide intelligent alerts. Then you find that you would want to  
> provide a 2-way system (like we are rolling out pretty soon)...and  
> you find your self building a whole new SMS system :)
>
> You may want to build a module that integrates with an existing  
> system like RapidSMS (in django)...and my thinking is that a RESTful  
> (service) to RapidSMS may just suffice...(I am doing this using a  
> similar system though proprietary in this case)
> or better still if the system is in Java (like mobilisr), you can  
> embed it in OpenMRS and call its service through a module
>
> just some thoughts
>
> Cheers,
> Ime Asangansi
>
> --- On Tue, 11/3/09, Saptarshi Purkayastha <[hidden email]> wrote:
>
>> I do feel that using another application
>> (RapidSMS) for sending alert for a single patient, is an
>> overkill... A simplistic module in OpenMRS should be able to
>> do this...
>> I agree a standard way to do it and
>> aligning forces is a good thing to do, but for the above
>> mentioned use-case, sounds like an overkill.
>>
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>> Director R & D, HISP India
>> Health Information Systems Programme
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>>
>>
>> You Live by CHOICE, Not by CHANCE
>>
>>
>>
>> 2009/11/3 Daniel Kayiwa <[hidden email]>
>>
>>
>>
>> The xforms module sms functionality is only a way for
>> filling forms.
>> It is a one way route, where the sms is parsed and used to
>> fill an existing xform.
>>
>> So it does not do things like alerts, etc
>>
>>
>>
>>
>>
>> On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email]
>> >
>> wrote:
>>
>>
>>
>> I'll look forward to hearing from Matt, but just a
>> point of clarification while we wait:
>>
>>
>>
>> So, imagine the use case where we might want an OpenMRS
>> instance to send out a single SMS alert to a patient.
>>  Would you imagine sending that SMS to RapidSMS at this
>> point with an XForm?
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>> I will let Matt respond himself, but I believe the current
>> MVP intent is to continue to use the Xforms module as the
>> way in to OpenMRS by creating a wrapper around the SMS. I
>> know the module can accept some strictly formatted SMS
>> messages but we envision a more robust two way API. I think
>> this should be considered by others as well. One thing
>> raised by this interface is the need for a shorter patient
>> code which can be used instead of longer patient IDs typical
>> for EMRs. We'd like to have OpenMRS autogenerate a short
>> code (hex for example) which could be used by SMS messages
>> more easily. Daniel's code does allow patients to be
>> searched and downloaded, but when creating a message from
>> scratch, shorter ids are better...
>>
>>
>>
>>
>>
>>
>> Andy
>>
>>
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 8:02:07 PM
>>
>> Subject: Re: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Hi, thanks for this... what is his email address?
>>
>>
>>
>> I should have given more background... the need is arising
>> on multiple fronts to support interfaces with SMS /
>> telephony applications within OpenMRS and I want to pre-empt
>> what might end up being fractured work by encouraging an
>> open dialogue with stakeholder groups like FrontlineSMS and
>> RapidSMS to consider agreeing on a standard interface
>> protocol for interaction with OpenMRS vs. multiple adhoc
>> interfaces.
>>
>>
>>
>>
>>
>>
>> Hope this makes sense... figured since you as well as
>> others have committed at some level to RapidSMS that we
>> consider them.
>>
>>
>>
>> In short, I remembered our conversation... ;)
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>>
>>
>> You should talk to Matt Berg at Columbia... he is heading
>> up the modifications we are making to the RapidSMS core for
>> UNICEF. Are you interested in a technical contact or a
>> political one ;)?
>>
>>
>>
>> Andy
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 4:49:37 PM
>>
>> Subject: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Andy and/or other colleagues,
>>
>>
>>
>> I am looking for development lead contacts at RapidSMS.
>>  Whom should I speak with?  Any ideas?
>>
>>
>>
>> -Paul
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> --
>> If we keep uppermost in our minds the unkind and unjust
>> acts of others, we shall find it impossible to love them as
>> Christ has loved us; but if our thoughts dwell upon the
>> wondrous love and pity of Christ for us, the same spirit
>> will flow out to others.
>>
>>
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Joaquín Blaya]

I'll try to respond later but not sure when I'll have time but one quick
thing I'd throw out to this group is that I think the standard for outbound
SMS messages need _not_ be XForms.  I almost always think the answer is
XForms, so wanted to distinguish in this case.  If you want to send a bunch
of people a message, i think a standard is good (so that you can use
RapidSMS or Frontline or whwatever) but doesn't strike me XForms is the
right standard.  maybe it is--but not necessarily so.  

also, there is a use case where patients can query OpenMRS for
info...obvious security concerns, but am pretty sure there is something good
to be done there too.

sorry for partial/non-answer.

n

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Zeshan Rajput
Sent: Tuesday, November 03, 2009 12:18 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Hi everyone. I'm a new medical informatics fellow at Regenstrief working
with Paul, and I'm trying to make my focus patient-facing applications in
OpenMRS. As Paul mentioned elsewhere, I'm beginning to work with the AMPATH
Outreach program on using SMS to remind patients of appointments, and thus
came to this conversation.

I've been thinking along the lines of the 'black box' approach, as was
mentioned on a call earlier this morning. In short, various modules and
functions in OpenMRS that require asynchronous communication with a user
could interact with a 'communications module'. In that interaction, the
requesting module will need to reference a concept for an interaction (i.e.
ask patient if he will make an appointment). The communications module would
need to know the preferred method for reaching a user (SMS message, email,
perhaps automated telephone system, courier pigeon, etc). The communications
module would then interact in a standard fashion with the preferred
communications module - that interaction would include the message from the
originally referenced concept, the intended recipient's name, the relevant
address, and a unique ID for this message.

The communications module may also need to conduct information back into the
original requesting module. It would then need to receive in a standard
fashion the original unique ID and the response message (or 'not
deliverable'). The communications module would then reference the original
concept and introduce the relevant answer to the requesting module.

Questions:
1) Does this model address everyone's use cases? What use cases do you have
interest in? (For example, one use case on my desk is to send an SMS message
to a patient reminding them of an appointment. Another is to collect
point-of-care lab values from field workers, again via SMS likely. A third
was possibly 'flashing' a patient's phone to remind them, rather than
incurring SMS messaging costs.)
2) Is there a standard for the communications module - preferred
communications module interaction that everyone prefers?
3) This module infers some complexity - at the worst case, you're talking
about a requesting module, a communications 'hub' module, and separate
modules to interact with the various communications methods (i.e. an
OpenMRS-Frontline:SMS module), not including the communications methods
themselves. Is this complexity needed? Is this the least complex solution
possible?
4) What issues are going to arise here?
5) Does anyone have thoughts (or perhaps even code) already done along these
lines?

I appreciate everyone's time and interest on this. Based on the responses,
I'll put together some entries on the wiki and plan logistics. I'll also
write the implementer's list and see if they have any more use cases to
contribute. Thanks again!
-Zeshan

Zeshan A. Rajput, MD
Medical Informatics Fellow, Regenstrief Institute
Health Information and Translational Sciences (HITS) Building
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
IU Campus Mail:  HS 2000
Phone: [phone]


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Biondich
Sent: Tuesday, November 03, 2009 10:40 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Yes, you're on the money here Ime, as always... this is my thinking as  
well.

-Paul

On Nov 3, 2009, at 9:27 AM, Ime Asangansi wrote:

> Yes, Saptarshi. Such simplicity was the idea when I started coding
http://openmrs.org/wiki/SMS_Server_Module

>
> But then its never that simple :)
>
> After wanting to send alerts for a single patient today, tomorrow  
> you would want to send to a cohort
> ...and then later you would want to be able to schedule the alerts,  
> provide intelligent alerts. Then you find that you would want to  
> provide a 2-way system (like we are rolling out pretty soon)...and  
> you find your self building a whole new SMS system :)
>
> You may want to build a module that integrates with an existing  
> system like RapidSMS (in django)...and my thinking is that a RESTful  
> (service) to RapidSMS may just suffice...(I am doing this using a  
> similar system though proprietary in this case)
> or better still if the system is in Java (like mobilisr), you can  
> embed it in OpenMRS and call its service through a module
>
> just some thoughts
>
> Cheers,
> Ime Asangansi
>
> --- On Tue, 11/3/09, Saptarshi Purkayastha <[hidden email]> wrote:
>
>> I do feel that using another application
>> (RapidSMS) for sending alert for a single patient, is an
>> overkill... A simplistic module in OpenMRS should be able to
>> do this...
>> I agree a standard way to do it and
>> aligning forces is a good thing to do, but for the above
>> mentioned use-case, sounds like an overkill.
>>
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>> Director R & D, HISP India
>> Health Information Systems Programme
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>>
>>
>> You Live by CHOICE, Not by CHANCE
>>
>>
>>
>> 2009/11/3 Daniel Kayiwa <[hidden email]>
>>
>>
>>
>> The xforms module sms functionality is only a way for
>> filling forms.
>> It is a one way route, where the sms is parsed and used to
>> fill an existing xform.
>>
>> So it does not do things like alerts, etc
>>
>>
>>
>>
>>
>> On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email]
>> >
>> wrote:
>>
>>
>>
>> I'll look forward to hearing from Matt, but just a
>> point of clarification while we wait:
>>
>>
>>
>> So, imagine the use case where we might want an OpenMRS
>> instance to send out a single SMS alert to a patient.
>>  Would you imagine sending that SMS to RapidSMS at this
>> point with an XForm?
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>> I will let Matt respond himself, but I believe the current
>> MVP intent is to continue to use the Xforms module as the
>> way in to OpenMRS by creating a wrapper around the SMS. I
>> know the module can accept some strictly formatted SMS
>> messages but we envision a more robust two way API. I think
>> this should be considered by others as well. One thing
>> raised by this interface is the need for a shorter patient
>> code which can be used instead of longer patient IDs typical
>> for EMRs. We'd like to have OpenMRS autogenerate a short
>> code (hex for example) which could be used by SMS messages
>> more easily. Daniel's code does allow patients to be
>> searched and downloaded, but when creating a message from
>> scratch, shorter ids are better...
>>
>>
>>
>>
>>
>>
>> Andy
>>
>>
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 8:02:07 PM
>>
>> Subject: Re: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Hi, thanks for this... what is his email address?
>>
>>
>>
>> I should have given more background... the need is arising
>> on multiple fronts to support interfaces with SMS /
>> telephony applications within OpenMRS and I want to pre-empt
>> what might end up being fractured work by encouraging an
>> open dialogue with stakeholder groups like FrontlineSMS and
>> RapidSMS to consider agreeing on a standard interface
>> protocol for interaction with OpenMRS vs. multiple adhoc
>> interfaces.
>>
>>
>>
>>
>>
>>
>> Hope this makes sense... figured since you as well as
>> others have committed at some level to RapidSMS that we
>> consider them.
>>
>>
>>
>> In short, I remembered our conversation... ;)
>>
>>
>>
>> -Paul
>>
>>
>>
>> On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:
>>
>>
>>
>>
>> Paul,
>>
>>
>>
>> You should talk to Matt Berg at Columbia... he is heading
>> up the modifications we are making to the RapidSMS core for
>> UNICEF. Are you interested in a technical contact or a
>> political one ;)?
>>
>>
>>
>> Andy
>>
>> --------------------
>>
>> Andrew S. Kanter, MD MPH
>>
>>
>>
>>
>>
>> - Director of Health Information Systems/Medical
>> Informatics
>>
>> Millennium Villages Project, Earth Institute, Columbia
>> University
>>
>> - Asst. Prof. of Clinical Biomedical Informatics and
>> Clinical Epidemiology
>>
>> Columbia University
>>
>>
>>
>>
>>
>> Email: [hidden email]
>>
>> Mobile: [phone]
>>
>> Office: [phone]
>>
>> Skype: akanter-ippnw
>>
>> Yahoo: andy_kanter
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----
>>
>> From: Paul Biondich <[hidden email]>
>>
>> To: [hidden email]
>>
>> Sent: Mon, November 2, 2009 4:49:37 PM
>>
>> Subject: [OPENMRS-DEV] RapidSMS...
>>
>>
>>
>> Andy and/or other colleagues,
>>
>>
>>
>> I am looking for development lead contacts at RapidSMS.
>>  Whom should I speak with?  Any ideas?
>>
>>
>>
>> -Paul
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> _________________________________________
>>
>>
>>
>> To unsubscribe from OpenMRS Developers' mailing list,
>> send an e-mail to [hidden email]
>> with "SIGNOFF openmrs-devel-l" in the  body (not
>> the subject) of your e-mail.
>>
>>
>>
>>
>>
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>>
>>
>> --
>> If we keep uppermost in our minds the unkind and unjust
>> acts of others, we shall find it impossible to love them as
>> Christ has loved us; but if our thoughts dwell upon the
>> wondrous love and pity of Christ for us, the same spirit
>> will flow out to others.
>>
>>
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>>
>>
>>
>> Click
>> here to unsubscribe from OpenMRS Developers' mailing
>> list
>>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  
> to [hidden email] with "SIGNOFF openmrs-devel-l" in  
> the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not
the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not
the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[isaacholeman]

Some javascript/style in this post has been disabled (why?)

Hi Everyone,

I didn't respond to this thread earlier because I'm already working closely with Zeshan, but I guess it might be good to fill everyone else in. I work with the Frontline Medic community, which has been working for some time to integrate OMRS with the widely used FrontlineSMS platform for a large number of use cases. Dozens of orgs are using FrontlineSMS in mHealth programs, and we're supporting projects that involve FSMS and OMRS in Malawi (where I'm currently based), Burundi, Mali, and Kenya. 

We're putting substantial developer time into mobile for OMRS, and we'd like to share the love - hopefully building an OMRS messaging module based on a standard that other mobile tools will take advantage of. At the OMRS meeting in Cape Town we decided to focus on the XForms module for submitting forms to OMRS. We're still working on a standard for blasting out simple messages (like appointment reminders).

We'll keep the list posted of our progress.

cheers

Isaac

Isaac Holeman, Field Director

FrontlineSMS:Medic ~ http://medic.frontlinesms.com

team twitter @smsmedic

(blog) www.isaacholeman.org

(malawi mobile) 256 99.364.3347

twitter @isaacholeman

On Nov 4, 2009, at 6:21 PM, Anand, Vibha wrote:

We have a use case - currently it is to use smart phones to collect survey data and GPS coordinates of the phone from the participants at a regular interval, send reminders (SMS) to answer the survey and get general good health indicators of the phone. The survey itself can be served as a page that can be accessed using the browser on the smart phones or using advanced form technologies (XForm). We would like to use OpenMRS as backend for collecting the data and generating the surveys which initially are static but will become dynamic using our atd module and the logic engine.

I am currently exploring the FrontlineSMS framework for its capabilities and certainly am interested in knowing how these features get built into the OpenMRS framework.

Vibha

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

From: [hidden email] [[hidden email]] On Behalf Of Zeshan Rajput

Sent: Tuesday, November 03, 2009 12:18 PM

To: [hidden email]

Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Hi everyone. I'm a new medical informatics fellow at Regenstrief working with Paul, and I'm trying to make my focus patient-facing applications in OpenMRS. As Paul mentioned elsewhere, I'm beginning to work with the AMPATH Outreach program on using SMS to remind patients of appointments, and thus came to this conversation.

I've been thinking along the lines of the 'black box' approach, as was mentioned on a call earlier this morning. In short, various modules and functions in OpenMRS that require asynchronous communication with a user could interact with a 'communications module'. In that interaction, the requesting module will need to reference a concept for an interaction (i.e. ask patient if he will make an appointment). The communications module would need to know the preferred method for reaching a user (SMS message, email, perhaps automated telephone system, courier pigeon, etc). The communications module would then interact in a standard fashion with the preferred communications module - that interaction would include the message from the originally referenced concept, the intended recipient's name, the relevant address, and a unique ID for this message.

The communications module may also need to conduct information back into the original requesting module. It would then need to receive in a standard fashion the original unique ID and the response message (or 'not deliverable'). The communications module would then reference the original concept and introduce the relevant answer to the requesting module. 

Questions:

1) Does this model address everyone's use cases? What use cases do you have interest in? (For example, one use case on my desk is to send an SMS message to a patient reminding them of an appointment. Another is to collect point-of-care lab values from field workers, again via SMS likely. A third was possibly 'flashing' a patient's phone to remind them, rather than incurring SMS messaging costs.)

2) Is there a standard for the communications module - preferred communications module interaction that everyone prefers? 

3) This module infers some complexity - at the worst case, you're talking about a requesting module, a communications 'hub' module, and separate modules to interact with the various communications methods (i.e. an OpenMRS-Frontline:SMS module), not including the communications methods themselves. Is this complexity needed? Is this the least complex solution possible?

4) What issues are going to arise here?

5) Does anyone have thoughts (or perhaps even code) already done along these lines?

I appreciate everyone's time and interest on this. Based on the responses, I'll put together some entries on the wiki and plan logistics. I'll also write the implementer's list and see if they have any more use cases to contribute. Thanks again!

-Zeshan

Zeshan A. Rajput, MD

Medical Informatics Fellow, Regenstrief Institute

Health Information and Translational Sciences (HITS) Building

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

IU Campus Mail:  HS 2000

Phone: [phone]

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

From: [hidden email] [[hidden email]] On Behalf Of Paul Biondich

Sent: Tuesday, November 03, 2009 10:40 AM

To: [hidden email]

Subject: Re: [OPENMRS-DEV] SMS Services in OpenMRS (was Re: RapidSMS...)

Yes, you're on the money here Ime, as always... this is my thinking as  

well.

-Paul

On Nov 3, 2009, at 9:27 AM, Ime Asangansi wrote:

Yes, Saptarshi. Such simplicity was the idea when I started coding http://openmrs.org/wiki/SMS_Server_Module

But then its never that simple :)

After wanting to send alerts for a single patient today, tomorrow  

you would want to send to a cohort

...and then later you would want to be able to schedule the alerts,  

provide intelligent alerts. Then you find that you would want to  

provide a 2-way system (like we are rolling out pretty soon)...and  

you find your self building a whole new SMS system :)

You may want to build a module that integrates with an existing  

system like RapidSMS (in django)...and my thinking is that a RESTful  

(service) to RapidSMS may just suffice...(I am doing this using a  

similar system though proprietary in this case)

or better still if the system is in Java (like mobilisr), you can  

embed it in OpenMRS and call its service through a module

just some thoughts

Cheers,

Ime Asangansi

--- On Tue, 11/3/09, Saptarshi Purkayastha <[hidden email]> wrote:

I do feel that using another application

(RapidSMS) for sending alert for a single patient, is an

overkill... A simplistic module in OpenMRS should be able to

do this...

I agree a standard way to do it and

aligning forces is a good thing to do, but for the above

mentioned use-case, sounds like an overkill.

---

Regards,

Saptarshi PURKAYASTHA

Director R & D, HISP India

Health Information Systems Programme

My Tech Blog:  http://sunnytalkstech.blogspot.com

You Live by CHOICE, Not by CHANCE

2009/11/3 Daniel Kayiwa <[hidden email]>

The xforms module sms functionality is only a way for

filling forms.

It is a one way route, where the sms is parsed and used to

fill an existing xform.

So it does not do things like alerts, etc

On Tue, Nov 3, 2009 at 4:59 PM, Paul Biondich <[hidden email] 

wrote:

I'll look forward to hearing from Matt, but just a

point of clarification while we wait:

So, imagine the use case where we might want an OpenMRS

instance to send out a single SMS alert to a patient.

 Would you imagine sending that SMS to RapidSMS at this

point with an XForm?

-Paul

On Nov 3, 2009, at 8:14 AM, Andrew Kanter wrote:

Paul,

I will let Matt respond himself, but I believe the current

MVP intent is to continue to use the Xforms module as the

way in to OpenMRS by creating a wrapper around the SMS. I

know the module can accept some strictly formatted SMS

messages but we envision a more robust two way API. I think

this should be considered by others as well. One thing

raised by this interface is the need for a shorter patient

code which can be used instead of longer patient IDs typical

for EMRs. We'd like to have OpenMRS autogenerate a short

code (hex for example) which could be used by SMS messages

more easily. Daniel's code does allow patients to be

searched and downloaded, but when creating a message from

scratch, shorter ids are better...

Andy

--------------------

Andrew S. Kanter, MD MPH

- Director of Health Information Systems/Medical

Informatics

Millennium Villages Project, Earth Institute, Columbia

University

- Asst. Prof. of Clinical Biomedical Informatics and

Clinical Epidemiology

Columbia University

Email: [hidden email]

Mobile: [phone]

Office: [phone]

Skype: akanter-ippnw

Yahoo: andy_kanter

----- Original Message ----

From: Paul Biondich <[hidden email]>

To: [hidden email]

Sent: Mon, November 2, 2009 8:02:07 PM

Subject: Re: [OPENMRS-DEV] RapidSMS...

Hi, thanks for this... what is his email address?

I should have given more background... the need is arising

on multiple fronts to support interfaces with SMS /

telephony applications within OpenMRS and I want to pre-empt

what might end up being fractured work by encouraging an

open dialogue with stakeholder groups like FrontlineSMS and

RapidSMS to consider agreeing on a standard interface

protocol for interaction with OpenMRS vs. multiple adhoc

interfaces.

Hope this makes sense... figured since you as well as

others have committed at some level to RapidSMS that we

consider them.

In short, I remembered our conversation... ;)

-Paul

On Nov 2, 2009, at 7:14 PM, Andrew Kanter wrote:

Paul,

You should talk to Matt Berg at Columbia... he is heading

up the modifications we are making to the RapidSMS core for

UNICEF. Are you interested in a technical contact or a

political one ;)?

Andy

--------------------

Andrew S. Kanter, MD MPH

- Director of Health Information Systems/Medical

Informatics

Millennium Villages Project, Earth Institute, Columbia

University

- Asst. Prof. of Clinical Biomedical Informatics and

Clinical Epidemiology

Columbia University

Email: [hidden email]

Mobile: [phone]

Office: [phone]

Skype: akanter-ippnw

Yahoo: andy_kanter

----- Original Message ----

From: Paul Biondich <[hidden email]>

To: [hidden email]

Sent: Mon, November 2, 2009 4:49:37 PM

Subject: [OPENMRS-DEV] RapidSMS...

Andy and/or other colleagues,

I am looking for development lead contacts at RapidSMS.

 Whom should I speak with?  Any ideas?

-Paul

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list,

send an e-mail to [hidden email]

with "SIGNOFF openmrs-devel-l" in the  body (not

the subject) of your e-mail.

[[hidden email]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list,

send an e-mail to [hidden email]

with "SIGNOFF openmrs-devel-l" in the  body (not

the subject) of your e-mail.

[[hidden email]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list,

send an e-mail to [hidden email]

with "SIGNOFF openmrs-devel-l" in the  body (not

the subject) of your e-mail.

[[hidden email]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list,

send an e-mail to [hidden email]

with "SIGNOFF openmrs-devel-l" in the  body (not

the subject) of your e-mail.

[[hidden email]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list,

send an e-mail to [hidden email]

with "SIGNOFF openmrs-devel-l" in the  body (not

the subject) of your e-mail.

[[hidden email]

-- 

If we keep uppermost in our minds the unkind and unjust

acts of others, we shall find it impossible to love them as

Christ has loved us; but if our thoughts dwell upon the

wondrous love and pity of Christ for us, the same spirit

will flow out to others.

Click

here to unsubscribe from OpenMRS Developers' mailing

list

Click

here to unsubscribe from OpenMRS Developers' mailing

list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail  

to [hidden email] with "SIGNOFF openmrs-devel-l" in  

the  body (not the subject) of your e-mail.

[[hidden email]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[[hidden email]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[[hidden email]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[[hidden email]

---

[hidden email] from OpenMRS Developers' mailing list