Re: [openhealth] Re: Hi folks..

[Thomas Beale]

Nandalal Gunaratne wrote:
> Thank you Thomas. This is not urinalysis but urea and
> electrolytes! 
>
> What is the "Any Result" "data type is not set" doing
> here. It is, after all, urea and electrolytes, and the
> electrolytes are mentioned. Is this to leave room for
> rare electrolytes like the level of copper in the
> blood or iron?
>
>   
yes sorry, my mind wandered after I realised we hadn't posted a 
urinalysis result as such. "Any result" is just a placeholder name in an 
archetype for "new items" that might be added at runtime, i.e. if a 
different protein needed to be added. This is one of the things that 
allows data capture to go beyond the explicitly stated things in an 
archetype at runtime. The data type will be determined at runtime (must 
inherit from DATA_VALUE, due to the reference model).

- thomas

Re: [openhealth] Re: Hi folks..

[Thomas Beale]

Paul wrote:
>
> A wise quote that I heard when I started medical informatics training
> was "a lot of what we practice today is wrong."  I'm a pediatrician,
> and I can attest to this... and because of the constant evolution in
> best practices, there's always a "scattergram" of practice styles vs.
> best practices.  That is, the urinalysis today, might not be the
> urinalysis of tomorrow.  Some might continue to use the old urinalysis
> for a number of various reasons, and some of those reasons might be
> correct.  Therefore, there arise various flavors and colors of a single
> "archetype" that I think I understand represent models of how certain
> care is delivered.  These coexisting vagaries and various evolutions
> of medical concepts unfortunately I think are a necessary reality of
> health information system design.
>   
Yes, things change all the time. Archetypes are designed flexibly as 
'maximal data sets' that collect related data items together. See e.g. 
the BP measurement archetype: 
http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.blood_pressure.v1.html.
 
Within a template only a couple of items might actually be used, but no 
matter how many are, one can be sure they respect the archetype 
structure. This means as a consequence that the data are all queryable 
in a standard way, using the extracted archetype paths (I have shown the 
human readable versions):

/data[history]/events[baseline reading]/data[blood 
pressure]/items[systolic]/value DV_QUANTITY
/data[history]/events[baseline reading]/data[blood 
pressure]/items[diastolic]/value DV_QUANTITY
/data[history]/events[baseline reading]/data[blood 
pressure]/items[Comment]/value DV_TEXT
/data[history]/events[baseline reading]/data[blood pressure]/items[mean 
arterial pressure]/value DV_QUANTITY
/data[history]/events[baseline reading]/data[blood pressure]/items[pulse 
pressure]/value DV_QUANTITY
/data[history]/events[baseline reading]/offset/value DURATION
/data[history]/events[baseline reading]/state[state 
structure]/items[Position]/value/defining_code CODE_PHRASE
/data[history]/events[baseline reading]/state[state 
structure]/items[Exertion level]/value DV_QUANTITY
/data[history]/events[baseline reading]/state[state 
structure]/items[Exercise]/value/defining_code CODE_PHRASE
/data[history]/events[baseline reading]/state[state 
structure]/items[Tilt]/value DV_QUANTITY
/data[history]/events[any event]/data[blood 
pressure]/items[systolic]/value DV_QUANTITY
/data[history]/events[any event]/data[blood 
pressure]/items[diastolic]/value DV_QUANTITY
/data[history]/events[any event]/data[blood 
pressure]/items[Comment]/value DV_TEXT
/data[history]/events[any event]/data[blood pressure]/items[mean 
arterial pressure]/value DV_QUANTITY
/data[history]/events[any event]/data[blood pressure]/items[pulse 
pressure]/value DV_QUANTITY
/data[history]/events[any event]/state[state 
structure]/items[Position]/value/defining_code CODE_PHRASE
/data[history]/events[any event]/state[state structure]/items[Exertion 
level]/value DV_QUANTITY
/data[history]/events[any event]/state[state 
structure]/items[Exercise]/value/defining_code CODE_PHRASE
/data[history]/events[any event]/state[state 
structure]/items[Tilt]/value DV_QUANTITY

.. etc ..

/protocol[list structure]/items[Cuff size]/value/defining_code CODE_PHRASE
/protocol[list structure]/items[Location of 
measurement]/value/defining_code CODE_PHRASE

This standardised querying is one of the things that is most powerful 
about archetypes - no matter what template the data were captured in, it 
is the original archetype that determines the query paths. Actual 
queries look as follows:

SELECT
o/data[at0001]/events[at0002]/time,
o/data[at0001]/events[at0002]/data[at0003]/items[at0013.1]/value -- 
Total cholesterol
FROM
[EMAIL PROTECTED] CONTAINS
Composition c[openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS
Observation o[openEHR-EHR-OBSERVATION.laboratory-lipids.v1]


These archetypes do evolve; as long as they obey the basic terminology 
principle of not-redefining the meaning of existing items, everything 
works automatically.

- thomas beale

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Paul wrote:
> Heya Tim,
> 
> --- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote:
> 
>> Yes, it seems to me that openEHR as it stands is an interesting and
>> potentially useful technical advance which permits greater semantic
>> precision and thus may ease the valid interchange of health data, but
>> that there is a whole raft of sociological questions about how it might
>> work in practice which still need to be addressed, and which probably
>> can't be answered until more people start to use it and there is an
>> openEHR "ecosystem" to observe.
>>
>> On the other hand, the Regenstreif/OpenMRS approach is arguably less
>> rigorous, but has still been shown to work very well in practice over
>> many decades, at least at the individual clinic/institute/repository
>> level, but that its utility in a fully federated environment is still
>> being explored.
>>
>> But it is not an either/or situation, and one approach does not need to
>> prevail over the other.
>>
>> Tim C
> 
> One quick clarification.  The database approach OpenMRS utilizes, in
> fact *has* been demonstrated convincingly to work in a federated
> model.  The INPC is one of the only truly operational RHIOs in the
> country, and it's comprised of over 10 federated repositories all built
> on top of this database design.  Collectively, the INPC has over 2
> million patient records, and over 1 billion clinical observations
> stored within it.

Ah, OK, I misunderstood. That's impressive. But when you say "federated
repositories", what exactly do you mean? Are the 10 repositories
free-standing, self-sufficient entities which exchange data with each
other via messages or some other means, or are they "logical
repositories" all running on the one centrally-hosted system/database?

> However, the INPC is not built upon OpenMRS.  It's built on top of the
> RMRS, which was conceptualized in the early 70's.  We're a close
> cousin, open source, modern version of the RMRS model.

Seems like a very good foundation to build on.

Tim C

[openhealth] Re: Hi folks..

[Paul]

--- In openhealth@yahoogroups.com, Will Ross <[EMAIL PROTECTED]> wrote:
>
> Paul,
> 
> See below.
> 
> - - - - - - - -
> 
> Can the OCC be accessed by non-OpenMRS sites?   And, as a corollary,  
> can non-OpenMRS sites contribute to the concept coop?
> 
> Thanks!
> 
> - - - - - - - -

Hi Will,

We certainly anticipate the OCC being a community-wide resource, but
our first priority is to ensure great utility for OpenMRS
implementations.  We currently have a concept builder within our
web-client (see http://demo.openmrs.org to play with it), and we would
like to configure it such that when one builds a new concept that it
allows net connected developers to search against the OCC to first see
if that concept is available.  If it's not, and the end implementation
needs to create it, then we would envision that the app will be
written in such a way as to automatically upload that concept to the
OCC (supporting what is in theory a Creative Commons of concepts). 
Downloads of someone else's concept automatically creates a
terminology "mapping" between that new site and all the other sites
that use it.

We feel strongly that it's a mistake for OpenMRS to become yet another
standardized vocabulary for myriad reasons, but want to allow the
concepts to evolve organically such that most commonly used terms rise
to the top.  If you've ever built clinical vocabularies, you'll
quickly realize that there's great "guesswork" involved in it.  That
is, there are many ways to codify a given concept.  It's fairly simple
to codify something like a hemoglobin, but imagine if your system
needed to example code a child's developmental screen milestone.. like
walking at a year of age.

I could code that in a number of ways.  The question could be: "Walks
at a year of age?" and the answer could be yes or no.  The question
could also be "Motor milestone passed" with an answer of "walks at a
year of age".  Both of those are "right", given how you use the data,
and for a national standard to define that apriori without any real
understanding of how that datum will be used over time, ensures that
some of those initial decisions made by the standards body will be
unhelpful or flat out wrong.  Supporting a cooperative acknowledges
that we don't know the right answer to a given concept's mapping right
now, but we'll create a process that allows the community to figure
that out in a pragmatic way.  Indirectly, when enough people use a
given flavor of a concept, it becomes a standard in and of itself.

Once we augment the content of this cooperative with real world
implementations, then I think it might serve as a valuable exemplar to
the community as a whole when implementers wanted to know how the
community "voted with their feet".

-Paul

[openhealth] Re: Hi folks..

[Paul]

Heya Tim,

--- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote:

> Yes, it seems to me that openEHR as it stands is an interesting and
> potentially useful technical advance which permits greater semantic
> precision and thus may ease the valid interchange of health data, but
> that there is a whole raft of sociological questions about how it might
> work in practice which still need to be addressed, and which probably
> can't be answered until more people start to use it and there is an
> openEHR "ecosystem" to observe.
> 
> On the other hand, the Regenstreif/OpenMRS approach is arguably less
> rigorous, but has still been shown to work very well in practice over
> many decades, at least at the individual clinic/institute/repository
> level, but that its utility in a fully federated environment is still
> being explored.
> 
> But it is not an either/or situation, and one approach does not need to
> prevail over the other.
> 
> Tim C

One quick clarification.  The database approach OpenMRS utilizes, in
fact *has* been demonstrated convincingly to work in a federated
model.  The INPC is one of the only truly operational RHIOs in the
country, and it's comprised of over 10 federated repositories all built
on top of this database design.  Collectively, the INPC has over 2
million patient records, and over 1 billion clinical observations
stored within it.

However, the INPC is not built upon OpenMRS.  It's built on top of the
RMRS, which was conceptualized in the early 70's.  We're a close
cousin, open source, modern version of the RMRS model.

Best,
-Paul

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Nandalal Gunaratne wrote:
> Paul,
> 
> This is a good explanation of what OpenMRS is about,
> and I find it quite refreshing. The problem of
> constraints to allow greater acceptance and "accuracy"
> (OpenEHR) against allowing change as you seem to do to
> allow freedom to improve and grow in new directions, 
> but which can cause confusion and inaccuracy, will
> last forever. The correct path is the middle path.

Yes, it seems to me that openEHR as it stands is an interesting and
potentially useful technical advance which permits greater semantic
precision and thus may ease the valid interchange of health data, but
that there is a whole raft of sociological questions about how it might
work in practice which still need to be addressed, and which probably
can't be answered until more people start to use it and there is an
openEHR "ecosystem" to observe.

On the other hand, the Regenstreif/OpenMRS approach is arguably less
rigorous, but has still been shown to work very well in practice over
many decades, at least at the individual clinic/institute/repository
level, but that its utility in a fully federated environment is still
being explored.

But it is not an either/or situation, and one approach does not need to
prevail over the other.

Tim C

> --- Paul <[EMAIL PROTECTED]> wrote:
> 
>> Hi Thomas,
>>
>> --- In openhealth@yahoogroups.com, Thomas Beale
>> <[EMAIL PROTECTED]> wrote:
>>> Nandalal Gunaratne wrote:
  The power of this approach is hard to
>> appreciate
   
> until you're in a 
> situation where lots of people have lots of
>> things
> they want to 
> characterize in a system.  It allows
>> non-developers
> to own and 
> augment their own notions of what data matters
>> to
> them, without 
> altering the underlying database model.
> 
 This is important for clinicians in different
 specialities with various interests in the
>> specifics.
 No FOSS EMR I tried/used, except OIO, allow this
>> to be
 done easily by users.

 The Concept Dictionary approach seems to be
>> similar to
 the Archetypes approach of OpenEHR, which goes a
 further step.

   
>>> you can see a urinalysis archetype here: 
>>>
> http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.laboratory-urea_and_electrolytes.v1.html
>>> (main page:
> http://svn.openehr.org/knowledge/archetypes/dev/index.html)
>>> - thomas beale
>>>
>> Thanks for the link.  It hasn't worked for me, but
>> I'm familiar enough
>> (I think) to have at least a cursory understanding
>> of what archetypes
>> are.  Probably enough to be dangerous. :)
>>
>> Defining the relative metadata around medical
>> concepts is typically a
>> good thing, and for your work on that I applaud this
>> effort.  However,
>> where I get worried with this approach is in both
>> the vagaries of
>> health care and practice patterns.
>>
>> A wise quote that I heard when I started medical
>> informatics training
>> was "a lot of what we practice today is wrong."  I'm
>> a pediatrician,
>> and I can attest to this... and because of the
>> constant evolution in
>> best practices, there's always a "scattergram" of
>> practice styles vs.
>> best practices.  That is, the urinalysis today,
>> might not be the
>> urinalysis of tomorrow.  Some might continue to use
>> the old urinalysis
>> for a number of various reasons, and some of those
>> reasons might be
>> correct.  Therefore, there arise various flavors and
>> colors of a single
>> "archetype" that I think I understand represent
>> models of how certain
>> care is delivered.  These coexisting vagaries and
>> various evolutions
>> of medical concepts unfortunately I think are a
>> necessary reality of
>> health information system design.
>>
>> What we've attempted to do at Regenstrief (and
>> within OpenMRS for that
>> matter) is to abstract out one level further.  That
>> is, all medical
>> concepts have descriptions, datatypes, "classes",
>> and for a given
>> combination of class, datatype some relative
>> metadata.  For example, a
>> urine pH is a numeric datatype, and a test class. 
>> Therefore, it has
>> metadata such as absolute, critical, and normal
>> ranges, a unit
>> designation, etc etc.  These concepts live in the
>> database right
>> alongside the actual repository of data to serve as
>> a general resource
>> to the entire enterprise.  Any user can populate the
>> database with new
>> concepts, and we're actively working on building a
>> resource, the OCC
>> (OpenMRS Concept Cooperative) to allow for
>> imports/exports of these
>> creations for the use of the entire community.
>>
>> That being said, it's probably a good idea for the
>> community to try
>> something that inherently feels more tightly defined
>> and
>> interoperable.  We however, made the choice based on
>> pragmatics.  That
>> is, the approach I've described has been road tested
>> for a very long
>> time with good success.  We wanted to stack our 

Re: [openhealth] Re: Hi folks..

[Will Ross]

Paul,

See below.

- - - - - - - -

On Feb 20, 2007, at 5:32 AM, Paul wrote:

> Hi Thomas,
>
> --- In openhealth@yahoogroups.com, Thomas Beale <[EMAIL PROTECTED]>  
> wrote:
>>
>> Nandalal Gunaratne wrote:
>>>  The power of this approach is hard to appreciate
>>>
 until you're in a
 situation where lots of people have lots of things
 they want to
 characterize in a system.  It allows non-developers
 to own and
 augment their own notions of what data matters to
 them, without
 altering the underlying database model.

>>>
>>> This is important for clinicians in different
>>> specialities with various interests in the specifics.
>>> No FOSS EMR I tried/used, except OIO, allow this to be
>>> done easily by users.
>>>
>>> The Concept Dictionary approach seems to be similar to
>>> the Archetypes approach of OpenEHR, which goes a
>>> further step.
>>>
>>>
>> you can see a urinalysis archetype here:
>>
> http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR- 
> OBSERVATION.laboratory-urea_and_electrolytes.v1.html
>> (main page: http://svn.openehr.org/knowledge/archetypes/dev/ 
>> index.html)
>>
>> - thomas beale
>>
>
> Thanks for the link.  It hasn't worked for me, but I'm familiar enough
> (I think) to have at least a cursory understanding of what archetypes
> are.  Probably enough to be dangerous. :)
>
> Defining the relative metadata around medical concepts is typically a
> good thing, and for your work on that I applaud this effort.  However,
> where I get worried with this approach is in both the vagaries of
> health care and practice patterns.
>
> A wise quote that I heard when I started medical informatics training
> was "a lot of what we practice today is wrong."  I'm a pediatrician,
> and I can attest to this... and because of the constant evolution in
> best practices, there's always a "scattergram" of practice styles vs.
> best practices.  That is, the urinalysis today, might not be the
> urinalysis of tomorrow.  Some might continue to use the old urinalysis
> for a number of various reasons, and some of those reasons might be
> correct.  Therefore, there arise various flavors and colors of a  
> single
> "archetype" that I think I understand represent models of how certain
> care is delivered.  These coexisting vagaries and various evolutions
> of medical concepts unfortunately I think are a necessary reality of
> health information system design.
>
> What we've attempted to do at Regenstrief (and within OpenMRS for that
> matter) is to abstract out one level further.  That is, all medical
> concepts have descriptions, datatypes, "classes", and for a given
> combination of class, datatype some relative metadata.  For example, a
> urine pH is a numeric datatype, and a test class.  Therefore, it has
> metadata such as absolute, critical, and normal ranges, a unit
> designation, etc etc.  These concepts live in the database right
> alongside the actual repository of data to serve as a general resource
> to the entire enterprise.  Any user can populate the database with new
> concepts, and we're actively working on building a resource, the OCC
> (OpenMRS Concept Cooperative) to allow for imports/exports of these
> creations for the use of the entire community.


Can the OCC be accessed by non-OpenMRS sites?   And, as a corollary,  
can non-OpenMRS sites contribute to the concept coop?

Thanks!

- - - - - - - -

>
> That being said, it's probably a good idea for the community to try
> something that inherently feels more tightly defined and
> interoperable.  We however, made the choice based on pragmatics.  That
> is, the approach I've described has been road tested for a very long
> time with good success.  We wanted to stack our odds for success, and
> were more reluctant to experiment.  The OpenMRS group took advantage
> of our institution's work, added some extra details (such as the
> ability to pre and post-coordinate ccmplex questions and answers,
> richer synonymies, etc.)
>
> Best,
> -Paul
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

[wr]

- - - - - - - -

will ross
project manager
mendocino health records exchange
216 west perkins street, suite 206
ukiah, california  95482  usa
707.462.6369 [office]
707.462.5015 [fax]
www.mendocinohre.org

- - - - - - - -

"Getting people to adopt common standards is impeded by patents."
 Sir Tim Berners-Lee,  BCS,  2006

- - - - - - - -

Re: [openhealth] Re: Hi folks..

[Nandalal Gunaratne]

Paul,

This is a good explanation of what OpenMRS is about,
and I find it quite refreshing. The problem of
constraints to allow greater acceptance and "accuracy"
(OpenEHR) against allowing change as you seem to do to
allow freedom to improve and grow in new directions, 
but which can cause confusion and inaccuracy, will
last forever. The correct path is the middle path.

nandalal
--- Paul <[EMAIL PROTECTED]> wrote:

> Hi Thomas,
> 
> --- In openhealth@yahoogroups.com, Thomas Beale
> <[EMAIL PROTECTED]> wrote:
> >
> > Nandalal Gunaratne wrote:
> > >  The power of this approach is hard to
> appreciate
> > >   
> > >> until you're in a 
> > >> situation where lots of people have lots of
> things
> > >> they want to 
> > >> characterize in a system.  It allows
> non-developers
> > >> to own and 
> > >> augment their own notions of what data matters
> to
> > >> them, without 
> > >> altering the underlying database model.
> > >> 
> > >
> > > This is important for clinicians in different
> > > specialities with various interests in the
> specifics.
> > > No FOSS EMR I tried/used, except OIO, allow this
> to be
> > > done easily by users.
> > >
> > > The Concept Dictionary approach seems to be
> similar to
> > > the Archetypes approach of OpenEHR, which goes a
> > > further step.
> > >
> > >   
> > you can see a urinalysis archetype here: 
> >
>
http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.laboratory-urea_and_electrolytes.v1.html
> > (main page:
>
http://svn.openehr.org/knowledge/archetypes/dev/index.html)
> > 
> > - thomas beale
> >
> 
> Thanks for the link.  It hasn't worked for me, but
> I'm familiar enough
> (I think) to have at least a cursory understanding
> of what archetypes
> are.  Probably enough to be dangerous. :)
> 
> Defining the relative metadata around medical
> concepts is typically a
> good thing, and for your work on that I applaud this
> effort.  However,
> where I get worried with this approach is in both
> the vagaries of
> health care and practice patterns.
> 
> A wise quote that I heard when I started medical
> informatics training
> was "a lot of what we practice today is wrong."  I'm
> a pediatrician,
> and I can attest to this... and because of the
> constant evolution in
> best practices, there's always a "scattergram" of
> practice styles vs.
> best practices.  That is, the urinalysis today,
> might not be the
> urinalysis of tomorrow.  Some might continue to use
> the old urinalysis
> for a number of various reasons, and some of those
> reasons might be
> correct.  Therefore, there arise various flavors and
> colors of a single
> "archetype" that I think I understand represent
> models of how certain
> care is delivered.  These coexisting vagaries and
> various evolutions
> of medical concepts unfortunately I think are a
> necessary reality of
> health information system design.
> 
> What we've attempted to do at Regenstrief (and
> within OpenMRS for that
> matter) is to abstract out one level further.  That
> is, all medical
> concepts have descriptions, datatypes, "classes",
> and for a given
> combination of class, datatype some relative
> metadata.  For example, a
> urine pH is a numeric datatype, and a test class. 
> Therefore, it has
> metadata such as absolute, critical, and normal
> ranges, a unit
> designation, etc etc.  These concepts live in the
> database right
> alongside the actual repository of data to serve as
> a general resource
> to the entire enterprise.  Any user can populate the
> database with new
> concepts, and we're actively working on building a
> resource, the OCC
> (OpenMRS Concept Cooperative) to allow for
> imports/exports of these
> creations for the use of the entire community.
> 
> That being said, it's probably a good idea for the
> community to try
> something that inherently feels more tightly defined
> and
> interoperable.  We however, made the choice based on
> pragmatics.  That
> is, the approach I've described has been road tested
> for a very long
> time with good success.  We wanted to stack our odds
> for success, and
> were more reluctant to experiment.  The OpenMRS
> group took advantage
> of our institution's work, added some extra details
> (such as the
> ability to pre and post-coordinate ccmplex questions
> and answers,
> richer synonymies, etc.)
> 
> Best,
> -Paul
> 
> 



 

Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 

Re: [openhealth] Re: Hi folks..

[Nandalal Gunaratne]

Thank you Thomas. This is not urinalysis but urea and
electrolytes! 

What is the "Any Result" "data type is not set" doing
here. It is, after all, urea and electrolytes, and the
electrolytes are mentioned. Is this to leave room for
rare electrolytes like the level of copper in the
blood or iron?

Nandalal
--- Thomas Beale <[EMAIL PROTECTED]>
wrote:

> Nandalal Gunaratne wrote:
> >  The power of this approach is hard to appreciate
> >   
> >> until you're in a 
> >> situation where lots of people have lots of
> things
> >> they want to 
> >> characterize in a system.  It allows
> non-developers
> >> to own and 
> >> augment their own notions of what data matters to
> >> them, without 
> >> altering the underlying database model.
> >> 
> >
> > This is important for clinicians in different
> > specialities with various interests in the
> specifics.
> > No FOSS EMR I tried/used, except OIO, allow this
> to be
> > done easily by users.
> >
> > The Concept Dictionary approach seems to be
> similar to
> > the Archetypes approach of OpenEHR, which goes a
> > further step.
> >
> >   
> you can see a urinalysis archetype here: 
>
http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.laboratory-urea_and_electrolytes.v1.html
> (main page:
>
http://svn.openehr.org/knowledge/archetypes/dev/index.html)
> 
> - thomas beale
> 
> 
> 



 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

[openhealth] Re: Hi folks..

[Paul]

Hi Thomas,

--- In openhealth@yahoogroups.com, Thomas Beale <[EMAIL PROTECTED]> wrote:
>
> Nandalal Gunaratne wrote:
> >  The power of this approach is hard to appreciate
> >   
> >> until you're in a 
> >> situation where lots of people have lots of things
> >> they want to 
> >> characterize in a system.  It allows non-developers
> >> to own and 
> >> augment their own notions of what data matters to
> >> them, without 
> >> altering the underlying database model.
> >> 
> >
> > This is important for clinicians in different
> > specialities with various interests in the specifics.
> > No FOSS EMR I tried/used, except OIO, allow this to be
> > done easily by users.
> >
> > The Concept Dictionary approach seems to be similar to
> > the Archetypes approach of OpenEHR, which goes a
> > further step.
> >
> >   
> you can see a urinalysis archetype here: 
>
http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.laboratory-urea_and_electrolytes.v1.html
> (main page: http://svn.openehr.org/knowledge/archetypes/dev/index.html)
> 
> - thomas beale
>

Thanks for the link.  It hasn't worked for me, but I'm familiar enough
(I think) to have at least a cursory understanding of what archetypes
are.  Probably enough to be dangerous. :)

Defining the relative metadata around medical concepts is typically a
good thing, and for your work on that I applaud this effort.  However,
where I get worried with this approach is in both the vagaries of
health care and practice patterns.

A wise quote that I heard when I started medical informatics training
was "a lot of what we practice today is wrong."  I'm a pediatrician,
and I can attest to this... and because of the constant evolution in
best practices, there's always a "scattergram" of practice styles vs.
best practices.  That is, the urinalysis today, might not be the
urinalysis of tomorrow.  Some might continue to use the old urinalysis
for a number of various reasons, and some of those reasons might be
correct.  Therefore, there arise various flavors and colors of a single
"archetype" that I think I understand represent models of how certain
care is delivered.  These coexisting vagaries and various evolutions
of medical concepts unfortunately I think are a necessary reality of
health information system design.

What we've attempted to do at Regenstrief (and within OpenMRS for that
matter) is to abstract out one level further.  That is, all medical
concepts have descriptions, datatypes, "classes", and for a given
combination of class, datatype some relative metadata.  For example, a
urine pH is a numeric datatype, and a test class.  Therefore, it has
metadata such as absolute, critical, and normal ranges, a unit
designation, etc etc.  These concepts live in the database right
alongside the actual repository of data to serve as a general resource
to the entire enterprise.  Any user can populate the database with new
concepts, and we're actively working on building a resource, the OCC
(OpenMRS Concept Cooperative) to allow for imports/exports of these
creations for the use of the entire community.

That being said, it's probably a good idea for the community to try
something that inherently feels more tightly defined and
interoperable.  We however, made the choice based on pragmatics.  That
is, the approach I've described has been road tested for a very long
time with good success.  We wanted to stack our odds for success, and
were more reluctant to experiment.  The OpenMRS group took advantage
of our institution's work, added some extra details (such as the
ability to pre and post-coordinate ccmplex questions and answers,
richer synonymies, etc.)

Best,
-Paul

RE: [openhealth] Re: Hi folks.. OSHCA conference

[Klaus Veil]

All,
 
I assume people on this list have seen this:
 
http://blogs.sun.com/Sun_on_Health/entry/open_source_and_open_standards
 
Could Sun be a sponsor for OSHCA 2007?
 
Klaus

  _  

From: openhealth@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Dr Molly Cheah
Sent: Monday, 19 February 2007 11:03
To: openhealth@yahoogroups.com
Subject: Re: [openhealth] Re: Hi folks.. OSHCA conference



Thanks for your offer Paul. You've probably missed OSHCA's call for 
presentation at its coming conference from May 8-11 2007 in Kuala 
Lumpur. The date had been changed from May 1 to accommodate request from 
those who wish to attend HIMSS Asia-Pacific in S'pore.

We're making some changes to the programme to include a training 
component for new Asian FOSS programmers (the contents are being worked 
out), again focussing on data exchange and interoperability. Our major 
funders (as of now) will be IDRC and UNDP-APDIP's IOSN (ASEAN+3).

Naturally we welcome other assistance not only financial support but 
more crucially presentations of FOSS applications, other resources for 
expertise to impart their knowledge on the wide ranging topics of FOSS 
in healthcare.

Here is a repeat of the call, with the new confirmed dates. We have also 
confirmed the venue as the Federal Hotel, Kuala Lumpur offering us a 
hotel rate of MYR180 nett per room (single/twin-sharing with breakfast). 
At current exchange rate of approx. 3.5 its only USD52 per day.

We're working out with our funders to make available scholarships for 
FOSS advocates who can't afford to come on their own, but feel strongly 
that they would like to share their expertise, experience and 
collaborate with their developing world FOSS enthusiasts especially from 
the Asian region.

So, we would like to welcome anyone to register their interests with us 
asap to help us plan the conference in a better way. I'm off travelling 
for a week and may not be able to respond regularly, but there are 
others on the OSHCA conference technical committee who will do so.

Please bear with us on the slowness of the OSHCA web portal. It's 
temporarily hosted on the MCTC's server from my office, as upto now we 
don't have any funding for OSHCA except for some subscription received 
so far. In the meantime, we'll update using this list.

Moving the FOSS Agenda for Health: Setting the Framework for
Interoperability

*8-11 May 2007
Kuala Lumpur, Malaysia*

Call for Presentations OSHCA 2007 - Annual Open Source Health Care 
Alliance Meeting

This four-day conference provides the opportunity for Free/Open Source 
Software (FOSS) applications in healthcare, its updates and the use of 
FOSS technologies to be presented to participants particularly from the 
developing countries of the Asia-Pacific region. The target audience, in 
addition to the FOSS in Healthcare Community, will include interested 
persons from Ministries of Health and Private Health Care Facilities 
from this region.

The conference agenda will also include presentations and workshops on a 
variety of issues focussing on interoperability and data exchange. Major 
concerns on affordability and developing human capacity in the 
promotion, adoption and the use of FOSS applications will be deliberated on.

There will also be concurrent sessions for training of new FOSS 
programmers in health care to be scheduled during the conference.

To register your interest in presenting your applications, please email 
a brief description of your application (not more than 250 words) and 
its reference url in plain text or XHTML to: [EMAIL PROTECTED]
<mailto:conference%40oshca.org> org 
<mailto:[EMAIL PROTECTED] <mailto:conference%40oshca.org> org>

OSHCA Committee will decide on the final programme, logistics etc.
For updated information on the conference status and registration 
information as it becomes available please visit the conference site at: 
http://oshca. <http://oshca.org/conference/conf2007/>
org/conference/conf2007/

In the meantime, please register your interests asap to enable us to 
plan the conference agenda.

Molly
Paul wrote:

>Hi Molly, I'm one of the co-founders of OpenMRS. Let me know how I
>can be helpful to you. Still trying to catch up with the community
>here, and it seems I need to do some due diligence on OSHCA.
>
>Best,
>-Paul
>
>--- In [EMAIL PROTECTED] <mailto:openhealth%40yahoogroups.com> ups.com,
Molly Cheah <[EMAIL PROTECTED]> wrote:
> 
>
>>You're right, Nandalal. I was given the contact to the OpenMRS to
>> 
>>
>invite 
> 
>
>>them to the OSHCA conference in May by the new director of ICT for IDRC 
>>as I understand that the project in Africa is quite exciting. As
>> 
>>
>soon as 
> 
>
>>I get a firm commitment on the funding for scholarships for those 
>>outside the ASEAN region, I

Re: [openhealth] Re: Hi folks..

[Thomas Beale]

Nandalal Gunaratne wrote:
>  The power of this approach is hard to appreciate
>   
>> until you're in a 
>> situation where lots of people have lots of things
>> they want to 
>> characterize in a system.  It allows non-developers
>> to own and 
>> augment their own notions of what data matters to
>> them, without 
>> altering the underlying database model.
>> 
>
> This is important for clinicians in different
> specialities with various interests in the specifics.
> No FOSS EMR I tried/used, except OIO, allow this to be
> done easily by users.
>
> The Concept Dictionary approach seems to be similar to
> the Archetypes approach of OpenEHR, which goes a
> further step.
>
>   
you can see a urinalysis archetype here: 
http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.laboratory-urea_and_electrolytes.v1.html
(main page: http://svn.openehr.org/knowledge/archetypes/dev/index.html)

- thomas beale

Re: Open source OCR (was [openhealth] Re: Hi folks..)

[Tim Churches]

Karsten Hilbert wrote:
> On Tue, Feb 20, 2007 at 08:16:07AM +1100, Tim Churches wrote:
> 
>>> The data retrieved from step 4 will be computable data ! Not
>>> particularly well constrained, but not just image data either.
>> Ah, OK. Our problem is that many users only want to record data with a
>> pen, on paper. No typing, no computers. And then scan the paper forms in
>> and have their data appear, automagically, in the database just as if
>> they had typed it. Nearly every user over the age of 50 asks for that.
> I see.
> 
>> Mind you, these are mobile users, and paper forms and a pen are highly
>> portable, robust and never need to be plugged in, so they do have a bit
>> of a (ball) point.
>
> No problem, the availability of pen-and-paper is nearly unbeatable.
> 
> That would bring us back to constrained OCR. Which sort of
> pre-sets the range of output to expect from the OCR process.
> Always assuming users write down valid data ...

Yes, and that is what Teleform claims to be able to do, and if users are
well-behaved and write very neatly, then it does work. But if they
don't... more trouble than it is worth, in my experience.

Which leads me to think that something like Amazon's Mechanical Turk
(see http://en.wikipedia.org/wiki/Amazon_Mechanical_Turk ) is required.
Not actually MTurk, due to privacy concerns, but a pool of trusted or
semi-trusted humans who can do the data entry in a distributed fashion
from scanned forms. The fields on each form could even be teased apart
first by raster image manipulation, and each human transcriber/typist is
sent only small parts of a set of randomly chosen forms, so as to
further mitigate privacy concerns. Either all (for double-entry data
validation) or a sample of bits of form text could be sent to more than
one person and the results cross-checked and resolved if discrepant to
ensure accuracy. H.

Tim C

Re: Open source OCR (was Re: [openhealth] Re: Hi folks..)

[Tim Churches]

ksbhaskar wrote:
> --- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote:
> 
> [KSB] <...snip...>
> 
>> But if anyone can suggest an alternative for turning data recorded on
>> paper forms into data (as opposed to raster image) files, we'd love to
>> hear of it.
> 
> [KSB] Did you look at Ocrad
> (http://www.gnu.org/software/ocrad/ocrad.html) perchance?  Is it
> anywhere near viability?

No, haven't tried it, but reading various blogs suggests that it is not,
whereas Tesseract, despite being of early-90s vintage, is a viable
option, perhaps. It is available as a debian package, I think, so should
be easy to try out.

Of course, most people are using Tesseract etc to read machine-printed
text which is very different to reading hand-written text. Surely
there are open source handwriting recognition engines? There are some,
but they focus on stroke recognition as characters are written on a
touch screen, not on post-hoc recognition of handwritten text.

I think that Teleform may be the only (commercial, closed-source, alas)
game in town for what our older users want to be able to do.

Tim C

Re: [openhealth] Re: Hi folks..

[Karsten Hilbert]

On Tue, Feb 20, 2007 at 08:16:07AM +1100, Tim Churches wrote:

> > The data retrieved from step 4 will be computable data ! Not
> > particularly well constrained, but not just image data either.
> 
> Ah, OK. Our problem is that many users only want to record data with a
> pen, on paper. No typing, no computers. And then scan the paper forms in
> and have their data appear, automagically, in the database just as if
> they had typed it. Nearly every user over the age of 50 asks for that.
I see.

> Mind you, these are mobile users, and paper forms and a pen are highly
> portable, robust and never need to be plugged in, so they do have a bit
> of a valid case.
No problem, the availability of pen-and-paper is nearly unbeatable.

That would bring us back to constrained OCR. Which sort of
pre-sets the range of output to expect from the OCR process.
Always assuming users write down valid data ...

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Karsten Hilbert wrote:
> On Tue, Feb 20, 2007 at 07:25:28AM +1100, Tim Churches wrote:
> 
 No, we need the data in computable form
>>> OK, that kills the easy solution. Or it might not. If you
>>> don't blend both sources of information (background image
>>> and user input) but rather keep them separate and blend on
>>> display/printing you'd still have the computable user input.
>>> The drawback is that it lacks any metadata (apart from which
>>> form it belongs to) as all the metadata would be encoded in
>>> the *location* of what the user typed. Which in itself just
>>> *might* lend itself to an OCR-like solution where a mask
>>> image is overlaid onto the data thereby adding metadata to
>>> it.
>> Hmm, that's a nice idea. It would be interesting to use PIL (Python
>> image library) to do the form subtraction that you mention, leaving just
>> the handwritten entries, and then present that to Tesseract OCR (which
>> is in C and could be wrapped as a Python library, I'm sure), and see how
>> it performs.
> Wait, the initial idea was slightly different still:
> 
> 1) scan the legacy paper form
> 2) put it into an OOo document as a background image
> 3) define text areas in OOo to have users type data into them
> 4) later on read the data from the text entry areas in the OOo document
> 
> The data retrieved from step 4 will be computable data ! Not
> particularly well constrained, but not just image data either.

Ah, OK. Our problem is that many users only want to record data with a
pen, on paper. No typing, no computers. And then scan the paper forms in
and have their data appear, automagically, in the database just as if
they had typed it. Nearly every user over the age of 50 asks for that.
Mind you, these are mobile users, and paper forms and a pen are highly
portable, robust and never need to be plugged in, so they do have a bit
of a valid case.

Tim C

Re: Holding the Vision While Achieving Practical Integration/Interoperability Today (was) Re: [openhealth] Re: Hi folks..

[David Forslund]

Tim Churches wrote:
> David Forslund wrote:
>   
>> Joseph Dal Molin wrote:
>> 
>>> Open source efforts/software like OpenMRS, WorldVistA (VistA Office 
>>> etc.), OSCAR etc. that are focused on diffusion/uptake and continuous 
>>> improvement. All need to have practical tools methods etc. to work 
>>> effectively in the heterogeneous health IT ecosystem. Building on Tim's 
>>> view:
>>>
>>>  >> I believe that with a modest upfront investment one can go a long way
>>>  >> toward interoperability.  The
>>>  >> open source community should be leading in this area, because of the
>>>  >> increased cooperation.
>>>
>>> What would that modest investment be? Who would be willing to 
>>> collaborate to make it happen? How does a practical approach dance 
>>> effectively with and benefit from the vision/work of the 
>>> "interoperability" expert community?  How can we leverage the OSHCA 
>>> meeting in May to help the open source health community take the 
>>> leadership role?
>>>
>>>
>>> Joseph
>>>   
>>>   
>> The above quote was from me, not Tim.  I don't know if he has the same 
>> view or not.
>> 
>
> I am not in any way antithetical to investing effort in
> interoperability. However, I do not regard it as an end in itself. The
> goal of open source health informatics must always be to improve the
> health and health care of people. If widespread and ongoing
> interoperability is important, in a given setting or sub-domain, to
> achieving those goals, then lots of effort should be put into
> implementing highly generalised, standards-based interoperability. If
> only limited intraoperability between, say, a few clinics all running
> the same software is required, then I believe it is perfectly
> permissible to take shortcuts and go for easier-to-implement
> non-standard interoperability mechanisms, particularly when software
> development resources are tight, as they almost always are in open
> source projects. And if interoperability is just not needed, then there
> is no point building it in. All these views are modified by the level of
> resources and the expected longevity of the software. If millions of
> dollars and tens or hundreds of person-years are being ploughed into a
> project, then it would be silly not to consider standards-based
> interoperability right from the start. But if, like most open source
> projects, the budget ranges from zero to a few hundred thousand dollars,
> and a few person-years of effort or less is involved, then a more zen
> approach can be taken - regard the software as ephemeral, to be evolved
> or recreated on a regular basis, perhaps even every year or so. In that
> case, the failure to build in complex, standards=based interoperability
> at the early stages is not such a disaster, even if it is needed later.
> Better to get the project up on its feet first.
>
>   
I don't think that interoperability is that costly to consider up 
front.  The design process that
even the smallest project can easily consider it.  It may well reject 
it, but the principles
of interoperability are important so that the cost of including it in 
the future can be anticipated. 
How one separates modules or components which can facilitate 
interoperability can also lower
the cost of development even for small open source projects.  I submit 
that exchanging and integrating
medical records is an important consideration even if not fully 
implemented at the moment.  The
cost later may require completely rewriting/replacing/converting the old 
system to a new one.
Interoperability certainly isn't the major driver, but should be at 
least considered up front. 
>   
>> The "modest
>> investment" is in the design of a system up front.  It always saves time 
>> to go through a design process
>> rather than just start coding.  The design process involves 
>> understanding and documenting the underlying
>> abstractions of the process.  This can lead to well-designed interfaces 
>> which properly divide up the labor involved
>> more efficient development.  It is at this point that one reviews the 
>> literature to see how well the interfaces
>> match to existing standards or systems.
>> 
>
> I agree with this to a degree, although I am utterly convinced that the
> traditional "waterfall" methods of designing everything on paper or as
> thought-experiments, encoding that in written specs, and then slavishly
> implementing those specs, is completely broken (yet I still see it used
> all the time for software projects, half of which then fail). Better to
> keep the initial design phase brief, then start coding and reviewing the
> outcome and design using highly iterative agile development methods.
>   
I'm not in favor of traditional "waterfall" methods either for the 
reasons you describe.  
As I've participated in the standards process, I've adopted some of the 
strategies learned
in my internal development. I create interfaces all the time for my 
internal code between
various modules, b

Re: Holding the Vision While Achieving Practical Integration/Interoperability Today (was) Re: [openhealth] Re: Hi folks..

[Tim Churches]

David Forslund wrote:
> Joseph Dal Molin wrote:
>> Open source efforts/software like OpenMRS, WorldVistA (VistA Office 
>> etc.), OSCAR etc. that are focused on diffusion/uptake and continuous 
>> improvement. All need to have practical tools methods etc. to work 
>> effectively in the heterogeneous health IT ecosystem. Building on Tim's 
>> view:
>>
>>  >> I believe that with a modest upfront investment one can go a long way
>>  >> toward interoperability.  The
>>  >> open source community should be leading in this area, because of the
>>  >> increased cooperation.
>>
>> What would that modest investment be? Who would be willing to 
>> collaborate to make it happen? How does a practical approach dance 
>> effectively with and benefit from the vision/work of the 
>> "interoperability" expert community?  How can we leverage the OSHCA 
>> meeting in May to help the open source health community take the 
>> leadership role?
>>
>>
>> Joseph
>>   
> The above quote was from me, not Tim.  I don't know if he has the same 
> view or not.

I am not in any way antithetical to investing effort in
interoperability. However, I do not regard it as an end in itself. The
goal of open source health informatics must always be to improve the
health and health care of people. If widespread and ongoing
interoperability is important, in a given setting or sub-domain, to
achieving those goals, then lots of effort should be put into
implementing highly generalised, standards-based interoperability. If
only limited intraoperability between, say, a few clinics all running
the same software is required, then I believe it is perfectly
permissible to take shortcuts and go for easier-to-implement
non-standard interoperability mechanisms, particularly when software
development resources are tight, as they almost always are in open
source projects. And if interoperability is just not needed, then there
is no point building it in. All these views are modified by the level of
resources and the expected longevity of the software. If millions of
dollars and tens or hundreds of person-years are being ploughed into a
project, then it would be silly not to consider standards-based
interoperability right from the start. But if, like most open source
projects, the budget ranges from zero to a few hundred thousand dollars,
and a few person-years of effort or less is involved, then a more zen
approach can be taken - regard the software as ephemeral, to be evolved
or recreated on a regular basis, perhaps even every year or so. In that
case, the failure to build in complex, standards=based interoperability
at the early stages is not such a disaster, even if it is needed later.
Better to get the project up on its feet first.


> The "modest
> investment" is in the design of a system up front.  It always saves time 
> to go through a design process
> rather than just start coding.  The design process involves 
> understanding and documenting the underlying
> abstractions of the process.  This can lead to well-designed interfaces 
> which properly divide up the labor involved
> more efficient development.  It is at this point that one reviews the 
> literature to see how well the interfaces
> match to existing standards or systems.

I agree with this to a degree, although I am utterly convinced that the
traditional "waterfall" methods of designing everything on paper or as
thought-experiments, encoding that in written specs, and then slavishly
implementing those specs, is completely broken (yet I still see it used
all the time for software projects, half of which then fail). Better to
keep the initial design phase brief, then start coding and reviewing the
outcome and design using highly iterative agile development methods.

Tim C

Re: [openhealth] Re: Hi folks..

[Karsten Hilbert]

On Tue, Feb 20, 2007 at 07:25:28AM +1100, Tim Churches wrote:

> >> No, we need the data in computable form
> > OK, that kills the easy solution. Or it might not. If you
> > don't blend both sources of information (background image
> > and user input) but rather keep them separate and blend on
> > display/printing you'd still have the computable user input.
> > The drawback is that it lacks any metadata (apart from which
> > form it belongs to) as all the metadata would be encoded in
> > the *location* of what the user typed. Which in itself just
> > *might* lend itself to an OCR-like solution where a mask
> > image is overlaid onto the data thereby adding metadata to
> > it.
> 
> Hmm, that's a nice idea. It would be interesting to use PIL (Python
> image library) to do the form subtraction that you mention, leaving just
> the handwritten entries, and then present that to Tesseract OCR (which
> is in C and could be wrapped as a Python library, I'm sure), and see how
> it performs.
Wait, the initial idea was slightly different still:

1) scan the legacy paper form
2) put it into an OOo document as a background image
3) define text areas in OOo to have users type data into them
4) later on read the data from the text entry areas in the OOo document

The data retrieved from step 4 will be computable data ! Not
particularly well constrained, but not just image data either.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Open source OCR (was Re: [openhealth] Re: Hi folks..)

[ksbhaskar]

--- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote:

[KSB] <...snip...>

> But if anyone can suggest an alternative for turning data recorded on
> paper forms into data (as opposed to raster image) files, we'd love to
> hear of it.

[KSB] Did you look at Ocrad
(http://www.gnu.org/software/ocrad/ocrad.html) perchance?  Is it
anywhere near viability?

Regards
-- Bhaskar

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Karsten Hilbert wrote:
> On Mon, Feb 19, 2007 at 07:04:35AM +1100, Tim Churches wrote:
>> No, we need the data in computable form
> OK, that kills the easy solution. Or it might not. If you
> don't blend both sources of information (background image
> and user input) but rather keep them separate and blend on
> display/printing you'd still have the computable user input.
> The drawback is that it lacks any metadata (apart from which
> form it belongs to) as all the metadata would be encoded in
> the *location* of what the user typed. Which in itself just
> *might* lend itself to an OCR-like solution where a mask
> image is overlaid onto the data thereby adding metadata to
> it.

Hmm, that's a nice idea. It would be interesting to use PIL (Python
image library) to do the form subtraction that you mention, leaving just
the handwritten entries, and then present that to Tesseract OCR (which
is in C and could be wrapped as a Python library, I'm sure), and see how
it performs. But that's several days or a week of fiddling, and it may
be fruitless, but if it worked...

Re Tesseract, see also:
http://www.groklaw.net/article.php?story=20061210115516438

Ah, so many ideas, so little time.

Tim C

Re: Holding the Vision While Achieving Practical Integration/Interoperability Today (was) Re: [openhealth] Re: Hi folks..

[David Forslund]

Joseph Dal Molin wrote:
> Open source efforts/software like OpenMRS, WorldVistA (VistA Office 
> etc.), OSCAR etc. that are focused on diffusion/uptake and continuous 
> improvement. All need to have practical tools methods etc. to work 
> effectively in the heterogeneous health IT ecosystem. Building on Tim's 
> view:
>
>  >> I believe that with a modest upfront investment one can go a long way
>  >> toward interoperability.  The
>  >> open source community should be leading in this area, because of the
>  >> increased cooperation.
>
> What would that modest investment be? Who would be willing to 
> collaborate to make it happen? How does a practical approach dance 
> effectively with and benefit from the vision/work of the 
> "interoperability" expert community?  How can we leverage the OSHCA 
> meeting in May to help the open source health community take the 
> leadership role?
>
>
> Joseph
>   
The above quote was from me, not Tim.  I don't know if he has the same 
view or not.  The "modest
investment" is in the design of a system up front.  It always saves time 
to go through a design process
rather than just start coding.  The design process involves 
understanding and documenting the underlying
abstractions of the process.  This can lead to well-designed interfaces 
which properly divide up the labor involved
more efficient development.  It is at this point that one reviews the 
literature to see how well the interfaces
match to existing standards or systems.   The collaboration could be in 
the sharing of the design processes
involved in the software development.   Get someone from the HSSP 
community to discuss the interoperability
vision and its impact.   I don't know how this can take advantage of the 
upcoming OSHCA meeting, since it is far beyond
my means or time to attend the meeting that far away. 

Dave
>
> Will Ross wrote:
>   
>> What a wonderful discussion.   I am so glad to have Regenstrief's  
>> OpenMRS at the table!   I also know there are other lurkers out there  
>> (you know who you are!) who can add to the robust discussion.  But my  
>> purpose here is to highlight one point.   Paul, Dave and Tim have all  
>> mentioned not allowing the pursuit of "perfect" semantic  
>> interoperability to interfere with simple incremental improvements  
>> that can be realized immediately.   This is in fact one of the  
>> hallmarks of the decades of dramatic real-world demonstrations that  
>> Regenstrief has brought to central Indiana.   And it is the central  
>> tenet of the Connecting For Health (USA version) effort to make  
>> records portable and electronic without requiring a rip and replace  
>> changeout of all legacy health record systems.   And it was one of  
>> the key points in Andy Grove's "Shift Left" address at Stanford this  
>> past november.
>>
>>http://news-service.stanford.edu/news/2006/november8/med- 
>> grove-110806.html
>>
>> But we all know this is a marathon, not a sprint.   This year's TEPR  
>> conference is the 23rd annual meeting devoted to the immanent  
>> transition from paper to digital charting.
>>
>>http://www.medrecinst.com/conference/tepr/index.asp
>>
>> Meanwhile, in my rural region of California, 2007 may be the year we  
>> see adoption of EHR rise above 10% among small practices.   The  
>> arrival of new FOSS projects like OpenMRS can only help improve our  
>> rate of adoption.
>>
>> With best regards,
>>
>> [wr]
>>
>> - - - - - - - -
>>
>> On Feb 17, 2007, at 9:24 PM, David Forslund wrote:
>>
>> 
>>> Tim Churches wrote:
>>>   
 David Forslund wrote:

 
> I've seen no real
> effort in the open source community to embrace interoperability.
> Certainly interoperability has
> been opposed by much of industry until recently, but there is no  
> good
> reason for the open source community to not embrace it.
>
>   
 Dave, interoperability, although good in theory, is not an end in
 itself. Thus you have to ask the question: in the settings in  
 which open
 source health information systems are or are likely to be  
 deployed, what
 are the "business drivers" or the "business case" for  
 interoperability,
 and what sort of interoperability?

 Thus, although there is indeed no good reason not to embrace
 interoperability, there may be, in many open source deployment  
 settings,
 no good reason to embrace it, either, given that supporting
 interoperability is not without some cost.

 
>>> I agree with you, with a caveat.  If you plan for interoperability,  
>>> the
>>> cost isn't very high. Adding it
>>> later is much more expensive.  For the patient, the value of
>>> interoperability is very high.  Clearly
>>> for implementers, the demand for interoperability is not high since it
>>> might take away from the
>>> local business model.
>>>   
 For example, the COAS specs document is 260 pages long, bu

Re: [openhealth] Re: Hi folks..

[Karsten Hilbert]

On Mon, Feb 19, 2007 at 07:04:35AM +1100, Tim Churches wrote:

> >> surprisingly tricky and fragile). But it does support dataset
> >> versioning, so that the latest version of source data can be loaded into
> >> a new dataset in the background while users continue to use an existing
> >> dataset, and when the new load has completely it is transparently used
> >> for all new analysis sessions.
> > Isn't that what transactions are all about in an MVCC
> > database ?
> 
> Yes, but it doesn't use PostgreSQL (our data collection facility, NetEpi
> Collection, uses PostgreSQL).
Oh, I thought since NetEpi does the other does, too. But
MVCC isn't limited to PostgreSQL so there was still a
chance. Also, it would only support old and new and when new
became committed old wouldn't be accessible (readily)
anymore.

> Also, the versioning is at the level of
> entire datasets (equivalent to tables in an SQL database, more or less).
Which just means the scope of the transaction would have to
be set appropriately.

> >> would be harder, but possible - maybe a few weeks work. It can certainly
> >> load data directly from a database back-end, although some queries to
> >> flatten the data appropriately might be needed.
> > This might be achievable with a few flattening and/or even
> > materialized views inbetween the NetEpi code and the OpenMRS
> > schema.
> 
> Yes, but would need to be able to use the OpenMRS concept dictionary and
> other metadata to be able to flatten the OpenMRS tables/entities stored
> in EAV form, and also do statically defined joins between those and
> other conventional tables in OpenMRS.
All of which would still be available for access despite the
views layer. But it's work which doesn't get done by itself,
yes.

> No, we need the data in computable form
OK, that kills the easy solution. Or it might not. If you
don't blend both sources of information (background image
and user input) but rather keep them separate and blend on
display/printing you'd still have the computable user input.
The drawback is that it lacks any metadata (apart from which
form it belongs to) as all the metadata would be encoded in
the *location* of what the user typed. Which in itself just
*might* lend itself to an OCR-like solution where a mask
image is overlaid onto the data thereby adding metadata to
it.

> hand-written forms using that, but gee, an open source solution would be
> nice. Suggestions very welcome.
If I had any GNUmed would have an interface for it  :-(

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [openhealth] Re: Hi folks..

[Thomas Beale]

Tim Churches wrote:
> It will be very interesting to see what the UK NHS does with the
> copyright and licensing of openEHR archetypes and specifications which
> it creates. It doesn't really have much of a track record for releasing
> its IP for wider use, does it? (Very few large govt health authorities
> do.) Maybe they will change?
>
> This does raise the issue of licensing of openEHR archetypes and
> templates. I'll reproduce here a post I made on this list in Dec 2006 -
> it is an issue still not completely resolved (at least not to my
> satisfaction), but it is a most important one, I feel:
>
>   
It is likely to be improved - now that archetypes are being used quite 
widely in national and international modelling exercises - we expect 
more feedback from users. I am not yet so cynical as to believe the NHS 
won't require a sensible, open license. From openEHR's point of view, 
the change can only be open -> more open.

- thomas

Re: [openhealth] Re: Hi folks..

[Nandalal Gunaratne]

 The power of this approach is hard to appreciate
> until you're in a 
> situation where lots of people have lots of things
> they want to 
> characterize in a system.  It allows non-developers
> to own and 
> augment their own notions of what data matters to
> them, without 
> altering the underlying database model.

This is important for clinicians in different
specialities with various interests in the specifics.
No FOSS EMR I tried/used, except OIO, allow this to be
done easily by users.

The Concept Dictionary approach seems to be similar to
the Archetypes approach of OpenEHR, which goes a
further step.

Nandalal
--- Paul <[EMAIL PROTECTED]> wrote:

> Hi Karsten,
> 
> --- In openhealth@yahoogroups.com, Karsten Hilbert 
> 
> > Agree. I'm reading this thread with interest. I
> have been
> > interested in the Concept Dictionary approach ever
> since I
> > learned about OpenMRS a year ago or so. There's a
> strong
> > camp opposed to EAV-only schemata. I have a
> nagging feeling,
> > however, that having a Concept Dictionary approach
> can be of
> > great value where it fits (as a poor-mans export
> system,
> > perhaps ?). I have read most of the OpenMRS docs
> but haven't
> > yet been struck by lightning going "Ah yes !
> That's how I'd
> > want to use that in GNUmed !!". As I said, I do
> think I am
> > missing out on something very elegant and would
> like to be
> > educated on that. It's the same feeling I have
> that once I
> > eventually get around to implementing forms (as in
> paper)
> > support I will turn to studying NetEpi on that.
> 
> Well, Burke and I started down the pathway of a
> concept dictionary 
> based EAV model not due to any divine wisdom on our
> part, but 
> because of the education we received from our
> mentor, Clem McDonald, 
> who is the father of the RMRS, one of the oldest
> (40+ years) and 
> largest clinical information systems I'm aware of. 
> We thought, if 
> it's not broke, let's not try to fix it.  Of course,
> we've 
> modernized and extended out some of the
> functionalities from the 
> RMRS model, but the basic ideas have remained
> intact.
> 
> The most important technical "a-ha" for me was once
> I got the point 
> that the dictionary defines both the questions and
> the answers 
> within an observation.  My favorite example is a
> simple test in any 
> urinalysis, the urine color.  We create a concept
> for the 
> question "urine color" and then define all of the
> appropriate meta-
> data that drives that question.  Like, what is the
> datatype of the 
> concept, what are it's synonyms, what is it's
> description?  In the 
> case of urine color, you might set it's datatype as
> "coded" so that 
> you can make separate concepts for each answer. 
> (ie, yellow, straw 
> colored, clear, etc.)  The magic of this dictionary
> is that any 
> concept can be used throughout the system in a lot
> of ways.  Want to 
> use "urine color" as an answer to another question? 
> No problem.  
> Want to use yellow to describe's someone skin color?
>  No problem as 
> well.
> 
> The power of this approach is hard to appreciate
> until you're in a 
> situation where lots of people have lots of things
> they want to 
> characterize in a system.  It allows non-developers
> to own and 
> augment their own notions of what data matters to
> them, without 
> altering the underlying database model.  The RMRS
> has over 30k of 
> these concepts.  If you'd like me to set you up with
> some examples 
> of what this looks like in a live system, just let
> me know.  I'll 
> point you to a demo that you can hack around with.
> 
> Hope this is helpful,
> -Paul
> 
> 




 

Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Paul wrote:
> Thanks for this overview.  There are so many layers to this whole 
> data analysis aspect of medical record repositories.  Thinking from 
> left to right, there's the whole set of challenges around 
> converting "stacked" database models (where there's one row per 
> clinical observation) to the typical "flat" models, where the 
> columns of a table are the observations, and each row is some higher 
> level of measurement (ie, encounter, patient, etc).  We're working 
> quite hard on tools to go from our stacked OpenMRS data repository 
> to flat data exports for analysis purposes.  To generate the rows, 
> we're developing a cohort builder which allows users to 
> interactively look at patient/encounter counts for given clinical 
> measurements, and in an OVID style, provide an interface to and/or 
> them together to arrive at your final cohort.  If you'd like to see 
> this in a demonstration, let me know and I can pass some 
> instructions.  To generate the columns, we're developing a tool to 
> select the observations of interest, and apply aggregations and/or 
> rules to them (IE, last 4 hemoglobins where they occured in the past 
> year).

Yup, would like to have a look. Those flattened tables or views are what
NetEpi Analysis needs to load, although as I mentioned, it handles
repeating data. So, for instance, if "reason_for_visit" (rfv) from the
last 4 visits are flattened into rfv1, rfv2, rfv3 and rfv columns in a
one-row-per-patient table/view, then NetEpi can accommodate all four
columns separately and also view them as a single multi-valued column
called, say, rfv_all, which greatly simplifies dataset subsetting and
analysis.

> Once you have the data exported, there's the whole issue of what 
> interfaces do you support to various analysis software packages.  I 
> think the OpenMRS group is fully in support of letting a thousand 
> flowers bloom.  As we @ Regenstrief are directly serving a large set 
> of clinical sites in Western Kenya, we have to have a solution for 
> our own backyard, and so the one we're investigating at this point 
> is BIRT.

BIRT looks to be good as a traditional banded report writer, for line
listings and summaries. Tools for end users to design reports easily and
quickly need to be developed, though (same for JasperReports). Pentaho
is one worth watching, though.

>  That being said, we'd love to have a variety of choices, 
> and perhaps NetEpi Analysis could be another one.  We'd gladly 
> advertise and document ways in which these softwares could work 
> together.
> 
>> Fairly easy to write hard-coded interfaces to OpenMRS, I
>> suspect, either in PHP or Python or both, although a generic 
> interface
>> would be harder, but possible - maybe a few weeks work. It can 
> certainly
>> load data directly from a database back-end, although some queries 
> to
>> flatten the data appropriately might be needed. Further processing 
> and
>> data transformation can be done in Python as the data are loaded. 
> 
> Tim, perhaps I don't understand the scope of your software, but does 
> NetEpi analysis generate OLAP cubes or views on the fly as well as 
> provide the interface for report generation?

Yes, it summarises data in a manner similar to OLAP cubes, on-the-fly,
and also provides a point-and-click Web interface for exploratory data
analysis (which more accurately describes the ground it covers than
"report generation"). The Web interface uses metadata about the datasets
and their columns wherever possible to offer sensible or meaningful
choices, more or less (its an aspect we plan to improve a lot, but the
interface is to a degree metadata-driven).

> 
> Oh,
>> you can use it via the Web front-end, no programming, or via its 
> own
>> Python API, which is simple enough for interactive command-line 
> analysis
>> as well as for calling from other things.
> 
> I'd like to sick Justin Miranda, the developer currently leading up 
> our reporting efforts, on top of what your team has done.  Would you 
> mind me passing some contact information along to him?

No, please do. We're frantically busy until mid-March, but not too busy
to exchange a few preliminary emails. After that, happy to engage in
collaboration.

Tim C

[openhealth] Re: Hi folks.. OSHCA conference

[Paul]

Molly, thanks for the information.  I've passed this information onto 
my colleagues and I'll let you know their thoughts soon.

Best,
-Paul

--- In openhealth@yahoogroups.com, Dr Molly Cheah <[EMAIL PROTECTED]> wrote:
>
> Thanks for your offer Paul. You've probably missed OSHCA's call for 
> presentation at its coming conference from May 8-11 2007 in Kuala 
> Lumpur. The date had been changed from May 1 to accommodate request 
from 
> those who wish to attend HIMSS Asia-Pacific in S'pore.
> 
> We're making some changes to the programme to include a training 
> component for new Asian FOSS programmers (the contents are being 
worked 
> out), again focussing on data exchange and interoperability. Our 
major 
> funders (as of now) will be IDRC and UNDP-APDIP's IOSN (ASEAN+3).
> 
> Naturally we welcome other assistance not only financial support 
but 
> more crucially presentations of FOSS applications, other resources 
for 
> expertise to impart their knowledge on the wide ranging topics of 
FOSS 
> in healthcare.
> 
> Here is a repeat of the call, with the new confirmed dates. We have 
also 
> confirmed the venue as the Federal Hotel, Kuala Lumpur offering us 
a 
> hotel rate of MYR180 nett per room (single/twin-sharing with 
breakfast). 
> At current exchange rate of approx. 3.5 its only USD52 per day.
> 
> We're working out with our funders to make available scholarships 
for 
> FOSS advocates who can't afford to come on their own, but feel 
strongly 
> that they would like to share their expertise, experience and 
> collaborate with their developing world FOSS enthusiasts especially 
from 
> the Asian region.
> 
> So, we would like to welcome anyone to register their interests 
with us 
> asap to help us plan the conference in a better way. I'm off 
travelling 
> for a week and may not be able to respond regularly, but there are 
> others on the OSHCA conference technical committee who will do so.
> 
> Please bear with us on the slowness of the OSHCA web portal. It's 
> temporarily hosted on the MCTC's server from my office, as upto now 
we 
> don't have any funding for OSHCA except for some subscription 
received 
> so far. In the meantime, we'll update using this list.
> 
> 
> Moving the FOSS Agenda for Health: Setting the Framework for
> Interoperability
> 
> *8-11 May 2007
> Kuala Lumpur, Malaysia*
> 
> Call for Presentations OSHCA 2007 - Annual Open Source Health Care 
> Alliance Meeting
> 
> This four-day conference provides the opportunity for Free/Open 
Source 
> Software (FOSS) applications in healthcare, its updates and the use 
of 
> FOSS technologies to be presented to participants particularly from 
the 
> developing countries of the Asia-Pacific region. The target 
audience, in 
> addition to the FOSS in Healthcare Community, will include 
interested 
> persons from Ministries of Health and Private Health Care 
Facilities 
> from this region.
> 
> The conference agenda will also include presentations and workshops 
on a 
> variety of issues focussing on interoperability and data exchange. 
Major 
> concerns on affordability and developing human capacity in the 
> promotion, adoption and the use of FOSS applications will be 
deliberated on.
> 
> There will also be concurrent sessions for training of new FOSS 
> programmers in health care to be scheduled during the conference.
> 
> To register your interest in presenting your applications, please 
email 
> a brief description of your application (not more than 250 words) 
and 
> its reference url in plain text or XHTML to: [EMAIL PROTECTED] 
> 
> 
> OSHCA Committee will decide on the final programme, logistics etc.
> For updated information on the conference status and registration 
> information as it becomes available please visit the conference 
site at: 
> http://oshca.org/conference/conf2007/
> 
> In the meantime, please register your interests asap to enable us 
to 
> plan the conference agenda.
> 
> Molly
> Paul wrote:
> 
> >Hi Molly, I'm one of the co-founders of OpenMRS.  Let me know how I
> >can be helpful to you.  Still trying to catch up with the community
> >here, and it seems I need to do some due diligence on OSHCA.
> >
> >Best,
> >-Paul
> >
> >--- In openhealth@yahoogroups.com, Molly Cheah  wrote:
> >  
> >
> >>You're right, Nandalal. I was given the contact to the OpenMRS to
> >>
> >>
> >invite 
> >  
> >
> >>them to the OSHCA conference in May by the new director of ICT 
for IDRC 
> >>as I understand that the project in Africa is quite exciting. As
> >>
> >>
> >soon as 
> >  
> >
> >>I get a firm commitment on the funding for scholarships for those 
> >>outside the ASEAN region, I'll get in touch with them.
> >>
> >>Rgds,
> >>Molly
> >>Nandalal Gunaratne wrote:
> >>
> >>
> >>
> >>>This is just the type of discussion we should have in
> >>>the May OSHCA Conference!!
> >>>
> >>>"FOSS interoperability - from theory to practice"
> >>>
> >>>Nandalal
> >>>--- David Forslund  wrote:
> >

[openhealth] Re: Hi folks..

[Paul]

Hi Karsten,

--- In openhealth@yahoogroups.com, Karsten Hilbert 

> Agree. I'm reading this thread with interest. I have been
> interested in the Concept Dictionary approach ever since I
> learned about OpenMRS a year ago or so. There's a strong
> camp opposed to EAV-only schemata. I have a nagging feeling,
> however, that having a Concept Dictionary approach can be of
> great value where it fits (as a poor-mans export system,
> perhaps ?). I have read most of the OpenMRS docs but haven't
> yet been struck by lightning going "Ah yes ! That's how I'd
> want to use that in GNUmed !!". As I said, I do think I am
> missing out on something very elegant and would like to be
> educated on that. It's the same feeling I have that once I
> eventually get around to implementing forms (as in paper)
> support I will turn to studying NetEpi on that.

Well, Burke and I started down the pathway of a concept dictionary 
based EAV model not due to any divine wisdom on our part, but 
because of the education we received from our mentor, Clem McDonald, 
who is the father of the RMRS, one of the oldest (40+ years) and 
largest clinical information systems I'm aware of.  We thought, if 
it's not broke, let's not try to fix it.  Of course, we've 
modernized and extended out some of the functionalities from the 
RMRS model, but the basic ideas have remained intact.

The most important technical "a-ha" for me was once I got the point 
that the dictionary defines both the questions and the answers 
within an observation.  My favorite example is a simple test in any 
urinalysis, the urine color.  We create a concept for the 
question "urine color" and then define all of the appropriate meta-
data that drives that question.  Like, what is the datatype of the 
concept, what are it's synonyms, what is it's description?  In the 
case of urine color, you might set it's datatype as "coded" so that 
you can make separate concepts for each answer.  (ie, yellow, straw 
colored, clear, etc.)  The magic of this dictionary is that any 
concept can be used throughout the system in a lot of ways.  Want to 
use "urine color" as an answer to another question?  No problem.  
Want to use yellow to describe's someone skin color?  No problem as 
well.

The power of this approach is hard to appreciate until you're in a 
situation where lots of people have lots of things they want to 
characterize in a system.  It allows non-developers to own and 
augment their own notions of what data matters to them, without 
altering the underlying database model.  The RMRS has over 30k of 
these concepts.  If you'd like me to set you up with some examples 
of what this looks like in a live system, just let me know.  I'll 
point you to a demo that you can hack around with.

Hope this is helpful,
-Paul

[openhealth] Re: Hi folks..

[Paul]

Hi Tim, thanks for your interest in investigating collaborating with 
us.

--- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote:
> NetEpi Analysis was designed to deal with the types of data and 
analyses
> which you mention - for example, apart from supporting complex
> cross-tabs (with good support for proportions), basic contingency 
table
> analysis and standard statistical charts (again with confidence 
limits),
> it also does direct and indirectly age-standardised population-
based
> rates (with confidence intervals), and we hope to shortly add 
support
> for log-linear (Poisson and negative-binomial) models for 
counts/rates,
> as well as possibly Bayesian smoothing of rates. And it works 
quickly
> enough for interactive, real-time analysis even with many millions 
of
> records, and the underlying architecture deals well with the sort 
of
> multi-level data you describe eg it supports multi-valued records. 
And
> it has full support for missing data handling. Oh, and it also does
> Google-style indexed searching or free text fields. However, a 
major
> downside is that it only accepts batch loads of data at the moment,
> without incremental updates (although many data sources can be 
loaded
> into one dataset, but they all have to be loaded in one go). That's
> something we also plan to fix as soon as possible, but unless you 
have
> many tens millions of records , periodic batch loading works OK 
(and is
> simpler to set up and maintain than incremental updates, which can 
be
> surprisingly tricky and fragile). But it does support dataset
> versioning, so that the latest version of source data can be 
loaded into
> a new dataset in the background while users continue to use an 
existing
> dataset, and when the new load has completely it is transparently 
used
> for all new analysis sessions. Of course, there are still plenty of
> rough edges and gaps, but it might be a good start, or a partial
> solution. 

Thanks for this overview.  There are so many layers to this whole 
data analysis aspect of medical record repositories.  Thinking from 
left to right, there's the whole set of challenges around 
converting "stacked" database models (where there's one row per 
clinical observation) to the typical "flat" models, where the 
columns of a table are the observations, and each row is some higher 
level of measurement (ie, encounter, patient, etc).  We're working 
quite hard on tools to go from our stacked OpenMRS data repository 
to flat data exports for analysis purposes.  To generate the rows, 
we're developing a cohort builder which allows users to 
interactively look at patient/encounter counts for given clinical 
measurements, and in an OVID style, provide an interface to and/or 
them together to arrive at your final cohort.  If you'd like to see 
this in a demonstration, let me know and I can pass some 
instructions.  To generate the columns, we're developing a tool to 
select the observations of interest, and apply aggregations and/or 
rules to them (IE, last 4 hemoglobins where they occured in the past 
year).

Once you have the data exported, there's the whole issue of what 
interfaces do you support to various analysis software packages.  I 
think the OpenMRS group is fully in support of letting a thousand 
flowers bloom.  As we @ Regenstrief are directly serving a large set 
of clinical sites in Western Kenya, we have to have a solution for 
our own backyard, and so the one we're investigating at this point 
is BIRT.  That being said, we'd love to have a variety of choices, 
and perhaps NetEpi Analysis could be another one.  We'd gladly 
advertise and document ways in which these softwares could work 
together.

>Fairly easy to write hard-coded interfaces to OpenMRS, I
> suspect, either in PHP or Python or both, although a generic 
interface
> would be harder, but possible - maybe a few weeks work. It can 
certainly
> load data directly from a database back-end, although some queries 
to
> flatten the data appropriately might be needed. Further processing 
and
> data transformation can be done in Python as the data are loaded. 

Tim, perhaps I don't understand the scope of your software, but does 
NetEpi analysis generate OLAP cubes or views on the fly as well as 
provide the interface for report generation?

Oh,
> you can use it via the Web front-end, no programming, or via its 
own
> Python API, which is simple enough for interactive command-line 
analysis
> as well as for calling from other things.

I'd like to sick Justin Miranda, the developer currently leading up 
our reporting efforts, on top of what your team has done.  Would you 
mind me passing some contact information along to him?
 
> Yes. Actually, we don't support messaging in NetEpi, yet, but no 
reason
> why it can't. No, that's wrong, one of our application, for real-
time
> ED-based public health surveillance, does use HL7 messaging and 
the data
> is fed into NetEpi Analysis. We do have some very insi

Re: Open source OCR (was Re: [openhealth] Re: Hi folks..)

[Joseph Dal Molin]

UCLA had developed a very good scanning OCR solution . but I don't 
think it was pure FOSS will ask.

Joseph

Tim Churches wrote:
> Tim Churches wrote:
>> Karsten Hilbert wrote:
>>> Well, the path of least resistance here is to scan it and
>>> use it as a background image in some text editor or other so
>>> that what you type appears to be written into the fields
>>> while it is (technically) written on top of the background
>>> image. We then save the result as any other old document
>>> tied into the medical record.
>> No, we need the data in computable form for epidemiological (aggregate)
>> analysis - images of numbers nd characters must be converted to ASCII or
>> Unicode bytes. There is a commercial product, Teleform, which does this
>> reasonably well - see
>> http://www.cardiff.com/products/teleform/index.html - and we may just
>> provide an interface which can load data which has been scanned off
>> hand-written forms using that, but gee, an open source solution would be
>> nice. Suggestions very welcome.
> 
> A few months ago Google released Tesseract OCR, an oCR engine developed
> in the 1990s by Hewlett-Packard. Apparently it was state-of-the-art in
> 1995, but that's over a decade ago, and has not been developed since.
> There don't seem to be any other open source OCR engines around that are
> being actively developed or which are anything more than demos or
> proofs-of-concept. And Teleform seems to have the OCR-from-paper-forms
> market almost to themselves. I think we'll have to build a batch input
> interface that Teleform can be plugged into - I think it exports to XML,
> or at the very least CSV files.
> 
> But if anyone can suggest an alternative for turning data recorded on
> paper forms into data (as opposed to raster image) files, we'd love to
> hear of it.
> 
> Tim C
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
> .
> 

Open source OCR (was Re: [openhealth] Re: Hi folks..)

[Tim Churches]

Tim Churches wrote:
> Karsten Hilbert wrote:
>> Well, the path of least resistance here is to scan it and
>> use it as a background image in some text editor or other so
>> that what you type appears to be written into the fields
>> while it is (technically) written on top of the background
>> image. We then save the result as any other old document
>> tied into the medical record.
> 
> No, we need the data in computable form for epidemiological (aggregate)
> analysis - images of numbers nd characters must be converted to ASCII or
> Unicode bytes. There is a commercial product, Teleform, which does this
> reasonably well - see
> http://www.cardiff.com/products/teleform/index.html - and we may just
> provide an interface which can load data which has been scanned off
> hand-written forms using that, but gee, an open source solution would be
> nice. Suggestions very welcome.

A few months ago Google released Tesseract OCR, an oCR engine developed
in the 1990s by Hewlett-Packard. Apparently it was state-of-the-art in
1995, but that's over a decade ago, and has not been developed since.
There don't seem to be any other open source OCR engines around that are
being actively developed or which are anything more than demos or
proofs-of-concept. And Teleform seems to have the OCR-from-paper-forms
market almost to themselves. I think we'll have to build a batch input
interface that Teleform can be plugged into - I think it exports to XML,
or at the very least CSV files.

But if anyone can suggest an alternative for turning data recorded on
paper forms into data (as opposed to raster image) files, we'd love to
hear of it.

Tim C

Re: [openhealth] Re: Hi folks.. OSHCA conference

[Dr Molly Cheah]

Thanks for your offer Paul. You've probably missed OSHCA's call for 
presentation at its coming conference from May 8-11 2007 in Kuala 
Lumpur. The date had been changed from May 1 to accommodate request from 
those who wish to attend HIMSS Asia-Pacific in S'pore.

We're making some changes to the programme to include a training 
component for new Asian FOSS programmers (the contents are being worked 
out), again focussing on data exchange and interoperability. Our major 
funders (as of now) will be IDRC and UNDP-APDIP's IOSN (ASEAN+3).

Naturally we welcome other assistance not only financial support but 
more crucially presentations of FOSS applications, other resources for 
expertise to impart their knowledge on the wide ranging topics of FOSS 
in healthcare.

Here is a repeat of the call, with the new confirmed dates. We have also 
confirmed the venue as the Federal Hotel, Kuala Lumpur offering us a 
hotel rate of MYR180 nett per room (single/twin-sharing with breakfast). 
At current exchange rate of approx. 3.5 its only USD52 per day.

We're working out with our funders to make available scholarships for 
FOSS advocates who can't afford to come on their own, but feel strongly 
that they would like to share their expertise, experience and 
collaborate with their developing world FOSS enthusiasts especially from 
the Asian region.

So, we would like to welcome anyone to register their interests with us 
asap to help us plan the conference in a better way. I'm off travelling 
for a week and may not be able to respond regularly, but there are 
others on the OSHCA conference technical committee who will do so.

Please bear with us on the slowness of the OSHCA web portal. It's 
temporarily hosted on the MCTC's server from my office, as upto now we 
don't have any funding for OSHCA except for some subscription received 
so far. In the meantime, we'll update using this list.


Moving the FOSS Agenda for Health: Setting the Framework for
Interoperability

*8-11 May 2007
Kuala Lumpur, Malaysia*

Call for Presentations OSHCA 2007 - Annual Open Source Health Care 
Alliance Meeting

This four-day conference provides the opportunity for Free/Open Source 
Software (FOSS) applications in healthcare, its updates and the use of 
FOSS technologies to be presented to participants particularly from the 
developing countries of the Asia-Pacific region. The target audience, in 
addition to the FOSS in Healthcare Community, will include interested 
persons from Ministries of Health and Private Health Care Facilities 
from this region.

The conference agenda will also include presentations and workshops on a 
variety of issues focussing on interoperability and data exchange. Major 
concerns on affordability and developing human capacity in the 
promotion, adoption and the use of FOSS applications will be deliberated on.

There will also be concurrent sessions for training of new FOSS 
programmers in health care to be scheduled during the conference.

To register your interest in presenting your applications, please email 
a brief description of your application (not more than 250 words) and 
its reference url in plain text or XHTML to: [EMAIL PROTECTED] 


OSHCA Committee will decide on the final programme, logistics etc.
For updated information on the conference status and registration 
information as it becomes available please visit the conference site at: 
http://oshca.org/conference/conf2007/

In the meantime, please register your interests asap to enable us to 
plan the conference agenda.

Molly
Paul wrote:

>Hi Molly, I'm one of the co-founders of OpenMRS.  Let me know how I
>can be helpful to you.  Still trying to catch up with the community
>here, and it seems I need to do some due diligence on OSHCA.
>
>Best,
>-Paul
>
>--- In openhealth@yahoogroups.com, Molly Cheah <[EMAIL PROTECTED]> wrote:
>  
>
>>You're right, Nandalal. I was given the contact to the OpenMRS to
>>
>>
>invite 
>  
>
>>them to the OSHCA conference in May by the new director of ICT for IDRC 
>>as I understand that the project in Africa is quite exciting. As
>>
>>
>soon as 
>  
>
>>I get a firm commitment on the funding for scholarships for those 
>>outside the ASEAN region, I'll get in touch with them.
>>
>>Rgds,
>>Molly
>>Nandalal Gunaratne wrote:
>>
>>
>>
>>>This is just the type of discussion we should have in
>>>the May OSHCA Conference!!
>>>
>>>"FOSS interoperability - from theory to practice"
>>>
>>>Nandalal
>>>--- David Forslund <[EMAIL PROTECTED]> wrote:
>>>
>>> 
>>>
>>>  
>>>
Tim Churches wrote:
   



>Paul wrote:
> 
> 
>
>  
>
>>Hi Dave,
>>
>>Our API is built around the standard health
>>   
>>
>>
>>
"objects" within the
   



>>OpenMRS data model (ie, person, encounter, order,
>>   
>>
>>
>>
observation, etc) ,
>>>

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Thomas Beale wrote:
> Tim Churches wrote:
>> The openEHR model is probably relevant - it can be viewed as a more
>> evolved form of the "two-level" model which OpenEMR (and the Regenstrief
>> Clinic for several decades before that) uses. The openEHR people have
>> put forward their work as the basis for an ISO standard - only a
>> proposed standard at this stage. There is a java-based open source
>> openEHR kernel currently available, but it is still in beta or
>> incomplete (I think), and there are some other open-source tools for
>> working with openEHR archetypes, but relatively few people have much
>> experience with this technology and those that do have not published
>> descriptions of their experience except anecdotally (eg "it seems to
>> work"). So, openEHR has promise but it is a rather untrodden path at
>> present, and a complex and twisting one at that with steep (learning)
>> hills (curves) along the way. We are keeping a watching brief on openEHR
>> for potential use in our NetEpi suite of public health/epidemiology
>> tools (see http://www.netepi.org ).
>>   
> you may be interested to know that we are providing training in the NHS 
> Connecting for Health programme on archetype development, templates and 
> Snomed subsetting and binding. Most of the tools for this are open 
> source, and I will make an announcement soon about the latest version 
> releases, which will be in a few days (making the tools 100% ADL 1.4 
> compliant). The NHS has (rightly) specified that any IP they create with 
> these tools is NHS IP, which I think means that the rest of the world 
> will get to see it (they may even favour putting some of the archetypes 
> back into openEHR as the Australian government has already done with 
> many of the archetypes already there). See 
> http://svn.openehr.org/knowledge/archetypes/dev/index.html for access to 
> the existing archetypes.

It will be very interesting to see what the UK NHS does with the
copyright and licensing of openEHR archetypes and specifications which
it creates. It doesn't really have much of a track record for releasing
its IP for wider use, does it? (Very few large govt health authorities
do.) Maybe they will change?

This does raise the issue of licensing of openEHR archetypes and
templates. I'll reproduce here a post I made on this list in Dec 2006 -
it is an issue still not completely resolved (at least not to my
satisfaction), but it is a most important one, I feel:

>>> Posting by Tim Churches to openhealth list 2 Dec 2006

Yes, this is an important point. A question I put to Sebastian Garde
from Central Qld Uni after his presentation at the Health Informatics
Conference in Sydney in Aug 2006 on managing libraries of openEHR
archetypes ("Towards a Repository for Managing Archetypes for Electronic
Health Records", Sebastian Garde, Evelyn J.S. Hovenga, Jana Gränz, Shala
Foozonkhah, Sam Heard - also not available online, alas) was along the
following lines:

Data storage in the openEHR model is controlled and enabled by archetype
definitions, in a manner analogous to the way in which data storage in a
relational database is controlled and enabled by a database schema.
openEHR archetype definitions are documents which are subject to
copyright protection - they are not and cannot be automatically in the
public domain.

Now, the openEHR Foundation presumably publishes all its archetype
definitions under either its "openEHR Free Commercial Use Licence" or
its far more restrictive "openEHR Public Licence". I say presumably
because the only statement I can find the openEHR web site relating to
this is at http://www.openehr.org/about_openehr/t_licensing.htm , which
says:

"# openEHR Public Licence (document), applying to documentary
specifications, including formal specifications in XML and IDL
# openEHR Free Commercial Use Licence, applying to commercial use of
specification materials "

Which of these two licenses apply to the archetype definitions expressed
in ADL available here:
http://my.openehr.org/wsvn/knowledge/archetypes/dev/adl/?rev=0&sc=0
or here: http://oceaninformatics.biz/archetypes/index_en.html
is not crystal clear (and generally it is always better if licensing
arrangements are crystal clear), but we hope that it is the "openEHR
Free Commercial Use License", which is paradoxically much more liberal
than the "openEHR Public License". None of the archetype definitions in
ADL available via the above pages carry any copyright assertion (not
that they strictly need to), nor licensing information (which would be
helpful indeed). The Archetype definitions rendered as HTML pages from
the same places carry just the copyright assertion "Copyright openEHR
Foundation © 2006" but no indication of how they are licensed, if at
all. If no license, then thay are subject to the full protection
provided by national copyright laws, which means you can do very little
with them except read them, and certainly can't share them with third
parties. Thus explicit, c

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Karsten Hilbert wrote:
> On Sun, Feb 18, 2007 at 05:32:54PM +1100, Tim Churches wrote:
> 
>> surprisingly tricky and fragile). But it does support dataset
>> versioning, so that the latest version of source data can be loaded into
>> a new dataset in the background while users continue to use an existing
>> dataset, and when the new load has completely it is transparently used
>> for all new analysis sessions.
> Isn't that what transactions are all about in an MVCC
> database ?

Yes, but it doesn't use PostgreSQL (our data collection facility, NetEpi
Collection, uses PostgreSQL). Also, the versioning is at the level of
entire datasets (equivalent to tables in an SQL database, more or less).

> 
>> would be harder, but possible - maybe a few weeks work. It can certainly
>> load data directly from a database back-end, although some queries to
>> flatten the data appropriately might be needed.
> This might be achievable with a few flattening and/or even
> materialized views inbetween the NetEpi code and the OpenMRS
> schema.

Yes, but would need to be able to use the OpenMRS concept dictionary and
other metadata to be able to flatten the OpenMRS tables/entities stored
in EAV form, and also do statically defined joins between those and
other conventional tables in OpenMRS. Plus a Web front-end to drive it.
all doable, but a few weeks work.

>> also, form scanning just doesn't work as well in practice as people
>> think it should,
> Well, the path of least resistance here is to scan it and
> use it as a background image in some text editor or other so
> that what you type appears to be written into the fields
> while it is (technically) written on top of the background
> image. We then save the result as any other old document
> tied into the medical record.

No, we need the data in computable form for epidemiological (aggregate)
analysis - images of numbers nd characters must be converted to ASCII or
Unicode bytes. There is a commercial product, Teleform, which does this
reasonably well - see
http://www.cardiff.com/products/teleform/index.html - and we may just
provide an interface which can load data which has been scanned off
hand-written forms using that, but gee, an open source solution would be
nice. Suggestions very welcome.

Tim C

Re: [openhealth] Re: Hi folks..

[Thomas Beale]

David Forslund wrote:
>
> It does appear that programming languages seem to be the biggest barrier 
> for this particular open source community.  Some like Java, some like Python, 
> some like PHP, 
> etc.  That was the value of the IDL used in COAS, because it is language 
> independent 
> and really quite easy to read as an interface (as opposed to trying to read 
> WSDL).   It 
> is important for interoperability to have interfaces specified in a 
> language-neutral 
> way, so that, in fact, Python built systems can interoperate with Java, etc.  
>  XML seems now to 
> be the way that people want to do this, but at the cost of an enormous 
> increase in 
> complexity.  And how many Web-Services are actually designed for 
> interoperability.  
> Interoperability in Web-Services seems to be a low priority.  People seem to 
> think that 
> if they can exchange XML documents they are interoperable.  But this does not 
> address the semantic interoperability.   OpenEHR certainly understands this, 
> but 
> OpenEHR itself needs to be able to interoperate with non-OpenEHR systems if 
> we are to 
> really advance the state of healthcare IT.
>   
Some other forthcoming specifications in the openEHR area that may be of 
interest:
- EHR Extract (a few weeks; current draft available on request to 
individuals)
- CDA R2 export mapping
- EN 13606 mapping (this is nearly 1:1, and a bridging openEHR/EN13606 
schema and Xslt should be publishable soon; we are waiting on the CEN 
and ISO processes aroung 13606 to complete)
- virtual EHR API (see my previous post)
- archetype-based query language (already in use; paper to be published 
in MedInfo 2007)
- terminology subsetting query language (already in use; spec to be written)

There are various other things in the pipeline which provide intersystem 
connections, some based on archetypes.

- thomas beale

Re: [openhealth] Re: Hi folks..

[Thomas Beale]

Tim Churches wrote:
> David Forslund wrote:
>   
>>
>
> I was referring to making aspects such as the user interface and
> business logic as general as possible, while still keeping users happy
> by providing a slick, fiendly and productive interface and associated
> conveniences. Inter-system interoperabilty is alo important, but it is
> only one part of the picture. What OpenMRS (and NetEpi) are about is
> providing generic meta-applications which can be easily customised,
> ideally with little or no programming, for particular settings and
> tasks. Business logic and user interface design is crucial for this -
> and both business logic and user interfaces ultimately need to be tied
> into a storage back-end - ideally via abstraction layers.
>   
Sometime in the next few weeks we will publish a 'virtual EHR' API for 
openEHR. It already exists and has been in use for over a year within 
our company. (This API will have the status of an 'industrial' proposal 
within openEHR; from Release 1.0.1, we intend to follow more or less the 
OMG idea of RFPs leading to fairly fully-fledged and implemented 
technical proposals, before embarking on a normalisation process to 
generate a standard from a number of such proposals. This API provides a 
unified application view into an openEHR EHR service ('unified' meaning 
integrating EHR, demographics, terminology, archetypes, templates etc). 
There are a couple of other openEHR APIs around doing similar things; I 
would hope to see a convergence to a single spec within 6 months (the 
community can move pretty fast on this since all the APIs actually exist 
in running software).
>>>   
>>>   
>> I should note here that the COAS model supported the GEHR model which
>> was the predecessor to OpenEHR.  It specifically took into account in 
>> the standardization process.  I still believe that a COAS interface can 
>> be used with OpenEHR, but I don't have the time to actually demonstrate 
>> this. COAS has been shown to work in fairly interesting situations 
>> including epidemiology.   Our implementation is available, of course, as 
>> open source.  What is curious is that there have been, so far, no other
>> open source projects which have attempted to follow this 
>> interoperability path even though an open source example of it has been 
>> out there for more than 7 years.
>> 
>
> After finally locating the COAS documents (with Dave's help), I read
> them about 18 months ago but found them impenetrable and rather complex
> - perhaps most people are, like me, too stupid to be able to follow the
> COAS example? The openEHR stuff I can follow, just.
>   
COAS was good work, and easy enough to understand if you happened to 
come from that kind of technical culture. I would say it is out of date 
now, but has many useful things to be remembered (we have used it as a 
source of inspiration in openEHR service models).
>
>
> Yes, NEHTA, the top-level e-health authority here in Australia, is
> heavily promoting a web services approach, although many people are
> getting on perfectly well with HL7 messaging over encrypted SMTP e-mail,
> using HL7 ACK/NACK at various levels for handshaking to ensure reliable
> delivery (or notification of non-receipt). It has the advantage of using
> ubiquitous, well-understand services (SMTP/POP3 email, as provided by
> thousands of Internet service providers or by one's own off-the-shelf
> Linux system), and it works well over intermittent or unreliable
> networks. Not that I am a fan of HL7 - actually, I regard it as a dog's
> breakfast (functional, after a fashion, but terribly inelegant). And in
> practice HL7 2.x is more a point-to-point interface because ever
> application adopts its own interpretation of the HL7 standards - so
> heaps of message format and semantic "debugging" is always needed. But
> I've learnt that if you don't use HL7, no-one else wants to talk to you...
>   
Don't know whether you know, but an Australian Standards committee is in 
the process of standardising the use of ADL (i.e. openEHR, CEN) 
archetypes for use with HL7v2 messages, and it has been made to work in 
practice as well.
> Dave, how well do Web services handle intermittent (eg dial-up, wireless
> and/or very unreliable) Internet connections with very long latencies
> and low bandwidths, compared to simpler message-based systems? Most
> developing countries and rural areas in many developed countries only
> have very poor connectivity, sometimes having to fall-back to
> sneaker-net (eg floppy discs or memory sticks carried by hand or by
> physical snail-mail between systems).
>   
to be successful, web-services have to generally have coarse-grained 
interfaces and not be 'chatty'; they should also support asynchronous 
communication (sender sends request and sets a callback for receipt of 
reply) - then the transmission characteristics should be the same as for 
messaging.

- thomas beale

Holding the Vision While Achieving Practical Integration/Interoperability Today (was) Re: [openhealth] Re: Hi folks..

[Joseph Dal Molin]

Open source efforts/software like OpenMRS, WorldVistA (VistA Office 
etc.), OSCAR etc. that are focused on diffusion/uptake and continuous 
improvement. All need to have practical tools methods etc. to work 
effectively in the heterogeneous health IT ecosystem. Building on Tim's 
view:

 >> I believe that with a modest upfront investment one can go a long way
 >> toward interoperability.  The
 >> open source community should be leading in this area, because of the
 >> increased cooperation.

What would that modest investment be? Who would be willing to 
collaborate to make it happen? How does a practical approach dance 
effectively with and benefit from the vision/work of the 
"interoperability" expert community?  How can we leverage the OSHCA 
meeting in May to help the open source health community take the 
leadership role?


Joseph


Will Ross wrote:
> What a wonderful discussion.   I am so glad to have Regenstrief's  
> OpenMRS at the table!   I also know there are other lurkers out there  
> (you know who you are!) who can add to the robust discussion.  But my  
> purpose here is to highlight one point.   Paul, Dave and Tim have all  
> mentioned not allowing the pursuit of "perfect" semantic  
> interoperability to interfere with simple incremental improvements  
> that can be realized immediately.   This is in fact one of the  
> hallmarks of the decades of dramatic real-world demonstrations that  
> Regenstrief has brought to central Indiana.   And it is the central  
> tenet of the Connecting For Health (USA version) effort to make  
> records portable and electronic without requiring a rip and replace  
> changeout of all legacy health record systems.   And it was one of  
> the key points in Andy Grove's "Shift Left" address at Stanford this  
> past november.
> 
>http://news-service.stanford.edu/news/2006/november8/med- 
> grove-110806.html
> 
> But we all know this is a marathon, not a sprint.   This year's TEPR  
> conference is the 23rd annual meeting devoted to the immanent  
> transition from paper to digital charting.
> 
>http://www.medrecinst.com/conference/tepr/index.asp
> 
> Meanwhile, in my rural region of California, 2007 may be the year we  
> see adoption of EHR rise above 10% among small practices.   The  
> arrival of new FOSS projects like OpenMRS can only help improve our  
> rate of adoption.
> 
> With best regards,
> 
> [wr]
> 
> - - - - - - - -
> 
> On Feb 17, 2007, at 9:24 PM, David Forslund wrote:
> 
>> Tim Churches wrote:
>>> David Forslund wrote:
>>>
 I've seen no real
 effort in the open source community to embrace interoperability.
 Certainly interoperability has
 been opposed by much of industry until recently, but there is no  
 good
 reason for the open source community to not embrace it.

>>> Dave, interoperability, although good in theory, is not an end in
>>> itself. Thus you have to ask the question: in the settings in  
>>> which open
>>> source health information systems are or are likely to be  
>>> deployed, what
>>> are the "business drivers" or the "business case" for  
>>> interoperability,
>>> and what sort of interoperability?
>>>
>>> Thus, although there is indeed no good reason not to embrace
>>> interoperability, there may be, in many open source deployment  
>>> settings,
>>> no good reason to embrace it, either, given that supporting
>>> interoperability is not without some cost.
>>>
>> I agree with you, with a caveat.  If you plan for interoperability,  
>> the
>> cost isn't very high. Adding it
>> later is much more expensive.  For the patient, the value of
>> interoperability is very high.  Clearly
>> for implementers, the demand for interoperability is not high since it
>> might take away from the
>> local business model.
>>> For example, the COAS specs document is 260 pages long, but if you  
>>> go to
>>> the "Interoperation" chapter in it, it refers you to four other CORBA
>>> specifications, each also several hundred pages long, which need  
>>> to be
>>> assimilated first. So that's a thousand pages. And that's even before
>>> one works out how to implement all this. That's the cost. So unless
>>> there are strong reasons to do this, in the always-resource- 
>>> constrained
>>> world of open source development, it is no wonder it is hardly ever
>>> implemented.
>>>
>> Have you tried to read WS-Services documentation?  It is far more
>> complex than the CORBA specs.
>> Clearly the OMG specs requires an implementer to understand something
>> about CORBA and IDL,
>> but these have been available in book stores for years and there are
>> numerous free implementations
>> around with voluminous tutorials. The discipline of having well- 
>> defined
>> interfaces between services
>> is well worth the time invested to understand them.  You don't have to
>> read all of CORBA to understand
>> the value of COAS.  The UML models contained should go a long way to
>> helping you see the value
>> of the approach and ado

Re: [openhealth] Re: Hi folks..

[Will Ross]

What a wonderful discussion.   I am so glad to have Regenstrief's  
OpenMRS at the table!   I also know there are other lurkers out there  
(you know who you are!) who can add to the robust discussion.  But my  
purpose here is to highlight one point.   Paul, Dave and Tim have all  
mentioned not allowing the pursuit of "perfect" semantic  
interoperability to interfere with simple incremental improvements  
that can be realized immediately.   This is in fact one of the  
hallmarks of the decades of dramatic real-world demonstrations that  
Regenstrief has brought to central Indiana.   And it is the central  
tenet of the Connecting For Health (USA version) effort to make  
records portable and electronic without requiring a rip and replace  
changeout of all legacy health record systems.   And it was one of  
the key points in Andy Grove's "Shift Left" address at Stanford this  
past november.

   http://news-service.stanford.edu/news/2006/november8/med- 
grove-110806.html

But we all know this is a marathon, not a sprint.   This year's TEPR  
conference is the 23rd annual meeting devoted to the immanent  
transition from paper to digital charting.

   http://www.medrecinst.com/conference/tepr/index.asp

Meanwhile, in my rural region of California, 2007 may be the year we  
see adoption of EHR rise above 10% among small practices.   The  
arrival of new FOSS projects like OpenMRS can only help improve our  
rate of adoption.

With best regards,

[wr]

- - - - - - - -

On Feb 17, 2007, at 9:24 PM, David Forslund wrote:

> Tim Churches wrote:
>> David Forslund wrote:
>>
>>> I've seen no real
>>> effort in the open source community to embrace interoperability.
>>> Certainly interoperability has
>>> been opposed by much of industry until recently, but there is no  
>>> good
>>> reason for the open source community to not embrace it.
>>>
>>
>> Dave, interoperability, although good in theory, is not an end in
>> itself. Thus you have to ask the question: in the settings in  
>> which open
>> source health information systems are or are likely to be  
>> deployed, what
>> are the "business drivers" or the "business case" for  
>> interoperability,
>> and what sort of interoperability?
>>
>> Thus, although there is indeed no good reason not to embrace
>> interoperability, there may be, in many open source deployment  
>> settings,
>> no good reason to embrace it, either, given that supporting
>> interoperability is not without some cost.
>>
> I agree with you, with a caveat.  If you plan for interoperability,  
> the
> cost isn't very high. Adding it
> later is much more expensive.  For the patient, the value of
> interoperability is very high.  Clearly
> for implementers, the demand for interoperability is not high since it
> might take away from the
> local business model.
>> For example, the COAS specs document is 260 pages long, but if you  
>> go to
>> the "Interoperation" chapter in it, it refers you to four other CORBA
>> specifications, each also several hundred pages long, which need  
>> to be
>> assimilated first. So that's a thousand pages. And that's even before
>> one works out how to implement all this. That's the cost. So unless
>> there are strong reasons to do this, in the always-resource- 
>> constrained
>> world of open source development, it is no wonder it is hardly ever
>> implemented.
>>
> Have you tried to read WS-Services documentation?  It is far more
> complex than the CORBA specs.
> Clearly the OMG specs requires an implementer to understand something
> about CORBA and IDL,
> but these have been available in book stores for years and there are
> numerous free implementations
> around with voluminous tutorials. The discipline of having well- 
> defined
> interfaces between services
> is well worth the time invested to understand them.  You don't have to
> read all of CORBA to understand
> the value of COAS.  The UML models contained should go a long way to
> helping you see the value
> of the approach and adopting some of the interface principles which
> would make the implementation
> of interoperability much easier in the future.  And there are
> implementations that can be studied.
>>
>>> Sending HL7 messages over SMTP encrypted email is  a wonderful  
>>> idea for
>>> someone who is trying to get the most amount of money for support  
>>> from a
>>> customer, but has little to do with building truly distributed  
>>> systems.
>>>
>>
>> Tell that to the people using encrypted SMTP mail. I suppose it means
>> what one means by "truly distributed systems".
>>
> Of course.  I'm speaking of a system that supports the ability to be
> viewed as a "single" system distributed
> over a network of machines.  P2P is far from a "single" system image.
>>
>>> I think that one should avoid asynchronous, time-delayed  
>>> coordination of
>>> updates to the same record in multiple locations.  What we have done
>>> in COAS is to basically  provide versioning of a record so
>>> that all versions are 

[openhealth] Re: Hi folks..

[Paul]

Hi Molly, I'm one of the co-founders of OpenMRS.  Let me know how I
can be helpful to you.  Still trying to catch up with the community
here, and it seems I need to do some due diligence on OSHCA.

Best,
-Paul

--- In openhealth@yahoogroups.com, Molly Cheah <[EMAIL PROTECTED]> wrote:
>
> You're right, Nandalal. I was given the contact to the OpenMRS to
invite 
> them to the OSHCA conference in May by the new director of ICT for IDRC 
> as I understand that the project in Africa is quite exciting. As
soon as 
> I get a firm commitment on the funding for scholarships for those 
> outside the ASEAN region, I'll get in touch with them.
> 
> Rgds,
> Molly
> Nandalal Gunaratne wrote:
> 
> >This is just the type of discussion we should have in
> >the May OSHCA Conference!!
> >
> >"FOSS interoperability - from theory to practice"
> >
> >Nandalal
> >--- David Forslund <[EMAIL PROTECTED]> wrote:
> >
> >  
> >
> >>Tim Churches wrote:
> >>
> >>
> >>>Paul wrote:
> >>>  
> >>>  
> >>>
> Hi Dave,
> 
> Our API is built around the standard health
> 
> 
> >>"objects" within the
> >>
> >>
> OpenMRS data model (ie, person, encounter, order,
> 
> 
> >>observation, etc) ,
> >>
> >>
> as a way of abstracting out CRUD-type operations
> 
> 
> >>to the database. 
> >>
> >>
> There are layers of API calls on top of this
> 
> 
> >>bedrock which provide
> >>
> >>
> business type functionality (user authentication,
> 
> 
> >>medical logic
> >>
> >>
> services, etc).  Maybe I'm misunderstanding your
> 
> 
> >>question, but
> >>
> >>
> wouldn't "standard" APIs necessitate that the
> 
> 
> >>database schemas
> >>
> >>
> underneath those calls are represented the same
> 
> 
> >>as well?
> >>
> >>
> 
> 
> 
>

Re: [openhealth] Re: Hi folks..

[Molly Cheah]

You're right, Nandalal. I was given the contact to the OpenMRS to invite 
them to the OSHCA conference in May by the new director of ICT for IDRC 
as I understand that the project in Africa is quite exciting. As soon as 
I get a firm commitment on the funding for scholarships for those 
outside the ASEAN region, I'll get in touch with them.

Rgds,
Molly
Nandalal Gunaratne wrote:

>This is just the type of discussion we should have in
>the May OSHCA Conference!!
>
>"FOSS interoperability - from theory to practice"
>
>Nandalal
>--- David Forslund <[EMAIL PROTECTED]> wrote:
>
>  
>
>>Tim Churches wrote:
>>
>>
>>>Paul wrote:
>>>  
>>>  
>>>
Hi Dave,

Our API is built around the standard health


>>"objects" within the
>>
>>
OpenMRS data model (ie, person, encounter, order,


>>observation, etc) ,
>>
>>
as a way of abstracting out CRUD-type operations


>>to the database. 
>>
>>
There are layers of API calls on top of this


>>bedrock which provide
>>
>>
business type functionality (user authentication,


>>medical logic
>>
>>
services, etc).  Maybe I'm misunderstanding your


>>question, but
>>
>>
wouldn't "standard" APIs necessitate that the


>>database schemas
>>
>>
underneath those calls are represented the same


>>as well?
>>
>>

Re: [openhealth] Re: Hi folks..

[Nandalal Gunaratne]

This is just the type of discussion we should have in
the May OSHCA Conference!!

"FOSS interoperability - from theory to practice"

Nandalal
--- David Forslund <[EMAIL PROTECTED]> wrote:

> Tim Churches wrote:
> > Paul wrote:
> >   
> >> Hi Dave,
> >>
> >> Our API is built around the standard health
> "objects" within the
> >> OpenMRS data model (ie, person, encounter, order,
> observation, etc) ,
> >> as a way of abstracting out CRUD-type operations
> to the database. 
> >> There are layers of API calls on top of this
> bedrock which provide
> >> business type functionality (user authentication,
> medical logic
> >> services, etc).  Maybe I'm misunderstanding your
> question, but
> >> wouldn't "standard" APIs necessitate that the
> database schemas
> >> underneath those calls are represented the same
> as well?
> >> 
> The answer is no.  This is the major result of the
> Clinical Observation
> Access Service (COAS) specification from the OMG in
> the late 90's.  It 
> standardized an interface that was independent of
> the underlying
> storage schema.  In a sense this is the same
> question that arises with
> XML.  One can store an XML file with structure
> without having to have a 
> database that has the specific XML schema in it.COAS
> did this without 
> requiring XML.   Take a look at the RLUS work coming
> from 
> hssp.wikispaces.org
> for the follow on to this work.
> >> Part of the challenge our team continually
> struggles with involves
> >> finding that right balance between being
> pragmatic and creating a
> >> framework that's everything to everyone, and
> potentially smolders
> >> under it's own weight.
> >> 
> >
> > Yes, this is an absolutely central problem, and we
> also wrestle with it
> > all the time - the trade=off between specific
> solutions to specific
> > requirements, which are much simpler and quicker
> to implement, and more
> > general solutions to more general requirements,
> which are much harder to
> > design and implement.
> >   
> People may not agree with the COAS effort of the
> OMG, but this was
> exactly its goal and I believe it achieved it.  It
> provides an 
> underlying basic support for interoperability of
> medical records.  It
> doesn't provide all the business logic for
> healthcare which isn't
> required for interoperability.
> >   
> >> We made a fairly conscious decision for
> >> example, not to try to represent the HL7 RIM, as
> it's been our
> >> experience that work in that domain is high on
> promise but lacking in
> >> successful, well vetted implementations.  If on
> the other hand, you
> >> believe there's a way to adapt our API approach
> to be more closely
> >> aligned with existing "standards", yet allowing
> us to continue our
> >> EAV, concept modeling approach to repository
> design, I'd love to hear
> >> your thoughts.
> >> 
> >
> > The openEHR model is probably relevant - it can be
> viewed as a more
> > evolved form of the "two-level" model which
> OpenEMR (and the Regenstrief
> > Clinic for several decades before that) uses. The
> openEHR people have
> > put forward their work as the basis for an ISO
> standard - only a
> > proposed standard at this stage. There is a
> java-based open source
> > openEHR kernel currently available, but it is
> still in beta or
> > incomplete (I think), and there are some other
> open-source tools for
> > working with openEHR archetypes, but relatively
> few people have much
> > experience with this technology and those that do
> have not published
> > descriptions of their experience except
> anecdotally (eg "it seems to
> > work"). So, openEHR has promise but it is a rather
> untrodden path at
> > present, and a complex and twisting one at that
> with steep (learning)
> > hills (curves) along the way. We are keeping a
> watching brief on openEHR
> > for potential use in our NetEpi suite of public
> health/epidemiology
> > tools (see http://www.netepi.org ).
> >   
> I should note here that the COAS model supported the
> GEHR model which
> was the predecessor to OpenEHR.  It specifically
> took into account in 
> the standardization process.  I still believe that a
> COAS interface can 
> be used with OpenEHR, but I don't have the time to
> actually demonstrate 
> this. COAS has been shown to work in fairly
> interesting situations 
> including epidemiology.   Our implementation is
> available, of course, as 
> open source.  What is curious is that there have
> been, so far, no other
> open source projects which have attempted to follow
> this 
> interoperability path even though an open source
> example of it has been 
> out there for more than 7 years.
> >   
> >> Today, our vision of interoperability is through
> standard HL7
> >> messaging, and web-services where they make
> sense.  
> >> 
> >
> > That seems sensible. Have you looked at Mirth?
> http://www.mirthproject.org/
> >   
> Messaging is fine, although using HL7 for
> interoperability has its
> issues.   I think a service oriented

Re: [openhealth] Re: Hi folks..

[Thomas Beale]

Tim Churches wrote:
> Paul wrote:
>   
>> We made a fairly conscious decision for
>> example, not to try to represent the HL7 RIM, as it's been our
>> experience that work in that domain is high on promise but lacking in
>> successful, well vetted implementations.  If on the other hand, you
>> believe there's a way to adapt our API approach to be more closely
>> aligned with existing "standards", yet allowing us to continue our
>> EAV, concept modeling approach to repository design, I'd love to hear
>> your thoughts.
>> 
>
> The openEHR model is probably relevant - it can be viewed as a more
> evolved form of the "two-level" model which OpenEMR (and the Regenstrief
> Clinic for several decades before that) uses. The openEHR people have
> put forward their work as the basis for an ISO standard - only a
> proposed standard at this stage. There is a java-based open source
> openEHR kernel currently available, but it is still in beta or
> incomplete (I think), and there are some other open-source tools for
> working with openEHR archetypes, but relatively few people have much
> experience with this technology and those that do have not published
> descriptions of their experience except anecdotally (eg "it seems to
> work"). So, openEHR has promise but it is a rather untrodden path at
> present, and a complex and twisting one at that with steep (learning)
> hills (curves) along the way. We are keeping a watching brief on openEHR
> for potential use in our NetEpi suite of public health/epidemiology
> tools (see http://www.netepi.org ).
>   
you may be interested to know that we are providing training in the NHS 
Connecting for Health programme on archetype development, templates and 
Snomed subsetting and binding. Most of the tools for this are open 
source, and I will make an announcement soon about the latest version 
releases, which will be in a few days (making the tools 100% ADL 1.4 
compliant). The NHS has (rightly) specified that any IP they create with 
these tools is NHS IP, which I think means that the rest of the world 
will get to see it (they may even favour putting some of the archetypes 
back into openEHR as the Australian government has already done with 
many of the archetypes already there). See 
http://svn.openehr.org/knowledge/archetypes/dev/index.html for access to 
the existing archetypes.
>   
>> Today, our vision of interoperability is through standard HL7
>> messaging, and web-services where they make sense.  
>> 
>
> That seems sensible. Have you looked at Mirth? http://www.mirthproject.org/
>   
the thing to be careful of with HL7v3 messaging is that each 'message' 
is its own standard (well, same as v2 I suppose, but v2 is a lot simpler 
at least). The NHS CfH programme has decided to use CDA rather than 
HL7v3 messages for all clinical messages in the NHS, mainly for this 
reason. See 
http://www.e-health-insider.com/comment_and_analysis/index.cfm?ID=167
CDA will bring its own problems, mainly to do with non-computability of 
various categories of information (it is heavily text-oriented) and lack 
of EHR semantics (CDA semantics are single-document), but it is a step 
in the right direction.
>
> Yes, we also see federation as a key issue. Basically, we think that
> NetEpi needs to be able to operate as a multi-master federated database
> (i.e. any record can be created, edited or deleted on any node of the
> federation), but over potentially low-band and very low reliability
> network links (i.e. subject to frequent and prolonged network
> partition). Furthermore, all this needs to be tightly integrated into
> the application so that update conflicts can be handled nicely. The
> ability to dynamically evolve (on-the-fly) data collection forms and
> other aspects of the database schemas is also a large added
> complication. We have some ideas, proven in practice in other,
> non-health settings, about how to tackle these challenges, but think
> there is perhaps 6-12 person-months work in it to get it to
> production-ready stage - it is very complex. Would be happen to exchange
> ideas with members of the OpenMRS team on this.
>   
actually, federation problems of various kinds are the main use case 
openEHR is being used to solve right now (particularly in the UK). While 
there are many other ways to do it, openEHR does provide some useful 
advantages - the ability to define 'integration' archetypes and 
terminology mappings to perform semantic conversions of data, rather 
than just syntactic. And the use of a 'virtual EHR' API allowing any 
application to interrogate the resulting federated EHR in a standard 
way, including getting documentary (XML, HTML, etc) formats out of it 
(plus of course CEN EN13606/openEHR fully structured Extracts).

Some further information about progress in this area will appear soon on 
the openEHR lists.

- thomas beale

Re: [openhealth] Re: Hi folks..

[Karsten Hilbert]

On Sun, Feb 18, 2007 at 05:32:54PM +1100, Tim Churches wrote:

> surprisingly tricky and fragile). But it does support dataset
> versioning, so that the latest version of source data can be loaded into
> a new dataset in the background while users continue to use an existing
> dataset, and when the new load has completely it is transparently used
> for all new analysis sessions.
Isn't that what transactions are all about in an MVCC
database ?

> would be harder, but possible - maybe a few weeks work. It can certainly
> load data directly from a database back-end, although some queries to
> flatten the data appropriately might be needed.
This might be achievable with a few flattening and/or even
materialized views inbetween the NetEpi code and the OpenMRS
schema.

> also, form scanning just doesn't work as well in practice as people
> think it should,
Well, the path of least resistance here is to scan it and
use it as a background image in some text editor or other so
that what you type appears to be written into the fields
while it is (technically) written on top of the background
image. We then save the result as any other old document
tied into the medical record.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Paul wrote:
> --- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote:
>> Paul wrote:
>>> We would love to hear from folks, in particular who have the following
>>> skill sets:
>>>
>>> 1)  database performance optimization
>>> 2)  OLAP / reporting database design
>>> 3)  Hibernate ORM
>> With respect to 2), you might be interested in NetEpi Analysis. be
>> warned, we haven't worked on it for over 12 months, so its dependencies
>> are all a bit old and thus it is tricky to install, but we hope to get
>> back to it very shortly and make it easier to install. It doesn't do
>> everything you need, but it does do OLAP sort of things, but without the
>> restrictions of OLAP.
>>
>> There'll be a an online and offline/downloadable "screencast" demo of
>> NetEpi Analysis available in March I'm working on the script for it now)
>> - I'll announce it on this list.
> 
> We'll definitely take a look at this.  Thanks for the tip.  One of the
> technical deficiencies of our team is in the OLAP/reporting space. 
> Our long term vision at this point is to have a repository that's
> optimized for incoming data/HL7 and for clinical care purposes
> (optimized for patient-level queries), and another repository which
> shadows the primary for reporting/analysis purposes (higher
> abstraction-level queries by encounter, location, population, program,
> etc.)  So far, we've been able to get away with doing both from a
> single repository as reporting, data analyses can be done as
> non-mission critical tasks in low clinical utilization time periods. 
> I don't believe this will be sustainable over the long run however. 
> For example, our collaborators at PIH have just informed us that their
> OpenMRS instantiation is going "country-wide", and these queries will
> certainly take dedicated horsepower which will likely be continuous.

NetEpi Analysis was designed to deal with the types of data and analyses
which you mention - for example, apart from supporting complex
cross-tabs (with good support for proportions), basic contingency table
analysis and standard statistical charts (again with confidence limits),
it also does direct and indirectly age-standardised population-based
rates (with confidence intervals), and we hope to shortly add support
for log-linear (Poisson and negative-binomial) models for counts/rates,
as well as possibly Bayesian smoothing of rates. And it works quickly
enough for interactive, real-time analysis even with many millions of
records, and the underlying architecture deals well with the sort of
multi-level data you describe eg it supports multi-valued records. And
it has full support for missing data handling. Oh, and it also does
Google-style indexed searching or free text fields. However, a major
downside is that it only accepts batch loads of data at the moment,
without incremental updates (although many data sources can be loaded
into one dataset, but they all have to be loaded in one go). That's
something we also plan to fix as soon as possible, but unless you have
many tens millions of records , periodic batch loading works OK (and is
simpler to set up and maintain than incremental updates, which can be
surprisingly tricky and fragile). But it does support dataset
versioning, so that the latest version of source data can be loaded into
a new dataset in the background while users continue to use an existing
dataset, and when the new load has completely it is transparently used
for all new analysis sessions. Of course, there are still plenty of
rough edges and gaps, but it might be a good start, or a partial
solution. Fairly easy to write hard-coded interfaces to OpenMRS, I
suspect, either in PHP or Python or both, although a generic interface
would be harder, but possible - maybe a few weeks work. It can certainly
load data directly from a database back-end, although some queries to
flatten the data appropriately might be needed. Further processing and
data transformation can be done in Python as the data are loaded. Oh,
you can use it via the Web front-end, no programming, or via its own
Python API, which is simple enough for interactive command-line analysis
as well as for calling from other things.

>>> Additionally, new Java programmers are always welcome to join us.
>> Sorry, we prefer Python, and only use Java if absolutely forced.
>> Speaking of Python, you might be interested in the GNUmed project, which
>> also targets primary care settings, and the GNUmed people are very
>> interested in all sorts of architectural and design issues. GNUmed uses
>> a cross-platform GUI (wxWindows), rather than a Web interface, though.
>> But the design issues are similar.
> 
> Hey, Python is good stuff.  Whatever gets the job done is OK with me.
> :)  Messaging allows one the opportunity for something like NetEpi to
> play nicely with OpenMRS.

Yes. Actually, we don't support messaging in NetEpi, yet, but no reason
why it can't. No, that's wrong, one of our application, for real-time
ED-ba

Re: [openhealth] Re: Hi folks..

[David Forslund]

Paul wrote:
> Dave,
>
> Thanks for your thoughts.  These discussions can get religious fairly
> quickly, so I'll just say that the bottom line for us is a simple one:
>  we're supporting an open-source collaboration less to meet/support
> longstanding specifications that have fairly low uptake to this point,
> and more to create economies of scale in our work.  We don't have the
> luxury of time when it comes to HIV care in Africa/developing world. 
> If there were tangible reasons to work within these frameworks (ie, we
> could insert functionalities into OpenMRS, bring on a team of new
> developers, etc), then we'd certainly consider any possibility. 
> However, it seems like a trap to spend time building on top of specs
> for the sake of doing the "right thing".
>   
>   
>> People may not agree with the COAS effort of the OMG, but this was
>> exactly its goal and I believe it achieved it.  It provides an 
>> underlying basic support for interoperability of medical records.  It
>> doesn't provide all the business logic for healthcare which isn't
>> required for interoperability.
>> 
>
> I personally love efforts like the COAS.  Intellectually sound, gives
> me ideas, etc.  I think it starts to falter as a starting point of
> work though, b/c of the lack of critical code mass around it.  That
> combined with the extra inertia involved in following the spec place
> it in the position it's in now.  We are focused on giving people
> something to touch and feel first and foremost, which compels them to
> understand the underbelly of how we got there, as they inevitably want
> to extend the functionality to meet their specific needs.  Another
> heart and mind won over in the process. :) 
>   
>   
>> Messaging is fine, although using HL7 for interoperability has its
>> issues.   I think a service oriented approach is much more powerful and 
>> provides a stronger layer of interoperability.  It is this approach that
>> is being used in the HSSP effort: http://hssp.wikispaces.org as a joint
>> effort of HL7 and the OMG. To vastly oversimplify it, the HSSP
>> 
> effort is 
>   
>> taking the PIDS/COAS specifications and updating them to the current 
>> popular technologies.  There are RFP's out there that people could join 
>> in to help set these standards.
>> 
>
> I follow the HSSP work.  In particular, the DSS initiative.
>   
>   
>> I should mention that federation with COAS/PIDS was designed in from the
>> beginning and has been
>> demonstrated for quite some time now. The implementation of COAS that
>> OpenEMed has includes
>> the capability of having dynamic data collection without changing the
>> underlying database schema.
>> The key issue in federation is to be able to federate across
>> heterogeneous systems that all utilize
>> an interoperable set of interfaces.  PIDS/COAS can be significantly
>> improved on (and will be shortly), but
>> they provide an excellent example of how to go about this and shouldn't
>> be ignored.
>> 
>
> I'll take a look at OpenEMed.  I assume this is your work? :)  I work
> during my day job, amongst a very large federated repository called
> the Indiana Network for Patient Care (INPC), which stores well over
> 1.2 billion observations for over 2 million patients.  We actually
> have aggregated a majority of all inpatient data for the metropolitan
> Indianapolis area through a federated, centralized approach which
> shadows hospital EMRs into their own standardized database located at
> Regenstrief.  These shadow repositories are aggregated through a
> master provider and master patient index.  It's been our experience
> thus far, that what's really necessary is less code interoperability
> and a greater focus on data interoperability.  Differing sites have
> differing functionalities and clinical workflows.  Therefore we're not
> too sure that inertia needs to be spent upon making sure that higher
> level system functions are synchronized.  Who knows though, we might
> be making a big mistake. :)
>
> Best,
> -Paul
>
>   
I understand and appreciate your viewpoint.   Good specifications can 
enable the differing functionalities
and workflow and still support interoperability.  I think more than data 
interoperability is important.
A common Service Oriented Architecture adds significant value and can 
reduce the cost of data interchange.
Some common functionality required by most is an MPI or an Entity 
Identification Service.  This is critical
when moving between providers.   A record locator service follows right 
after this.  Much has been done
in this area.   It would be good to see this community contribute to the 
larger community in this area.  OpenEMed
has been around quite awhile.  It is probably too late for OpenMRS to 
look at it.  It might have been useful
to look at OpenEMed when OpenMRS was started up.

Dave

Re: [openhealth] Re: Hi folks..

[David Forslund]

Tim Churches wrote:
> David Forslund wrote:
>   
>> I've seen no real
>> effort in the open source community to embrace interoperability.   
>> Certainly interoperability has
>> been opposed by much of industry until recently, but there is no good 
>> reason for the open source community to not embrace it. 
>> 
>
> Dave, interoperability, although good in theory, is not an end in
> itself. Thus you have to ask the question: in the settings in which open
> source health information systems are or are likely to be deployed, what
> are the "business drivers" or the "business case" for interoperability,
> and what sort of interoperability?
>
> Thus, although there is indeed no good reason not to embrace
> interoperability, there may be, in many open source deployment settings,
> no good reason to embrace it, either, given that supporting
> interoperability is not without some cost.
>   
I agree with you, with a caveat.  If you plan for interoperability, the 
cost isn't very high. Adding it
later is much more expensive.  For the patient, the value of 
interoperability is very high.  Clearly
for implementers, the demand for interoperability is not high since it 
might take away from the
local business model. 
> For example, the COAS specs document is 260 pages long, but if you go to
> the "Interoperation" chapter in it, it refers you to four other CORBA
> specifications, each also several hundred pages long, which need to be
> assimilated first. So that's a thousand pages. And that's even before
> one works out how to implement all this. That's the cost. So unless
> there are strong reasons to do this, in the always-resource-constrained
> world of open source development, it is no wonder it is hardly ever
> implemented.
>   
Have you tried to read WS-Services documentation?  It is far more 
complex than the CORBA specs.
Clearly the OMG specs requires an implementer to understand something 
about CORBA and IDL,
but these have been available in book stores for years and there are 
numerous free implementations
around with voluminous tutorials. The discipline of having well-defined 
interfaces between services
is well worth the time invested to understand them.  You don't have to 
read all of CORBA to understand
the value of COAS.  The UML models contained should go a long way to 
helping you see the value
of the approach and adopting some of the interface principles which 
would make the implementation
of interoperability much easier in the future.  And there are 
implementations that can be studied.
>   
>> Sending HL7 messages over SMTP encrypted email is  a wonderful idea for
>> someone who is trying to get the most amount of money for support from a 
>> customer, but has little to do with building truly distributed systems.
>> 
>
> Tell that to the people using encrypted SMTP mail. I suppose it means
> what one means by "truly distributed systems".
>   
Of course.  I'm speaking of a system that supports the ability to be 
viewed as a "single" system distributed
over a network of machines.  P2P is far from a "single" system image.
>   
>> I think that one should avoid asynchronous, time-delayed coordination of 
>> updates to the same record in multiple locations.  What we have done 
>> in COAS is to basically  provide versioning of a record so
>> that all versions are available.
>> 
>
> That skirts the issue of coming up with the currently definitive version
> of a record for analysis purposes, but doesn't solve it. Which version
> should be used when analysing the data?
>   
There obviously is no way of telling this.  This depends on how it is 
used and the type of analysis.
One might want to analyze what changes have occurred in the record for 
audit purposes.  Typically
one is only interested in the latest version of a record.   If you want 
an algorithm to create a "new"
version of a record based on previous versions, this could be done, but 
I don't believe there is
one good solution to this problem.
>   
>> The B-Safer web application in  OpenEMed was used in a
>> distributed environment.  We had very heterogeneous feeds (available in 
>> the clients/translate directory) from  a variety of data sources 
>> (no two alike).   Users of  the data had views that
>> were potentially different for each site. 
>> 
>
> Differing views are what need to be avoided (at least eventually, when
> all nodes in a network have caught up with each other).
>   
Not necessarily.  The different views in our case were driven by the 
security requirements of not
being able to see other participants data except in the aggregate.  In 
the GCPR project the views
were to be in the form that the user was familiar with.  So that a DoD 
record would take on a VA
view when viewed by someone in the VA so that they would see a 
uniformity of records.  And
vice versa for a DoD person viewing VA data.
>   
>> It does appear that programming languages seem to be the biggest barrier 
>> for this particular
>> open source commu

[openhealth] Re: Hi folks..

[Paul]

--- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote:
>
> Paul wrote:
> > We would love to hear from folks, in particular who have the following
> > skill sets:
> > 
> > 1)  database performance optimization
> > 2)  OLAP / reporting database design
> > 3)  Hibernate ORM
> 
> With respect to 2), you might be interested in NetEpi Analysis. be
> warned, we haven't worked on it for over 12 months, so its dependencies
> are all a bit old and thus it is tricky to install, but we hope to get
> back to it very shortly and make it easier to install. It doesn't do
> everything you need, but it does do OLAP sort of things, but without the
> restrictions of OLAP.
> 
> There'll be a an online and offline/downloadable "screencast" demo of
> NetEpi Analysis available in March I'm working on the script for it now)
> - I'll announce it on this list.

We'll definitely take a look at this.  Thanks for the tip.  One of the
technical deficiencies of our team is in the OLAP/reporting space. 
Our long term vision at this point is to have a repository that's
optimized for incoming data/HL7 and for clinical care purposes
(optimized for patient-level queries), and another repository which
shadows the primary for reporting/analysis purposes (higher
abstraction-level queries by encounter, location, population, program,
etc.)  So far, we've been able to get away with doing both from a
single repository as reporting, data analyses can be done as
non-mission critical tasks in low clinical utilization time periods. 
I don't believe this will be sustainable over the long run however. 
For example, our collaborators at PIH have just informed us that their
OpenMRS instantiation is going "country-wide", and these queries will
certainly take dedicated horsepower which will likely be continuous.

> > Additionally, new Java programmers are always welcome to join us.
> 
> Sorry, we prefer Python, and only use Java if absolutely forced.
> Speaking of Python, you might be interested in the GNUmed project, which
> also targets primary care settings, and the GNUmed people are very
> interested in all sorts of architectural and design issues. GNUmed uses
> a cross-platform GUI (wxWindows), rather than a Web interface, though.
> But the design issues are similar.

Hey, Python is good stuff.  Whatever gets the job done is OK with me.
:)  Messaging allows one the opportunity for something like NetEpi to
play nicely with OpenMRS.

Best,
-Paul

[openhealth] Re: Hi folks..

[Paul]

Dave,

Thanks for your thoughts.  These discussions can get religious fairly
quickly, so I'll just say that the bottom line for us is a simple one:
 we're supporting an open-source collaboration less to meet/support
longstanding specifications that have fairly low uptake to this point,
and more to create economies of scale in our work.  We don't have the
luxury of time when it comes to HIV care in Africa/developing world. 
If there were tangible reasons to work within these frameworks (ie, we
could insert functionalities into OpenMRS, bring on a team of new
developers, etc), then we'd certainly consider any possibility. 
However, it seems like a trap to spend time building on top of specs
for the sake of doing the "right thing".
  
> People may not agree with the COAS effort of the OMG, but this was
> exactly its goal and I believe it achieved it.  It provides an 
> underlying basic support for interoperability of medical records.  It
> doesn't provide all the business logic for healthcare which isn't
> required for interoperability.

I personally love efforts like the COAS.  Intellectually sound, gives
me ideas, etc.  I think it starts to falter as a starting point of
work though, b/c of the lack of critical code mass around it.  That
combined with the extra inertia involved in following the spec place
it in the position it's in now.  We are focused on giving people
something to touch and feel first and foremost, which compels them to
understand the underbelly of how we got there, as they inevitably want
to extend the functionality to meet their specific needs.  Another
heart and mind won over in the process. :) 
  
> Messaging is fine, although using HL7 for interoperability has its
> issues.   I think a service oriented approach is much more powerful and 
> provides a stronger layer of interoperability.  It is this approach that
> is being used in the HSSP effort: http://hssp.wikispaces.org as a joint
> effort of HL7 and the OMG. To vastly oversimplify it, the HSSP
effort is 
> taking the PIDS/COAS specifications and updating them to the current 
> popular technologies.  There are RFP's out there that people could join 
> in to help set these standards.

I follow the HSSP work.  In particular, the DSS initiative.
  
> I should mention that federation with COAS/PIDS was designed in from the
> beginning and has been
> demonstrated for quite some time now. The implementation of COAS that
> OpenEMed has includes
> the capability of having dynamic data collection without changing the
> underlying database schema.
> The key issue in federation is to be able to federate across
> heterogeneous systems that all utilize
> an interoperable set of interfaces.  PIDS/COAS can be significantly
> improved on (and will be shortly), but
> they provide an excellent example of how to go about this and shouldn't
> be ignored.

I'll take a look at OpenEMed.  I assume this is your work? :)  I work
during my day job, amongst a very large federated repository called
the Indiana Network for Patient Care (INPC), which stores well over
1.2 billion observations for over 2 million patients.  We actually
have aggregated a majority of all inpatient data for the metropolitan
Indianapolis area through a federated, centralized approach which
shadows hospital EMRs into their own standardized database located at
Regenstrief.  These shadow repositories are aggregated through a
master provider and master patient index.  It's been our experience
thus far, that what's really necessary is less code interoperability
and a greater focus on data interoperability.  Differing sites have
differing functionalities and clinical workflows.  Therefore we're not
too sure that inertia needs to be spent upon making sure that higher
level system functions are synchronized.  Who knows though, we might
be making a big mistake. :)

Best,
-Paul

Re: [openhealth] Re: Hi folks..

[Tim Churches]

David Forslund wrote:
> I've seen no real
> effort in the open source community to embrace interoperability.   
> Certainly interoperability has
> been opposed by much of industry until recently, but there is no good 
> reason for the open source community to not embrace it. 

Dave, interoperability, although good in theory, is not an end in
itself. Thus you have to ask the question: in the settings in which open
source health information systems are or are likely to be deployed, what
are the "business drivers" or the "business case" for interoperability,
and what sort of interoperability?

Thus, although there is indeed no good reason not to embrace
interoperability, there may be, in many open source deployment settings,
no good reason to embrace it, either, given that supporting
interoperability is not without some cost.

For example, the COAS specs document is 260 pages long, but if you go to
the "Interoperation" chapter in it, it refers you to four other CORBA
specifications, each also several hundred pages long, which need to be
assimilated first. So that's a thousand pages. And that's even before
one works out how to implement all this. That's the cost. So unless
there are strong reasons to do this, in the always-resource-constrained
world of open source development, it is no wonder it is hardly ever
implemented.

> Sending HL7 messages over SMTP encrypted email is  a wonderful idea for
> someone who is trying to get the most amount of money for support from a 
> customer, but has little to do with building truly distributed systems.

Tell that to the people using encrypted SMTP mail. I suppose it means
what one means by "truly distributed systems".

> I think that one should avoid asynchronous, time-delayed coordination of 
> updates to the same record in multiple locations.  What we have done 
> in COAS is to basically  provide versioning of a record so
> that all versions are available.

That skirts the issue of coming up with the currently definitive version
of a record for analysis purposes, but doesn't solve it. Which version
should be used when analysing the data?

> The B-Safer web application in  OpenEMed was used in a
> distributed environment.  We had very heterogeneous feeds (available in 
> the clients/translate directory) from  a variety of data sources 
> (no two alike).   Users of  the data had views that
> were potentially different for each site. 

Differing views are what need to be avoided (at least eventually, when
all nodes in a network have caught up with each other).

> It does appear that programming languages seem to be the biggest barrier 
> for this particular
> open source community.  Some like Java, some like Python, some like PHP, 
> etc.  That was
> the value of the IDL used in COAS, because it is language independent 
> and really quite easy to read as an interface (as opposed to trying to 
> read WSDL).

If I type "python IDL" into Google, I get hits for Python and IDL, the
matrix language (like Matlab), but not IDL as in COAS. In other words,
CORBA support is not exactly mainstream, or even a well-supported niche.
Neither is openEHR (yet, maybe some day).

> It  is important
> for interoperability to have interfaces specified in a language-neutral 
> way, so that, in fact,
> Python built systems can interoperate with Java, etc.

Well, it depends what the aim is. If clinic A simply needs to share data
with clinics B and C, and none of them currently have information
systems, then installing the same software in all of them and using less
general means to share data between those clinics may be the easiest
path to take. Yes, that's short-sighted, but in many places it is
important to walk before you can run. In any case, systems are not set
in stone - all information systems have a limited life span and it is
wrong to forgo an adequate but sub-optimal system now while waiting for
a perfect system tomorrow. With open source, you can largely have both.

If the aim is to drop software into the midst of a modern large hospital
in a developed country, then what you say is correct.

Tim C

[openhealth] Re: Hi folks..

[Paul]

Hi Tim,

> > Part of the challenge our team continually struggles with involves
> > finding that right balance between being pragmatic and creating a
> > framework that's everything to everyone, and potentially smolders
> > under it's own weight.
> 
> Yes, this is an absolutely central problem, and we also wrestle with it
> all the time - the trade=off between specific solutions to specific
> requirements, which are much simpler and quicker to implement, and more
> general solutions to more general requirements, which are much harder to
> design and implement.

Nice to see some other folks struggling with this as well (grin).  A
strong driving force for our work was an attempt to be as accessible
as possible intellectually, without losing technical competency in the
process.  We want implementers in these developing countries (who
often lack PhD-level CS backgrounds, and for that matter are self
taught) to learn how to fish instead of being fed.  Therefore, we tend
to shy away from a lot of the OMG work, for example.  My personal bias
is that projects such as these can be conceptually beautiful (and I
really like to model in these ways), but this often limits those who
can contribute in substantive ways.  We really wanted to be focus on
being inviting to a potential developer, and strive to foster
collaboration. :)

> The openEHR model is probably relevant - it can be viewed as a more
> evolved form of the "two-level" model which OpenEMR (and the Regenstrief
> Clinic for several decades before that) uses. The openEHR people have
> put forward their work as the basis for an ISO standard - only a
> proposed standard at this stage. There is a java-based open source
> openEHR kernel currently available, but it is still in beta or
> incomplete (I think), and there are some other open-source tools for
> working with openEHR archetypes, but relatively few people have much
> experience with this technology and those that do have not published
> descriptions of their experience except anecdotally (eg "it seems to
> work"). So, openEHR has promise but it is a rather untrodden path at
> present, and a complex and twisting one at that with steep (learning)
> hills (curves) along the way. We are keeping a watching brief on openEHR
> for potential use in our NetEpi suite of public health/epidemiology
> tools (see http://www.netepi.org ).

I assume that by "two-level" you refer to our notions of concept
dictionary tables as relationships to observation style tables? 
Thanks for the reminder on OpenEHR.  We've taken a look at this work,
and perhaps we should take a look again (we started OpenMRS modeling
in early 2004).

> > Today, our vision of interoperability is through standard HL7
> > messaging, and web-services where they make sense.  
> 
> That seems sensible. Have you looked at Mirth?
http://www.mirthproject.org/

Sure have.  We actually use HAPI as our foundation, however.
 
> Yes, we also see federation as a key issue. Basically, we think that
> NetEpi needs to be able to operate as a multi-master federated database
> (i.e. any record can be created, edited or deleted on any node of the
> federation), but over potentially low-band and very low reliability
> network links (i.e. subject to frequent and prolonged network
> partition). Furthermore, all this needs to be tightly integrated into
> the application so that update conflicts can be handled nicely. The
> ability to dynamically evolve (on-the-fly) data collection forms and
> other aspects of the database schemas is also a large added
> complication. We have some ideas, proven in practice in other,
> non-health settings, about how to tackle these challenges, but think
> there is perhaps 6-12 person-months work in it to get it to
> production-ready stage - it is very complex. Would be happen to exchange
> ideas with members of the OpenMRS team on this.

We'd relish this conversation.  I think our design goals around
federation might be a little broader than what you're describing
however.  In my simplistic view of HIE, it's all about uniquely
identifying users, patients (or people depending on your level of
abstraction), and concepts to create consolidated patient-centric
records across multiple systems.  Strong use of standardized
vocabularies and dictionary/EAV-based data models take care of concept
matching.  MPIs take care of the other two.  It's plausible that
depending on the environment, implementations of OpenMRS will value
demographic attributes differently.  In fact, we allow implementers to
define their own within the framework.  That being said, we want to
support federating two data sources as if they've completely naive to
each other, at least on the OpenMRS side.

> Finally, can someone from OpenMRS give a presentation atteh OSCHCA
> conference in Kuala Lumpur in may 2007? I suggested OpenMRS as a
> potential conference topic to the organising committee, and I am sure
> they would be delighted if someone could talk about it.

That's a kind offer

Re: [openhealth] Re: Hi folks..

[Tim Churches]

David Forslund wrote:
> Tim Churches wrote:
>> Paul wrote:
>>> Part of the challenge our team continually struggles with involves
>>> finding that right balance between being pragmatic and creating a
>>> framework that's everything to everyone, and potentially smolders
>>> under it's own weight.
>>> 
>> Yes, this is an absolutely central problem, and we also wrestle with it
>> all the time - the trade=off between specific solutions to specific
>> requirements, which are much simpler and quicker to implement, and more
>> general solutions to more general requirements, which are much harder to
>> design and implement.
>>   
> People may not agree with the COAS effort of the OMG, but this was
> exactly its goal and I believe it achieved it.  It provides an 
> underlying basic support for interoperability of medical records.  It
> doesn't provide all the business logic for healthcare which isn't
> required for interoperability.

I was referring to making aspects such as the user interface and
business logic as general as possible, while still keeping users happy
by providing a slick, fiendly and productive interface and associated
conveniences. Inter-system interoperabilty is alo important, but it is
only one part of the picture. What OpenMRS (and NetEpi) are about is
providing generic meta-applications which can be easily customised,
ideally with little or no programming, for particular settings and
tasks. Business logic and user interface design is crucial for this -
and both business logic and user interfaces ultimately need to be tied
into a storage back-end - ideally via abstraction layers.

>>> We made a fairly conscious decision for
>>> example, not to try to represent the HL7 RIM, as it's been our
>>> experience that work in that domain is high on promise but lacking in
>>> successful, well vetted implementations.  If on the other hand, you
>>> believe there's a way to adapt our API approach to be more closely
>>> aligned with existing "standards", yet allowing us to continue our
>>> EAV, concept modeling approach to repository design, I'd love to hear
>>> your thoughts.
>>> 
>> The openEHR model is probably relevant - it can be viewed as a more
>> evolved form of the "two-level" model which OpenEMR (and the Regenstrief
>> Clinic for several decades before that) uses. The openEHR people have
>> put forward their work as the basis for an ISO standard - only a
>> proposed standard at this stage. There is a java-based open source
>> openEHR kernel currently available, but it is still in beta or
>> incomplete (I think), and there are some other open-source tools for
>> working with openEHR archetypes, but relatively few people have much
>> experience with this technology and those that do have not published
>> descriptions of their experience except anecdotally (eg "it seems to
>> work"). So, openEHR has promise but it is a rather untrodden path at
>> present, and a complex and twisting one at that with steep (learning)
>> hills (curves) along the way. We are keeping a watching brief on openEHR
>> for potential use in our NetEpi suite of public health/epidemiology
>> tools (see http://www.netepi.org ).
>>   
> I should note here that the COAS model supported the GEHR model which
> was the predecessor to OpenEHR.  It specifically took into account in 
> the standardization process.  I still believe that a COAS interface can 
> be used with OpenEHR, but I don't have the time to actually demonstrate 
> this. COAS has been shown to work in fairly interesting situations 
> including epidemiology.   Our implementation is available, of course, as 
> open source.  What is curious is that there have been, so far, no other
> open source projects which have attempted to follow this 
> interoperability path even though an open source example of it has been 
> out there for more than 7 years.

After finally locating the COAS documents (with Dave's help), I read
them about 18 months ago but found them impenetrable and rather complex
- perhaps most people are, like me, too stupid to be able to follow the
COAS example? The openEHR stuff I can follow, just.

And since no-one else (except Dave) was doing COAS, I didn't think we
should either - there are very strong network effects (as in
http://en.wikipedia.org/wiki/Network_effect ) with these things, or in
COAS's case, anti-network effects.

>>> Today, our vision of interoperability is through standard HL7
>>> messaging, and web-services where they make sense.  
>>> 
>> That seems sensible. Have you looked at Mirth? http://www.mirthproject.org/
>>   
> Messaging is fine, although using HL7 for interoperability has its
> issues.   I think a service oriented approach is much more powerful and 
> provides a stronger layer of interoperability.  It is this approach that
> is being used in the HSSP effort: http://hssp.wikispaces.org as a joint
> effort of HL7 and the OMG. To vastly oversimplify it, the HSSP effort is 
> taking the PIDS/COAS specifications and updatin

Re: [openhealth] Re: Hi folks..

[David Forslund]

Tim Churches wrote:
> Paul wrote:
>   
>> Hi Dave,
>>
>> Our API is built around the standard health "objects" within the
>> OpenMRS data model (ie, person, encounter, order, observation, etc) ,
>> as a way of abstracting out CRUD-type operations to the database. 
>> There are layers of API calls on top of this bedrock which provide
>> business type functionality (user authentication, medical logic
>> services, etc).  Maybe I'm misunderstanding your question, but
>> wouldn't "standard" APIs necessitate that the database schemas
>> underneath those calls are represented the same as well?
>> 
The answer is no.  This is the major result of the Clinical Observation
Access Service (COAS) specification from the OMG in the late 90's.  It 
standardized an interface that was independent of the underlying
storage schema.  In a sense this is the same question that arises with
XML.  One can store an XML file with structure without having to have a 
database that has the specific XML schema in it.COAS did this without 
requiring XML.   Take a look at the RLUS work coming from 
hssp.wikispaces.org
for the follow on to this work.
>> Part of the challenge our team continually struggles with involves
>> finding that right balance between being pragmatic and creating a
>> framework that's everything to everyone, and potentially smolders
>> under it's own weight.
>> 
>
> Yes, this is an absolutely central problem, and we also wrestle with it
> all the time - the trade=off between specific solutions to specific
> requirements, which are much simpler and quicker to implement, and more
> general solutions to more general requirements, which are much harder to
> design and implement.
>   
People may not agree with the COAS effort of the OMG, but this was
exactly its goal and I believe it achieved it.  It provides an 
underlying basic support for interoperability of medical records.  It
doesn't provide all the business logic for healthcare which isn't
required for interoperability.
>   
>> We made a fairly conscious decision for
>> example, not to try to represent the HL7 RIM, as it's been our
>> experience that work in that domain is high on promise but lacking in
>> successful, well vetted implementations.  If on the other hand, you
>> believe there's a way to adapt our API approach to be more closely
>> aligned with existing "standards", yet allowing us to continue our
>> EAV, concept modeling approach to repository design, I'd love to hear
>> your thoughts.
>> 
>
> The openEHR model is probably relevant - it can be viewed as a more
> evolved form of the "two-level" model which OpenEMR (and the Regenstrief
> Clinic for several decades before that) uses. The openEHR people have
> put forward their work as the basis for an ISO standard - only a
> proposed standard at this stage. There is a java-based open source
> openEHR kernel currently available, but it is still in beta or
> incomplete (I think), and there are some other open-source tools for
> working with openEHR archetypes, but relatively few people have much
> experience with this technology and those that do have not published
> descriptions of their experience except anecdotally (eg "it seems to
> work"). So, openEHR has promise but it is a rather untrodden path at
> present, and a complex and twisting one at that with steep (learning)
> hills (curves) along the way. We are keeping a watching brief on openEHR
> for potential use in our NetEpi suite of public health/epidemiology
> tools (see http://www.netepi.org ).
>   
I should note here that the COAS model supported the GEHR model which
was the predecessor to OpenEHR.  It specifically took into account in 
the standardization process.  I still believe that a COAS interface can 
be used with OpenEHR, but I don't have the time to actually demonstrate 
this. COAS has been shown to work in fairly interesting situations 
including epidemiology.   Our implementation is available, of course, as 
open source.  What is curious is that there have been, so far, no other
open source projects which have attempted to follow this 
interoperability path even though an open source example of it has been 
out there for more than 7 years.
>   
>> Today, our vision of interoperability is through standard HL7
>> messaging, and web-services where they make sense.  
>> 
>
> That seems sensible. Have you looked at Mirth? http://www.mirthproject.org/
>   
Messaging is fine, although using HL7 for interoperability has its
issues.   I think a service oriented approach is much more powerful and 
provides a stronger layer of interoperability.  It is this approach that
is being used in the HSSP effort: http://hssp.wikispaces.org as a joint
effort of HL7 and the OMG. To vastly oversimplify it, the HSSP effort is 
taking the PIDS/COAS specifications and updating them to the current 
popular technologies.  There are RFP's out there that people could join 
in to help set these standards.
>   
>> Those who want to
>> extend our code fun

Re: [openhealth] Re: Hi folks..

[Tim Churches]

Paul wrote:
> Hi Dave,
> 
> Our API is built around the standard health "objects" within the
> OpenMRS data model (ie, person, encounter, order, observation, etc) ,
> as a way of abstracting out CRUD-type operations to the database. 
> There are layers of API calls on top of this bedrock which provide
> business type functionality (user authentication, medical logic
> services, etc).  Maybe I'm misunderstanding your question, but
> wouldn't "standard" APIs necessitate that the database schemas
> underneath those calls are represented the same as well?
> 
> Part of the challenge our team continually struggles with involves
> finding that right balance between being pragmatic and creating a
> framework that's everything to everyone, and potentially smolders
> under it's own weight.

Yes, this is an absolutely central problem, and we also wrestle with it
all the time - the trade=off between specific solutions to specific
requirements, which are much simpler and quicker to implement, and more
general solutions to more general requirements, which are much harder to
design and implement.

> We made a fairly conscious decision for
> example, not to try to represent the HL7 RIM, as it's been our
> experience that work in that domain is high on promise but lacking in
> successful, well vetted implementations.  If on the other hand, you
> believe there's a way to adapt our API approach to be more closely
> aligned with existing "standards", yet allowing us to continue our
> EAV, concept modeling approach to repository design, I'd love to hear
> your thoughts.

The openEHR model is probably relevant - it can be viewed as a more
evolved form of the "two-level" model which OpenEMR (and the Regenstrief
Clinic for several decades before that) uses. The openEHR people have
put forward their work as the basis for an ISO standard - only a
proposed standard at this stage. There is a java-based open source
openEHR kernel currently available, but it is still in beta or
incomplete (I think), and there are some other open-source tools for
working with openEHR archetypes, but relatively few people have much
experience with this technology and those that do have not published
descriptions of their experience except anecdotally (eg "it seems to
work"). So, openEHR has promise but it is a rather untrodden path at
present, and a complex and twisting one at that with steep (learning)
hills (curves) along the way. We are keeping a watching brief on openEHR
for potential use in our NetEpi suite of public health/epidemiology
tools (see http://www.netepi.org ).

> Today, our vision of interoperability is through standard HL7
> messaging, and web-services where they make sense.  

That seems sensible. Have you looked at Mirth? http://www.mirthproject.org/

> Those who want to
> extend our code functionality will be able to do so through "modules"
> which are code extensions ala Firefox.
> 
> Federation is rising higher on our lists as an important feature of
> the platform.  People are needing this functionality within
> implementations.   From our perspective, the secret sauce to make that
> happen is robust person matching algorithms between systems, as we
> already have the capability to link OpenMRS medical concepts to
> standardized vocabularies.  That being said, we are in the planning
> stages (as of literally the past 3-4 weeks) to add statistical
> matching algorithm functionality to our framework.  Some of my
> colleagues @ Regenstrief have a lot of experience in that space, and
> are interested in adding that to our code base.  So stay tuned, but as
> it stands right now, federation could be achieved if MPI functionality
> was in place.

Yes, we also see federation as a key issue. Basically, we think that
NetEpi needs to be able to operate as a multi-master federated database
(i.e. any record can be created, edited or deleted on any node of the
federation), but over potentially low-band and very low reliability
network links (i.e. subject to frequent and prolonged network
partition). Furthermore, all this needs to be tightly integrated into
the application so that update conflicts can be handled nicely. The
ability to dynamically evolve (on-the-fly) data collection forms and
other aspects of the database schemas is also a large added
complication. We have some ideas, proven in practice in other,
non-health settings, about how to tackle these challenges, but think
there is perhaps 6-12 person-months work in it to get it to
production-ready stage - it is very complex. Would be happen to exchange
ideas with members of the OpenMRS team on this.

Finally, can someone from OpenMRS give a presentation atteh OSCHCA
conference in Kuala Lumpur in may 2007? I suggested OpenMRS as a
potential conference topic to the organising committee, and I am sure
they would be delighted if someone could talk about it.

Tim C

> --- In openhealth@yahoogroups.com, David Forslund <[EMAIL PROTECTED]> wrote:
>> Paul,
>> I have a question as to the inter

[openhealth] Re: Hi folks..

[Paul]

Hi Dave,

Our API is built around the standard health "objects" within the
OpenMRS data model (ie, person, encounter, order, observation, etc) ,
as a way of abstracting out CRUD-type operations to the database. 
There are layers of API calls on top of this bedrock which provide
business type functionality (user authentication, medical logic
services, etc).  Maybe I'm misunderstanding your question, but
wouldn't "standard" APIs necessitate that the database schemas
underneath those calls are represented the same as well?

Part of the challenge our team continually struggles with involves
finding that right balance between being pragmatic and creating a
framework that's everything to everyone, and potentially smolders
under it's own weight.  We made a fairly conscious decision for
example, not to try to represent the HL7 RIM, as it's been our
experience that work in that domain is high on promise but lacking in
successful, well vetted implementations.  If on the other hand, you
believe there's a way to adapt our API approach to be more closely
aligned with existing "standards", yet allowing us to continue our
EAV, concept modeling approach to repository design, I'd love to hear
your thoughts.

Today, our vision of interoperability is through standard HL7
messaging, and web-services where they make sense.  Those who want to
extend our code functionality will be able to do so through "modules"
which are code extensions ala Firefox.

Federation is rising higher on our lists as an important feature of
the platform.  People are needing this functionality within
implementations.   From our perspective, the secret sauce to make that
happen is robust person matching algorithms between systems, as we
already have the capability to link OpenMRS medical concepts to
standardized vocabularies.  That being said, we are in the planning
stages (as of literally the past 3-4 weeks) to add statistical
matching algorithm functionality to our framework.  Some of my
colleagues @ Regenstrief have a lot of experience in that space, and
are interested in adding that to our code base.  So stay tuned, but as
it stands right now, federation could be achieved if MPI functionality
was in place.

Hope this is helpful.
-Paul


--- In openhealth@yahoogroups.com, David Forslund <[EMAIL PROTECTED]> wrote:
>
> Paul,
> I have a question as to the interoperability of OpenMRS.  At what
> level can or could it interoperate with other systems?  It seems to have
> its own API rather than some of the "standard" APIs out there.   This
> information says that OpenMRS isn't another "stovepipe", but only talks
> of how others can use it as a building block for their system.  It is 
> clearly
> open, but this alone doesn't mean that it is interoperable with other 
> existing
> systems.  In addition, can it be used in a "federated" environment where
> information is linked together from a variety of locations? 
> 
> Thanks,
> 
> Dave Forslund
> 
> Paul wrote:
> >
> > I stumbled across this mailing list in my Google travels, and I
> > thought I'd drop a quick note to you all, as you seem like likely
> > allies in the type of work our group is fostering. I'm one of the
> > co-founders of the OpenMRS (http://www.openmrs.org 
> > ) collaborative, and
> > we're always looking for folks interested in creating HIT
> > infrastructures for developing countries. Here's a quick overview of
> > our project:
> >
> > --
> >
> > I. What is OpenMRS?
> > Our world continues to be ravaged by a pandemic of epic proportions,
> > as over 40 million people are infected with or dying from HIV. The
> > vast majority of these people (up to 95%) are in developing countries.
> > The severity of this pandemic necessitates rapid, coordinated efforts
> > toward HIV prevention and treatment which rely upon efficient
> > information management. In 2004, researchers at the Regenstrief
> > Institute (http://www.regenstrief.org ) 
> > served as consultants to scale
> > up a pre-existing MS Access®-based HIV management system within
> > western Kenya. Their response was to begin the design and development
> > of the AMPATH Medical Record System (AMRS).
> >
> > When work on this project began in earnest, the team investigated
> > other "best of breed" solutions. It became clear that the
> > overwhelming need for basic clinical data management (often to provide
> > outcome data to funding agencies) along with the needs for rapid
> > solutions in the face of limited technical resources typically led to
> > disparate, "stovepipe" efforts which often stored computer
> > uninterpretable clinical data that rarely scaled well in both size and
> > functionality. To combat these common shortcomings, the AMRS team
> > evolved their early work into a collaboration with Harvard's Partners
> > In Health (PIH) initiative (http://www.pih.org ). 
> > The product of this
> > collaboration, OpenMRS (http://www.openmrs.org 
> >