[prev in list] [next in list] [prev in thread] [next in thread]
List: openmrs-dev
Subject: Re: Drug Orders for Cancer
From: Darius Jazayeri <darius () openmrs ! org>
Date: 2014-08-27 16:10:16
Message-ID: CAA-nHnf1s8jHa3uKGyqMWeong=b+z0EHrszL74nNGDyidGE3tg () mail ! gmail ! com
[Download RAW message or body]
To Burke's broad point about where it's worth spending effort: you'll get
your biggest payoff in terms of user satisfaction and data quality from
building out standard Order Sets. These will allow electronic data entry to
be much quicker, and is a clear avenue for computer-aided prescribing.
Based on my (completely insufficient) understanding of cancer treatment, I
would not even try to handle those prescriptions electronically at any
scale until you've implemented Order Sets.
-Darius
PS- @Burke, if the doctor is going to be writing the order in the form of a
dilution, then it saves them significant effort to give them a
purpose-built UI. And once you've done that, if you want to support an
"Edit" use case, then it's probably less dev effort to store coded values
in the first place, than to deal with parsing them back out of free text.
(Once Order Sets are implemented, and an implementation has enough of these
pre-codified, the calculus could change. But OpenMRS doesn't support these
today.)
On Wed, Aug 27, 2014 at 8:43 AM, Burke Mamlin <burke@openmrs.org> wrote:
> That's correct. If you need the diluent to be codified, then it would
> require a different (new, not-yet-existent) dosing instruction type and, as
> Darius suggests, a generic InfusionDosingInstructions would be preferable
> to one that is case-specific.
>
> That said, not everything needs to be codified. Codifying data
> unncessarily can add costs of extra input fields, programming efforts, and
> content maintenance without any benefit. In general, data that just needs
> to be redisplayed or printed elsewhere does not need to be codified for the
> computer to understand. If you are codifying diluents "because you can" or
> because you can imagine a situation in which someday it might be useful to
> someone, I would take a moment to step back and look at your actual
> requirements. If diluent usage is supposed to drive automatic inventory
> updates or drive a robotic arm to prepare the infusion, then codifying will
> be useful. If you just need to be able to regurgitate the text that
> someone entered, then codifying diluent is adding structure (at a real
> cost) where it is not needed.
>
> Cheers,
>
> -Burke
>
>
> On Wed, Aug 27, 2014 at 11:03 AM, Darius Jazayeri <darius@openmrs.org>
> wrote:
>
> > My expectation was that for something like this, you would introduce a
> > new DosingInstructions type. You wouldn't want that to be cancer-specific,
> > but rather it would be "Infusion", along the lines of Jonathan's screenshot.
> >
> > This would let you capture coded values (probably via json in a big text
> > field in the database) as Mike suggests.
> >
> > -Darius
> >
> >
> > On Wed, Aug 27, 2014 at 7:55 AM, Hannan, Terry J (DHHS) <
> > Terry.Hannan@dhhs.tas.gov.au> wrote:
> >
> > > Mike, is there any 'evaluation' or 'guide' for your 1-2n years of
> > > effort? Terry
> > >
> > > Sent from my iPad
> > >
> > > On 27 Aug 2014, at 5:52 pm, "Michael Seaton" <mseaton@pih.org> wrote:
> > >
> > > Thanks all,
> > >
> > > Our team in Rwanda spent considerable time a few years ago trying to
> > > support Oncology order entry on top of the legacy drug order data model,
> > > and have been using it for managing complex chemotherapy regimens in the
> > > system there for 1-2 years now. The lions share of the work around this
> > > ended up in the orderextension module
> > > <https://github.com/openmrs/openmrs-module-orderextension>. Although I
> > > no longer hold out any hope that this will inform any of our decisions
> > > around order entry, I am still hoping that it will be a useful reference
> > > and/or strawman for order groups, order sets, and new user interface
> > > designs for drug order entry screens.
> > >
> > > My general feeling is that I would be fine using things like
> > > administration instructions and/or dosing instructions for this, but we
> > > need to be able to reliably parse these into objects that can be used to
> > > back the sort of user interfaces that Jonathan shows below. So we need to
> > > be able to ensure that the design unambiguously distinguishes between what
> > > are free-text administration instructions and what are structured
> > > administration instructions stored in a free-text field. Hopefully the
> > > design already accounts for this?
> > >
> > > Cheers,
> > > Mike
> > >
> > >
> > >
> > > -----Original Message-----
> > > *From*: Jonathan Teich <jmteich@gmail.com
> > > <Jonathan%20Teich%20%3cjmteich@gmail.com%3e>>
> > > Reply-to: <dev@openmrs.org>
> > > *To*: dev@openmrs.org <dev@openmrs.org
> > > <%22dev@openmrs.org%22%20%3cdev@openmrs.org%3e>>, burke@openmrs.org <
> > > burke@openmrs.org <%22burke@openmrs.org%22%20%3cburke@openmrs.org%3e>>
> > > *Cc*: bahmni <bahmni@thoughtworks.com
> > > <bahmni%20%3cbahmni@thoughtworks.com%3e>>
> > > *Subject*: Re: Drug Orders for Cancer
> > > *Date*: Wed, 27 Aug 2014 09:59:52 -0400
> > >
> > > This makes perfect sense for the current system capabilities.
> > >
> > > Going forward, a medication infusion has its own commonly used specific
> > > fields, if we ever choose to go there:
> > >
> > > <image.jpeg>
> > >
> > > There's a little more optimization that can be done to the fields above,
> > > but this is pretty close.
> > > Jonathan
> > > On Aug 27, 2014, at 9:21 AM, Burke Mamlin <burke@openmrs.org> wrote:
> > >
> > >
> > > On Wed, Aug 27, 2014 at 4:21 AM, Shruthi Dipali <shruthidipali@gmail.com>
> > > wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > For Chemotherapy, we may need to capture some of the following
> > > information with Drug Orders.
> > >
> > >
> > >
> > > - Diluent e.g. Give Ondansetron with 100ml Sodium Chloride 0.9%
> > >
> > >
> > >
> > > Diluent would be mentioned within administration instructions. For
> > > example:
> > >
> > >
> > >
> > > Drug = Ondansetron
> > >
> > > Simple Dosing Instructions
> > >
> > > Dose+units = 8 mg
> > >
> > > Route = IV
> > >
> > > Frequency = Once
> > >
> > > Administration instructions = give with 100ml Sodium Chloride 0.9%
> > > over 15 minutes at least 30 minutes prior to chemotherapy
> > >
> > >
> > >
> > > - Duration of administration. e.g. give this IV for 45 minutes
> > >
> > >
> > >
> > > Duration can be codified within Simple Dosing Instructions
> > > Duration+Units or can be non-codified in Simple Dosing Instructions
> > > Administration Instructions or in Free Text Instructions.
> > >
> > >
> > >
> > > - Stage in which to administer. e.g. pre-chemo, post-chemo
> > >
> > >
> > >
> > > Since these refer to timing, they could technically be additional
> > > urgency values; however, since they are very specific to chemotherapy, we
> > > would put these into administration instructions (as in my example above).
> > >
> > >
> > >
> > >
> > >
> > > How can we incorporate this into the current DrugOrder model?
> > >
> > >
> > >
> > > -Shruthi
> > >
> > >
> > >
> > >
> > >
> > > --
> > > OpenMRS Developers: http://go.openmrs.org/dev
> > > Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
> > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > >
> > >
> > >
> > > --
> > > OpenMRS Developers: http://go.openmrs.org/dev
> > > Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
> > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > >
> > >
> > > To unsubscribe from this group and stop receiving emails from it, send
> > > an email to dev+unsubscribe@openmrs.org.
> > >
> > >
> > >
> > > --
> > > OpenMRS Developers: http://go.openmrs.org/dev
> > > Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
> > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > >
> > > To unsubscribe from this group and stop receiving emails from it, send
> > > an email to dev+unsubscribe@openmrs.org.
> > >
> > >
> > > ------------------------------
> > >
> > > CONFIDENTIALITY NOTICE AND DISCLAIMER
> > > The information in this transmission may be confidential and/or
> > > protected by legal professional privilege, and is intended only for the
> > > person or persons to whom it is addressed. If you are not such a person,
> > > you are warned that any disclosure, copying or dissemination of the
> > > information is unauthorised. If you have received the transmission in
> > > error, please immediately contact this office by telephone, fax or email,
> > > to inform us of the error and to enable arrangements to be made for the
> > > destruction of the transmission, or its return at our cost. No liability is
> > > accepted for any unauthorised use of the information contained in this
> > > transmission.
> > >
> > > --
> > > OpenMRS Developers: http://go.openmrs.org/dev
> > > Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
> > > Manage your OpenMRS subscriptions at https://id.openmrs.org/
> > >
> >
> >
> --
> OpenMRS Developers: http://go.openmrs.org/dev
> Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
> Manage your OpenMRS subscriptions at https://id.openmrs.org/
>
--
OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
To unsubscribe from this group and stop receiving emails from it, send an email to \
dev+unsubscribe@openmrs.org.
[Attachment #3 (text/html)]
<div dir="ltr"><div>To Burke's broad point about where it's worth spending \
effort: you'll get your biggest payoff in terms of user satisfaction and data \
quality from building out standard Order Sets. These will allow electronic data entry \
to be much quicker, and is a clear avenue for computer-aided prescribing.</div>
<div><br></div><div>Based on my (completely insufficient) understanding of cancer \
treatment, I would not even try to handle those prescriptions electronically at any \
scale until you've implemented Order Sets.</div><div>
<br></div><div><div>-Darius</div></div><div><br></div><div>PS- @Burke, if the doctor \
is going to be writing the order in the form of a dilution, then it saves them \
significant effort to give them a purpose-built UI. And once you've done that, if \
you want to support an "Edit" use case, then it's probably less dev \
effort to store coded values in the first place, than to deal with parsing them back \
out of free text. (Once Order Sets are implemented, and an implementation has enough \
of these pre-codified, the calculus could change. But OpenMRS doesn't support \
these today.)<br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div \
class="gmail_quote">On Wed, Aug 27, 2014 at 8:43 AM, Burke Mamlin <span \
dir="ltr"><<a href="mailto:burke@openmrs.org" \
target="_blank">burke@openmrs.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">That's correct. If you need the diluent \
to be codified, then it would require a different (new, not-yet-existent) dosing \
instruction type and, as Darius suggests, a generic InfusionDosingInstructions would \
be preferable to one that is case-specific.<div>
<br></div><div>That said, not everything needs to be codified. Codifying data \
unncessarily can add costs of extra input fields, programming efforts, and content \
maintenance without any benefit. In general, data that just needs to be redisplayed \
or printed elsewhere does not need to be codified for the computer to understand. \
If you are codifying diluents "because you can" or because you can imagine \
a situation in which someday it might be useful to someone, I would take a moment to \
step back and look at your actual requirements. If diluent usage is supposed to \
drive automatic inventory updates or drive a robotic arm to prepare the infusion, \
then codifying will be useful. If you just need to be able to regurgitate the text \
that someone entered, then codifying diluent is adding structure (at a real cost) \
where it is not needed.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>-Burke</div></div><div \
class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div \
class="gmail_quote">On Wed, Aug 27, 2014 at 11:03 AM, Darius Jazayeri <span \
dir="ltr"><<a href="mailto:darius@openmrs.org" \
target="_blank">darius@openmrs.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">My expectation was that for something like \
this, you would introduce a new DosingInstructions type. You wouldn't want that \
to be cancer-specific, but rather it would be "Infusion", along the lines \
of Jonathan's screenshot.<div>
<br></div><div>This would let you capture coded values (probably via json in a big \
text field in the database) as Mike suggests.<span><font \
color="#888888"><br><div><br></div><div>-Darius</div></font></span></div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Aug 27, 2014 at 7:55 AM, Hannan, Terry J (DHHS) <span dir="ltr"><<a \
href="mailto:Terry.Hannan@dhhs.tas.gov.au" \
target="_blank">Terry.Hannan@dhhs.tas.gov.au</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div dir="auto">
<div>Mike, is there any 'evaluation' or 'guide' for your 1-2n years \
of effort? Terry<br> <br>
Sent from my iPad</div><div>
<div><br>
On 27 Aug 2014, at 5:52 pm, "Michael Seaton" <<a \
href="mailto:mseaton@pih.org" target="_blank">mseaton@pih.org</a>> wrote:<br> <br>
</div>
</div><blockquote type="cite">
<div><div>
Thanks all,<br>
<br>
Our team in Rwanda spent considerable time a few years ago trying to support Oncology \
order entry on top of the legacy drug order data model, and have been using it for \
managing complex chemotherapy regimens in the system there for 1-2 years now. The \
lions share of the work around this ended up in the <a \
href="https://github.com/openmrs/openmrs-module-orderextension" target="_blank"> \
orderextension module</a>. Although I no longer hold out any hope that this will \
inform any of our decisions around order entry, I am still hoping that it will be a \
useful reference and/or strawman for order groups, order sets, and new user interface \
designs for drug order entry screens.<br>
<br>
My general feeling is that I would be fine using things like administration \
instructions and/or dosing instructions for this, but we need to be able to reliably \
parse these into objects that can be used to back the sort of user interfaces that \
Jonathan shows below. So we need to be able to ensure that the design \
unambiguously distinguishes between what are free-text administration instructions \
and what are structured administration instructions stored in a free-text field. \
Hopefully the design already accounts for this?<br>
<br>
Cheers,<br>
Mike<br>
<br>
<br>
<br>
-----Original Message-----<br>
<b>From</b>: Jonathan Teich <<a \
href="mailto:Jonathan%20Teich%20%3cjmteich@gmail.com%3e" \
target="_blank">jmteich@gmail.com</a>><br>
Reply-to: <<a href="mailto:dev@openmrs.org" \
target="_blank">dev@openmrs.org</a>><br> <b>To</b>: <a \
href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a> <<a \
href="mailto:%22dev@openmrs.org%22%20%3cdev@openmrs.org%3e" \
target="_blank">dev@openmrs.org</a>>, <a href="mailto:burke@openmrs.org" \
target="_blank">burke@openmrs.org</a> <<a \
href="mailto:%22burke@openmrs.org%22%20%3cburke@openmrs.org%3e" \
target="_blank">burke@openmrs.org</a>><br> <b>Cc</b>: bahmni <<a \
href="mailto:bahmni%20%3cbahmni@thoughtworks.com%3e" \
target="_blank">bahmni@thoughtworks.com</a>><br> <b>Subject</b>: Re: Drug Orders \
for Cancer<br> <b>Date</b>: Wed, 27 Aug 2014 09:59:52 -0400<br>
<br>
This makes perfect sense for the current system capabilities. <br>
<br>
Going forward, a medication infusion has its own commonly used specific fields, if we \
ever choose to go there: <br>
<br></div><div><div>
<image.jpeg><br>
<br>
There's a little more optimization that can be done to the fields above, but this \
is pretty close. <br>
Jonathan <br>
On Aug 27, 2014, at 9:21 AM, Burke Mamlin <<a href="mailto:burke@openmrs.org" \
target="_blank">burke@openmrs.org</a>> wrote:<br> <br>
<br>
<blockquote type="CITE">On Wed, Aug 27, 2014 at 4:21 AM, Shruthi Dipali <<a \
href="mailto:shruthidipali@gmail.com" target="_blank">shruthidipali@gmail.com</a>> \
wrote: </blockquote>
<blockquote type="CITE">
<blockquote>Hi, </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>For Chemotherapy, we may need to capture some of the following \
information with Drug Orders. </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>- Diluent e.g. Give Ondansetron with 100ml Sodium Chloride 0.9% \
</blockquote> </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">Diluent would be mentioned within administration \
instructions. For example: </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">Drug = Ondansetron </blockquote>
<blockquote type="CITE">Simple Dosing Instructions </blockquote>
<blockquote type="CITE">
<blockquote>Dose+units = 8 mg<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>Route = IV </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>Frequency = Once </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>Administration instructions = give with 100ml Sodium Chloride 0.9% over \
15 minutes at least 30 minutes prior to chemotherapy </blockquote>
</blockquote>
<blockquote type="CITE"> </blockquote>
<blockquote type="CITE">
<blockquote>- Duration of administration. e.g. give this IV for 45 minutes \
</blockquote> </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">Duration can be codified within Simple Dosing Instructions \
Duration+Units or can be non-codified in Simple Dosing Instructions Administration \
Instructions or in Free Text Instructions. </blockquote>
<blockquote type="CITE"> </blockquote>
<blockquote type="CITE">
<blockquote>- Stage in which to administer. e.g. pre-chemo, post-chemo \
</blockquote> </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">Since these refer to timing, they could technically be \
additional urgency values; however, since they are very specific to chemotherapy, we \
would put these into administration instructions (as in my example above). \
</blockquote> <blockquote type="CITE"> <br>
<br>
</blockquote>
<blockquote type="CITE">
<blockquote><br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>How can we incorporate this into the current DrugOrder model? \
</blockquote> </blockquote>
<blockquote type="CITE">
<blockquote><br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><font color="#888888">-Shruthi</font> </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><font color="#888888">-- </font><br>
<font color="#888888">OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a></font><br> <font color="#888888">Post: \
<a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a> | Unsubscribe: \
<a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a></font><br> <font \
color="#888888">Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/" target="_blank"> https://id.openmrs.org/</a></font> \
</blockquote> </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a> | \
Unsubscribe: <a href="mailto:dev+unsubscribe@openmrs.org" target="_blank"> \
dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> <br>
<br>
To unsubscribe from this group and stop receiving emails from it, send an email to
<a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a>.<br> <br>
</blockquote>
<br>
<br>
<p></p>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a> | \
Unsubscribe: <a href="mailto:dev+unsubscribe@openmrs.org" target="_blank"> \
dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> \
<p></p> To unsubscribe from this group and stop receiving emails from it, send an \
email to <a href="mailto:dev+unsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a>.<br> </div></div></div>
</blockquote>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
CONFIDENTIALITY NOTICE AND DISCLAIMER<br>
The information in this transmission may be confidential and/or protected by legal \
professional privilege, and is intended only for the person or persons to whom it is \
addressed. If you are not such a person, you are warned that any disclosure, copying \
or dissemination of the information is unauthorised. If you have received the \
transmission in error, please immediately contact this office by telephone, fax or \
email, to inform us of the error and to enable arrangements to be made for the \
destruction of the transmission, or its return at our cost. No liability is accepted \
for any unauthorised use of the information contained in this transmission.<br> \
</font> </div><div><div>
<p></p>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a> | \
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> \
</div></div></blockquote></div><br></div> </div></div></blockquote></div><br></div>
<p></p>
-- <br>
OpenMRS Developers: <a href="http://go.openmrs.org/dev" \
target="_blank">http://go.openmrs.org/dev</a><br>
Post: <a href="mailto:dev@openmrs.org" target="_blank">dev@openmrs.org</a> | \
Unsubscribe: <a href="mailto:dev%2Bunsubscribe@openmrs.org" \
target="_blank">dev+unsubscribe@openmrs.org</a><br> Manage your OpenMRS subscriptions \
at <a href="https://id.openmrs.org/" target="_blank">https://id.openmrs.org/</a><br> \
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
OpenMRS Developers: <a \
href="http://go.openmrs.org/dev">http://go.openmrs.org/dev</a><br />
Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org<br />
Manage your OpenMRS subscriptions at <a \
href="https://id.openmrs.org/">https://id.openmrs.org/</a><br />
<p></p>
To unsubscribe from this group and stop receiving emails from it, send an email to <a \
href="mailto:dev+unsubscribe@openmrs.org">dev+unsubscribe@openmrs.org</a>.<br />
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic