[prev in list] [next in list] [prev in thread] [next in thread]
List: openmrs-dev
Subject: Re: Mapping a Test in OpenMRS used as a terminology server for broadcast
From: "'Andrew Kanter' via OpenMRS Developers" <dev () openmrs ! org>
Date: 2014-08-26 6:00:58
Message-ID: 1409032858.25009.YahooMailNeo () web163806 ! mail ! gq1 ! yahoo ! com
[Download RAW message or body]
I tend to favor Darius' approach here, but the point is that there are different use \
cases. The clinician doing the ordering may see one concept which should have enough \
clinical granularity to allow it to be defined for ordering. The performance of the \
lab should have specific metadata sufficient to allow it to map to a single LOINC \
code. That may be what is reported, but typically a single order may be broken up \
into separate components, each with a separate result and separate LOINC code. \
Finally, what get's documented is another use case where many different LOINCs might \
be brought together for display purposes but still not be equivalent to the thing \
which is ordered. A CBC is one example of that.
The CIEL dictionary makes some of those distinctions. I direct folks to IMO for \
Procedure IT for fully exploded Orderable/performable/chargeable/reportable \
documentation.
Of note, in the US for quality reporting and interoperability, it is necessary to map \
results at the fully-specified LOINC code level where the concepts are SAME-AS to \
LOINC codes.
Andy
--------------------
Andrew S. Kanter, MD MPH FACMI
Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University
Email: andrew.kanter@dbmi.columbia.edu
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter
On Tuesday, August 26, 2014 12:22 AM, Darius Jazayeri <darius@openmrs.org> wrote:
>
>
> As Burke says, the typical OpenMRS approach is for the concept to be an \
> end-user-friendly interface term, that's mapped to an (ugly-named) LOINC term.
>
> You're intending for the OpenMRS concept to contain all the information required \
> for a downstream system (LIMS in this case) to create its internal representation \
> of the test. (I presume Burke would say this is the wrong approach and really the \
> LIMS system should see the incoming concept, and use its reference term to look up \
> the true meaning in LOINC.)
>
> If you do want the downstream system to generate its internal data based entirely \
> on what the OpenMRS terminology server broadcasts, I would not want the client to \
> have to parse these out of a string. But #2 feels wrong to me. I \
> would instead say:
> * the name of the concept shouldn't just be WBC but rather something \
> fully-specified
> * Instead of using set members, use mappings on the concept representing the test, \
> where the map type gives the meaning, and the reference term is the LOINC value \
> set. E.g. take a look at the concept_map_type table, including all the rows marked \
> as hidden, which include things like "specimen source identity", "time aspect", and \
> "scale type". So in this case (and don't take this as the literal correct answer \
> since I'm outside my area of expertise here) your concept would be:
> Name: Leukocytes [#/volume] in Cerebral spinal fluid by Manual count (which is the \
> Long Common Name as par LOINC)
> > Mapping: "SAME-AS" "LOINC" "806-0"
> > Mapping: "Specimen substance" "BD Specimen Type" "Cerebral Spinal Fluid"
> > Mapping: "Time Aspect" "BD Time Aspects" "Point in time"
> > etc
>
>
> (I imagine there's an external terminology you'd use to define your specimen types, \
> time aspects, etc, unlike what I typed above.)
>
> -Darius
>
>
>
> On Mon, Aug 25, 2014 at 9:39 PM, Burke Mamlin <burke@openmrs.org> wrote:
>
> I would create a concept (interface term) like "White Blood Cell Count (CSF)" \
> mapped to the reference term you describe:
> >
> >
> > source = "LOINC", code = 806-0, Name = "Leukocytes: NCnc: Pt: CSF: Qn: Manual \
> > count"
> >
> > The "806-0" would uniquely identify the term within LOINC and the components \
> > entered in the reference term's name would be for convenience. The source of \
> > truth for these values remaining with LOINC (i.e., any discrepancy between your \
> > reference term name & the official LOINC term, LOINC would, of course, win).
> >
> > Cheers,
> >
> >
> > -Burke
> >
> >
> >
> > On Sat, Aug 23, 2014 at 3:07 PM, Angshuman Sarkar <angshuonline@gmail.com> wrote:
> >
> > Hi Burke, Darius, Andrew,
> > >
> > > As you know, we are using OpenMRS (only concept Management aspects) as \
> > > Terminology Server for Bangladesh SHR Project. We would like to define tests \
> > > and panels therein. We have also decided to adopt LOINC as the coding standard. \
> > >
> > >
> > > Tests/Panels are broadcasted as feeds for consumption for client systems that \
> > > include PoS like Hospital Facilities, Labs etc.
> > >
> > > Lets take an example of a Lab system like OpenELIS. OpenELIS will listen to the \
> > > feed for such test definition and create a test at its local instance. Or it \
> > > may map an existing test to the server's LOINC code. While communicating the \
> > > test results to the server, the lab system will use the LOINC code to specify \
> > > the results are for which tests.
> > >
> > > Under such circumstances, we need to define the Test Properties/Attributes at \
> > > the server, which will help in mapping to the local tests (create or map).
> > >
> > > We have found that LOINC Fully specified name consists of 5 such parts which \
> > > consistently/universally define a test name.
> > >
> > > <component/analyte>:<kind of property>:<time aspect>:<system \
> > > type>:<scale>:<method>
> > >
> > > How do you suggest that we define that using OpenMRS?
> > >
> > >
> > > I have thought about 2 approaches. Lets take example of "White blood Cell" \
> > > (WBC)
> > >
> > > 1) Define the FSN as part of the reference term's name.
> > >
> > >
> > > a) Define a reference term as below
> > > * source = "LOINC", code = 806-0, Name = "Leukocytes: NCnc: Pt: CSF: Qn: \
> > > Manual count"
> > >
> > > NOTE: The Name corresponds to the FSN of WBC (Leukocytes) as defined in LOINC, \
> > > where
> > >
> > > > Component (Analyte) = Leukocytes (white blood cells)
> > > > Property = NCnc (Number concentration)
> > > > Time = Pt (Point in time)
> > > > System (Specimen) = CSF (Cerebral spinal fluid)
> > > > Scale = Qn (Quantitative)
> > > > Method = Manual Count
> > >
> > >
> > >
> > >
> > > b) Define a concept of class "test" with datatype Numeric with units = /uL
> > > Name = Leukocytes [#/volume] in Cerebral spinal fluid by Manual count (which is \
> > > the Long Common Name as par LOINC) Synonym = WBC # CSF Manual (Short Name as \
> > > part LOINC)
> > >
> > > And map the concept to the reference term defined above.
> > >
> > >
> > > Alternatively,
> > >
> > >
> > > 2) Define "WBC" as a concept, which is a set, with members defining the \
> > > attributes a) Define a reference term as below
> > > source = "LOINC", code = 806-0, Name = "Leukocytes: NCnc: Pt: CSF: Qn: Manual \
> > > count" b) i) Define a concept of class "test" with datatype Numeric with units \
> > > = /uL Name = Leukocytes [#/volume] in Cerebral spinal fluid by Manual count \
> > > (which is the Long Common Name as par LOINC) Synonym = WBC # CSF Manual (Short \
> > > Name as part LOINC)
> > > ii) Define the concept as a set, and add "Leukocytes", "NCnc", "Point in \
> > > time", "CSF", "QN", "Manual Count" as members. We would have already defined \
> > > the above members as concept earlier, and to be explicit against specified \
> > > concept classes of "test-component", "test-property", "test-time", \
> > > "test-system", "test-scale", "test-method".
> > >
> > > In both the approaches, we can define LOINC FSN as reference term name, Loinc \
> > > LCN as concept name, and LOINC short Name as concept synonym. In first \
> > > approach, we don't need to define the concept as a set, and the lab system \
> > > would parse the LOINC FSN to create or map to local concept.
> > >
> > > What would you suggest the right approach be?
> > >
> > >
> > >
> > >
> > > Thanks and regards
> > > ~angshu
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > 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.
>
>
--
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)]
<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, \
Helvetica Neue, Helvetica, Arial, Lucida Grande, \
sans-serif;font-size:14pt"><div><span>I tend to favor Darius' approach here, but the \
point is that there are different use cases. The clinician doing the ordering may see \
one concept which should have enough clinical granularity to allow it to be defined \
for ordering. The performance of the lab should have specific metadata sufficient to \
allow it to map to a single LOINC code. That may be what is reported, but typically a \
single order may be broken up into separate components, each with a separate result \
and separate LOINC code. Finally, what get's documented is another use case where \
many different LOINCs might be brought together for display purposes but still not be \
equivalent to the thing which is ordered. A CBC is one example of \
that.</span></div><div style="color: rgb(0, 0, 0); font-size: 19px; font-family: \
HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; \
background-color: transparent; font-style: normal;"><span><br></span></div><div \
style="color: rgb(0, 0, 0); font-size: 19px; font-family: HelveticaNeue, 'Helvetica \
Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; \
font-style: normal;"><span>The CIEL dictionary makes some of those distinctions. I \
direct folks to IMO for Procedure IT for fully exploded \
Orderable/performable/chargeable/reportable documentation.</span></div><div \
style="color: rgb(0, 0, 0); font-size: 19px; font-family: HelveticaNeue, 'Helvetica \
Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; \
font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); \
font-size: 19px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, \
'Lucida Grande', sans-serif; background-color: transparent; font-style: \
normal;"><span>Of note, in the US for quality reporting and interoperability, it is \
necessary to map results at the fully-specified LOINC code level where the concepts \
are SAME-AS to LOINC codes.</span></div><div style="color: rgb(0, 0, 0); font-size: \
19px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida \
Grande', sans-serif; background-color: transparent; font-style: \
normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 19px; \
font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', \
sans-serif; background-color: transparent; font-style: \
normal;"><span>Andy</span></div><div></div><div> </div><div><b>-------------------- \
<br>Andrew S. Kanter, MD MPH FACMI<br><span class="Apple-style-span" \
style="font-weight:normal;"><b><br></b></span></b></div><div style="color: rgb(0, 0, \
0); font-size: 13px; font-family: arial, helvetica, clean, sans-serif; \
background-color: transparent; font-style: normal;">Asst. Prof. of Clinical \
Biomedical Informatics and Clinical Epidemiology<br></div><div style="color: rgb(0, \
0, 0); font-size: 13px; background-color: transparent; font-style: normal; \
font-family: arial, helvetica, clean, sans-serif;">Columbia University<br>Email: \
andrew.kanter@dbmi.columbia.edu <br>Mobile: +1 (646) 469-2421<br>Office: +1 (212) \
305-4842<br>Skype: akanter-ippnw<br>Yahoo: andy_kanter</div> <div \
class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: \
block;"> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, \
'Lucida Grande', sans-serif; font-size: 14pt;"> <div style="font-family: \
HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; \
font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> On Tuesday, August \
26, 2014 12:22 AM, Darius Jazayeri <darius@openmrs.org> wrote:<br> </font> \
</div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; \
margin-top: 5px; padding-left: 5px;"> <br><br> <div class="y_msg_container"><div \
id="yiv9307983601"><div><div dir="ltr">As Burke says, the typical OpenMRS approach is \
for the concept to be an end-user-friendly interface term, that's mapped to an \
(ugly-named) LOINC term.<div><br clear="none"></div><div>You're intending for the \
OpenMRS concept to contain all the information required for a downstream system (LIMS \
in this case) to create its internal representation of the test. (I presume Burke \
would say this is the wrong approach and really the LIMS system should see the \
incoming concept, and use its reference term to look up the true meaning in \
LOINC.)</div>
<div><br clear="none"></div><div>If you do want the downstream system to generate its \
internal data based entirely on what the OpenMRS terminology server broadcasts, I \
would not want the client to have to parse these out of a string. But #2 feels wrong \
to me. I would instead say:</div>
<div><ul><li>the name of the concept shouldn't just be WBC but rather something \
fully-specified</li><li>Instead of using set members, use mappings on the concept \
representing the test, where the map type gives the meaning, and the reference term \
is the LOINC value set. E.g. take a look at the concept_map_type table, including all \
the rows marked as hidden, which include things like "specimen source identity", \
"time aspect", and "scale type".</li></ul></div><div>So in this case (and don't take \
this as the literal correct answer since I'm outside my area of expertise here) your \
concept would be:</div><blockquote style="margin:0 0 0 \
40px;border:none;padding:0px;">
<div>Name: <span style="font-family: arial, sans-serif; font-size: \
13px;">Leukocytes [#/volume] in Cerebral spinal fluid by Manual count (which is the \
Long Common Name as par LOINC)</span></div><div><span style="font-family: arial, \
sans-serif; font-size: 13px;">Mapping: "SAME-AS" "LOINC" "</span><span \
style="font-family: arial, sans-serif; font-size: 13px;">806-0"</span></div>
<div><span style="font-family: arial, sans-serif; font-size: 13px;">Mapping: \
"Specimen substance" "BD Specimen Type" "Cerebral Spinal \
Fluid"</span></div><div><span style="font-family: arial, sans-serif; font-size: \
13px;">Mapping: "Time Aspect" "BD Time Aspects" "Point in time"</span></div>
<div><span style="font-family: arial, sans-serif; font-size: \
13px;">etc</span></div></blockquote><div><span style="font-family: arial, sans-serif; \
font-size: 13px;"><br clear="none"></span></div><div><span style="font-family: arial, \
sans-serif; font-size: 13px;">(I imagine there's an external terminology you'd use to \
define your specimen types, time aspects, etc, unlike what I typed \
above.)</span></div>
<div><br clear="none"></div><div><div><div>-Darius</div></div></div></div><div \
class="yiv9307983601gmail_extra"><br clear="none"><br clear="none"><div \
class="yiv9307983601gmail_quote">On Mon, Aug 25, 2014 at 9:39 PM, Burke Mamlin <span \
dir="ltr"><<a rel="nofollow" shape="rect" ymailto="mailto:burke@openmrs.org" \
target="_blank" href="mailto:burke@openmrs.org">burke@openmrs.org</a>></span> \
wrote:<br clear="none">
<blockquote class="yiv9307983601gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"><div dir="ltr">I would create a concept (interface \
term) like "White Blood Cell Count (CSF)" mapped to the reference term you \
describe:<div class="yiv9307983601">
<div><br clear="none"></div><blockquote class="yiv9307983601gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
source = "LOINC", code = 806-0, Name = "Leukocytes: NCnc: Pt: CSF: Qn: Manual \
count"</blockquote><div><br clear="none"></div></div><div>The "806-0" would uniquely \
identify the term within LOINC and the components entered in the reference term's \
name would be for convenience. The source of truth for these values remaining \
with LOINC (i.e., any discrepancy between your reference term name & the official \
LOINC term, LOINC would, of course, win).</div>
<div><br clear="none"></div><div>Cheers,</div><div><br \
clear="none"></div><div>-Burke </div></div><div class="yiv9307983601HOEnZb"><div \
class="yiv9307983601h5"><div class="yiv9307983601gmail_extra"><br clear="none"><br \
clear="none"><div class="yiv9307983601gmail_quote">On Sat, Aug 23, 2014 at 3:07 PM, \
Angshuman Sarkar <span dir="ltr"><<a rel="nofollow" shape="rect" \
ymailto="mailto:angshuonline@gmail.com" target="_blank" \
href="mailto:angshuonline@gmail.com">angshuonline@gmail.com</a>></span> wrote:<br \
clear="none">
<blockquote class="yiv9307983601gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"><div dir="ltr"><div><div>Hi Burke, Darius, \
Andrew,</div><div> </div><div>As you know, we are using OpenMRS (only concept \
Management aspects) as Terminology Server for Bangladesh SHR Project. We would like \
to define tests and panels therein. We have also decided to adopt LOINC as the coding \
standard. </div>
<div><br clear="none"></div><div>Tests/Panels are broadcasted as feeds for \
consumption for client systems that include PoS like Hospital Facilities, Labs \
etc. </div><div><br clear="none"></div><div>Lets take an example of a Lab system \
like OpenELIS. OpenELIS will listen to the feed for such test definition and create a \
test at its local instance. Or it may map an existing test to the server's LOINC \
code. While communicating the test results to the server, the lab system will use the \
LOINC code to specify the results are for which tests.</div>
<div><br clear="none"></div><div>Under such circumstances, we need to define the Test \
Properties/Attributes at the server, which will help in mapping to the local \
tests (create or map). </div><div><br clear="none"></div><div>We have found that \
LOINC Fully specified name consists of 5 such parts which consistently/universally \
define a test name. </div>
<div><br clear="none"></div><div><component/analyte>:<kind of \
property>:<time aspect>:<system \
type>:<scale>:<method></div><div><br clear="none"></div><div>How do \
you suggest that we define that using OpenMRS?</div>
<div><br clear="none"></div><div>I have thought about 2 approaches. Lets take example \
of "White blood Cell" (WBC)</div><div><br clear="none"></div><div>1) Define the FSN \
as part of the reference term's name. </div><div><br clear="none"></div><div>
a) Define a reference term as below</div><div> * source = "LOINC", code = \
806-0, Name = "Leukocytes: NCnc: Pt: CSF: Qn: Manual count"</div><div><br \
clear="none"></div><div>NOTE: The Name corresponds to the FSN of WBC (Leukocytes) as \
defined in LOINC, where</div>
<div><br clear="none"></div><div>> Component (Analyte) = Leukocytes (white blood \
cells)</div><div>> Property = NCnc (Number concentration)</div><div>> Time = Pt \
(Point in time)</div><div>> System (Specimen) = CSF (Cerebral spinal fluid)</div>
<div>> Scale = Qn (Quantitative)</div><div>> Method = Manual \
Count</div><div><br clear="none"></div><div><br clear="none"></div><div>b) Define a \
concept of class "test" with datatype Numeric with units = /uL</div><div>Name = \
Leukocytes [#/volume] in Cerebral spinal fluid by Manual count (which is the Long \
Common Name as par LOINC)</div>
<div>Synonym = WBC # CSF Manual (Short Name as part LOINC)</div><div><br \
clear="none"></div><div>And map the concept to the reference term defined \
above. </div><div><br clear="none"></div><div>Alternatively,</div><div><br \
clear="none"></div><div>2) Define "WBC" as a concept, which is a set, with members \
defining the attributes</div>
<div> a) Define a reference term as below</div><div> source = \
"LOINC", code = 806-0, Name = "Leukocytes: NCnc: Pt: CSF: Qn: Manual \
count"</div><div> b) i) Define a concept of class "test" with datatype Numeric \
with units = /uL</div>
<div> Name = Leukocytes [#/volume] in Cerebral spinal fluid by Manual \
count (which is the Long Common Name as par LOINC)</div><div> Synonym = \
WBC # CSF Manual (Short Name as part LOINC)</div><div> </div><div> \
ii) Define the concept as a set, and add "Leukocytes", "NCnc", "Point in \
time", "CSF", "QN", "Manual Count" as members. </div>
<div> We would have already defined the above members as concept earlier, \
and to be explicit against specified concept classes of "test-component", \
"test-property", "test-time", "test-system", "test-scale", "test-method". \
</div>
<div><br clear="none"></div><div>In both the approaches, we can define LOINC FSN as \
reference term name, Loinc LCN as concept name, and LOINC short Name as concept \
synonym. </div><div>In first approach, we don't need to define the concept as a \
set, and the lab system would parse the LOINC FSN to create or map to local \
concept.</div>
<div><br clear="none"></div><div>What would you suggest the right approach \
be?</div><div><br clear="none"></div><div><br clear="none"></div><div>Thanks and \
regards</div><div>~angshu</div><span><font color="#888888"></font></span><div><br \
clear="none"></div><div><br clear="none"></div>
<div> </div><div><br clear="none"></div><div><br clear="none"></div>
<div><br clear="none"></div></div></div><span><font color="#888888">
</font></span>
-- <br clear="none">
OpenMRS Developers: <a rel="nofollow" shape="rect" target="_blank" \
href="http://go.openmrs.org/dev">http://go.openmrs.org/dev</a><br \
clear="none">
Post: <a rel="nofollow" shape="rect" ymailto="mailto:dev@openmrs.org" target="_blank" \
href="mailto:dev@openmrs.org">dev@openmrs.org</a> | Unsubscribe: <a rel="nofollow" \
shape="rect" ymailto="mailto:dev%2Bunsubscribe@openmrs.org" target="_blank" \
href="mailto:dev%2Bunsubscribe@openmrs.org">dev+unsubscribe@openmrs.org</a><br \
clear="none"> Manage your OpenMRS subscriptions at <a rel="nofollow" shape="rect" \
target="_blank" href="https://id.openmrs.org/">https://id.openmrs.org/</a><div \
class="yiv9307983601yqt9989687127" id="yiv9307983601yqtfd40901"><br clear="none"> \
</div></blockquote></div><div class="yiv9307983601yqt9989687127" \
id="yiv9307983601yqtfd44335"><br clear="none"></div></div><div \
class="yiv9307983601yqt9989687127" id="yiv9307983601yqtfd19369">
-- <br clear="none">
OpenMRS Developers: <a rel="nofollow" shape="rect" target="_blank" \
href="http://go.openmrs.org/dev">http://go.openmrs.org/dev</a><br \
clear="none">
Post: <a rel="nofollow" shape="rect" ymailto="mailto:dev@openmrs.org" target="_blank" \
href="mailto:dev@openmrs.org">dev@openmrs.org</a> | Unsubscribe: <a rel="nofollow" \
shape="rect" ymailto="mailto:dev%2Bunsubscribe@openmrs.org" target="_blank" \
href="mailto:dev%2Bunsubscribe@openmrs.org">dev+unsubscribe@openmrs.org</a><br \
clear="none"> Manage your OpenMRS subscriptions at <a rel="nofollow" shape="rect" \
target="_blank" href="https://id.openmrs.org/">https://id.openmrs.org/</a><br \
clear="none"> </div></div></div></blockquote></div><div \
class="yiv9307983601yqt9989687127" id="yiv9307983601yqtfd75673"><br \
clear="none"></div></div><div class="yiv9307983601yqt9989687127" \
id="yiv9307983601yqtfd57625">
-- <br clear="none">
OpenMRS Developers: <a rel="nofollow" shape="rect" target="_blank" \
href="http://go.openmrs.org/dev">http://go.openmrs.org/dev</a><br \
clear="none">
Post: dev@openmrs.org | Unsubscribe: dev+unsubscribe@openmrs.org<br clear="none">
Manage your OpenMRS subscriptions at <a rel="nofollow" shape="rect" target="_blank" \
href="https://id.openmrs.org/">https://id.openmrs.org/</a><br clear="none">
To unsubscribe from this group and stop receiving emails from it, send an email to <a \
rel="nofollow" shape="rect" ymailto="mailto:dev+unsubscribe@openmrs.org" \
target="_blank" href="mailto:dev+unsubscribe@openmrs.org">dev+unsubscribe@openmrs.org</a>.<br \
clear="none"></div></div></div><br><br></div> </blockquote> </div> </div> </div> \
</div></body></html>
<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