Re: [openhealth] Re: Question re OpenMRS data entry forms

[Tim Churches]

Paul wrote:
> Well, yes.. we have a module within OpenMRS that allows data entry 
> using Microsoft InfoPath client.  However, we're using the client 
> that's a part of any base Microsoft Office install.  From our 
> perspective, that was as close to commodity software as you could get.

OK. I wasn't sure about this because I have the full Australian version
of Microsoft Office 2003 installed on my Windows box here at home, and
it doesn't include any InfoPath client - so when I try to access a data
form on the demo OpenMRS system I just see the InfoPath XML form
definition, not a rendered form.

> Why do we use InfoPath alongside OpenMRS?  A little background might 
> be helpful.  In short, we're big fans of the MVC design pattern.  In 
> our data model, you've maybe understood the concept dictionary 
> approach, but you might not have noticed our "form" objects.

No, that's the first thing I looked at, as it is the issue that has
vexed us.

> In our 
> world, a patient has 1 to n encounters, and within each clinical 
> encounter, 1 to n "forms" can be collected.  Forms are merely 
> collections of data, made up of 1 to n fields.  Each field points to 
> a concept in our system.

That's almost identical to the data model used in NetEpi Collection,
except that instead of "encounters" each patient/person has zero or more
"cases" or "syndromes" (with associated case definitions). But each case
in a person has zero or more forms of different types associated with
it, in either a 1-to-1 relationship or a 1-to-many relationship. We also
capture the relationship between cases and their contacts (since the
focus is communicable disease outbreaks), but that is analogous to the
Relationships entity in OpenMRS. We don't have a concept dictionary,
however. We did think about it, and have implemented such a thing
(called a "metadata database") for our population-based
computer-assisted telephone interview survey system, but the
communicable disease people didn't want to be constrained by a concept
dictionary. However, we plan to retrofit one, which will use SNOMED CT
as well as LOINC and local concepts. That is, if openEHR doesn't become
a viable option first, as it promises to handle much of this (i.e an
evolvable "concept dictionary" with constraints etc, and terminology
bindings, all drivig data storage and retrieval.

>  We've abstracted out these notions for 
> storage in our repository, so that we can render these forms using a 
> number of different data entry mechanisms, perhaps even 
> simultaneously.  IE, web page, OCR'ed form software, PDAs, etc.  Our 
> first, most pressing data entry need was through our web interface 
> however, so we went down the path of looking at open source MVC-based 
> data entry techniques.   We naturally zeroed in on XForms.  
> Unfortunately, XForms technology is still quite green, and 
> implementations are either feature poor or just don't feel right.  

Xforms is a quagmire best avoided.

> Microsoft InfoPath, however.. is pretty damn impressive.  InfoPath 
> can take form schemas that we render in XML, and the application 
> allows one to both render style sheets for the user interface around 
> these schemas (complete with constraints around the metadata we 
> define in our dictionary) and then additionally serves the client 
> rendering engine that works seemlessly with the browser experience.  
> What does InfoPath generate upon completion of a form?  Believe it or 
> not, clean XML... which we convert to a HL7 R01 message.  We're 
> really happy with it, and are eagerly awaiting another open source 
> product that has these InfoPath-like features.  OpenOffice has some 
> early signs of this functionality, so we're looking forward to that. 

OK, interesting. As far as I can work out, here in Australia InfoPath is
only available as part of a Microsoft "enterprise agreement", which in
turn is only available to very large companies, if they chose to go down
the Microsoft-everywhere-for-everything path. Certainly the consumer,
small business and educational versions of MS Office don't include
InfoPath here in Oz, so hardly anyone has seen it. I'd be interested in
seeing it in action, but not sure how.

> I'd be happy to set you up with an example of this if you have 
> interest.  We've used it for tens of thousands of direct data 
> captures from paper forms in Western Kenya, and the data entry team 
> loves it.

Ok, most interested.

> Once again, we made conscious decisions to compartmentalize 
> proprietary software solutions for specific uses, and have built with 
> full anticipation that an open source equivalent could sweep in and 
> replace it.  Ideally, we just let people choose the data entry 
> mechanism they like best.
> 
>> Or do
>> users need to have an InfoPath "runtime" package installed on their
>> (presumably Windows-only) client workstations? 
> 
> Yep, that's all that's required.  MS Office 2003 needs to be 
> installed (along with SP2), and OpenMRS data en

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: Question re OpenMRS data entry forms

[Paul]

Tim,

--- In openhealth@yahoogroups.com, Tim Churches <[EMAIL PROTECTED]> wrote:
>
> Paul,
> 
> A question regarding OpenMRS data entry forms. I notice form this 
wiki
> page: http://openmrs.org/wiki/FormEntry_Technical_Overview - that
> Microsoft InfoPath is used for form-based data collection in 
OpenMRS. I
> think, and correct me if I am wrong, that means that sites running
> OpenMRS need to license Microsoft InfoPath, which is part of the
> enterprise version of Microsoft Office, and/or Microsoft SharePoint
> Server, in order to serve up InfoPath forms? Is that correct? 

Well, yes.. we have a module within OpenMRS that allows data entry 
using Microsoft InfoPath client.  However, we're using the client 
that's a part of any base Microsoft Office install.  From our 
perspective, that was as close to commodity software as you could get.

Why do we use InfoPath alongside OpenMRS?  A little background might 
be helpful.  In short, we're big fans of the MVC design pattern.  In 
our data model, you've maybe understood the concept dictionary 
approach, but you might not have noticed our "form" objects.  In our 
world, a patient has 1 to n encounters, and within each clinical 
encounter, 1 to n "forms" can be collected.  Forms are merely 
collections of data, made up of 1 to n fields.  Each field points to 
a concept in our system.  We've abstracted out these notions for 
storage in our repository, so that we can render these forms using a 
number of different data entry mechanisms, perhaps even 
simultaneously.  IE, web page, OCR'ed form software, PDAs, etc.  Our 
first, most pressing data entry need was through our web interface 
however, so we went down the path of looking at open source MVC-based 
data entry techniques.   We naturally zeroed in on XForms.  
Unfortunately, XForms technology is still quite green, and 
implementations are either feature poor or just don't feel right.  
Microsoft InfoPath, however.. is pretty damn impressive.  InfoPath 
can take form schemas that we render in XML, and the application 
allows one to both render style sheets for the user interface around 
these schemas (complete with constraints around the metadata we 
define in our dictionary) and then additionally serves the client 
rendering engine that works seemlessly with the browser experience.  
What does InfoPath generate upon completion of a form?  Believe it or 
not, clean XML... which we convert to a HL7 R01 message.  We're 
really happy with it, and are eagerly awaiting another open source 
product that has these InfoPath-like features.  OpenOffice has some 
early signs of this functionality, so we're looking forward to that. 

I'd be happy to set you up with an example of this if you have 
interest.  We've used it for tens of thousands of direct data 
captures from paper forms in Western Kenya, and the data entry team 
loves it.

Once again, we made conscious decisions to compartmentalize 
proprietary software solutions for specific uses, and have built with 
full anticipation that an open source equivalent could sweep in and 
replace it.  Ideally, we just let people choose the data entry 
mechanism they like best.

> Or do
> users need to have an InfoPath "runtime" package installed on their
> (presumably Windows-only) client workstations? 

Yep, that's all that's required.  MS Office 2003 needs to be 
installed (along with SP2), and OpenMRS data entry functionality with 
InfoPath works.

> Or is OpenMRS just using
> the InfoPath form layout XML format, and provides its own form 
engine to
> interpret and render those XML form definitions on users' computers?

Nope, we let InfoPath do what it does best.. render XML forms and 
provide a rich end user experience around this functionality.  
They've done it right with this product, and the OSS community will 
pick up on this soon enough.

> I'm not asking these questions by way of criticism (for use of a 
closed
> source solution) - pragmatism should always win over open source 
purism
> if there is no other way, in my view. I am just curious about how 
you
> arrived at this particular mix of Microsoft and OpenMRS software? We
> wrestled with the problem of online forms for NetEpi Collection, and
> seriously investigated the XForms standard for defining form 
layouts,
> validation and other runtime behaviour using XML, but decided to 
ignore
> it because a) it was vastly over-complex and b) hardly anyone seems 
to
> be implementing it - Microsoft have Infopath/SharePoint instead, and
> others are working on  "Web Forms 2.0", which is much simpler (and 
which
> we may eventually adopt). We also looked at Adobe Acrobat, because 
the
> full version of Acrobat allows you to define data entry forms which 
can
> be both printed (for handwritten completion) and/or filled in 
online,
> using the free Acrobat Reader software. I note that STC, which is
> probably the largest and best known vendor of closed-source public
> health software, uses Adobe Acrobat for its user-defin

[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
> 
> 
> 
> .
> 

[openhealth] Question re OpenMRS data entry forms

[Tim Churches]

Paul,

A question regarding OpenMRS data entry forms. I notice form this wiki
page: http://openmrs.org/wiki/FormEntry_Technical_Overview - that
Microsoft InfoPath is used for form-based data collection in OpenMRS. I
think, and correct me if I am wrong, that means that sites running
OpenMRS need to license Microsoft InfoPath, which is part of the
enterprise version of Microsoft Office, and/or Microsoft SharePoint
Server, in order to serve up InfoPath forms? Is that correct? Or do
users need to have an InfoPath "runtime" package installed on their
(presumably Windows-only) client workstations? Or is OpenMRS just using
the InfoPath form layout XML format, and provides its own form engine to
interpret and render those XML form definitions on users' computers?

I'm not asking these questions by way of criticism (for use of a closed
source solution) - pragmatism should always win over open source purism
if there is no other way, in my view. I am just curious about how you
arrived at this particular mix of Microsoft and OpenMRS software? We
wrestled with the problem of online forms for NetEpi Collection, and
seriously investigated the XForms standard for defining form layouts,
validation and other runtime behaviour using XML, but decided to ignore
it because a) it was vastly over-complex and b) hardly anyone seems to
be implementing it - Microsoft have Infopath/SharePoint instead, and
others are working on  "Web Forms 2.0", which is much simpler (and which
we may eventually adopt). We also looked at Adobe Acrobat, because the
full version of Acrobat allows you to define data entry forms which can
be both printed (for handwritten completion) and/or filled in online,
using the free Acrobat Reader software. I note that STC, which is
probably the largest and best known vendor of closed-source public
health software, uses Adobe Acrobat for its user-defined custom data
entry/paper-based data collection forms.

In the end, we implemented our own forms engine, which stores
definitions in simple XML documents held in the database. The result is
adequate, but it is not as slick or as capable as we would like, and was
a lot harder to do than we thought. I'm not absolutely convinced it was
the right decision.

Tim C

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] Hi folks..

[Karsten Hilbert]

On Sun, Feb 18, 2007 at 12:59:38PM +1100, Tim Churches wrote:

> 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.
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.

> GNUmed uses
> a cross-platform GUI (wxWindows), rather than a Web interface, though.
Yes. We have a proof-of-concept web frontend, too, which
uses the same (Pythonic) middleware. And we have a XML-RPC
interface for remote-controlling the wxPython client (say,
from legacy applications - which we already do).

> But the design issues are similar.
Yes.

Re MPI/COAS/PIDS in this thread: My argument for not using
them (today!) in GNUmed is simply that I lack the man-power
(and, perhaps, intellectual prowess). However, I do think
that the current GNUmed infrastructure has a limited
timespan and that issues for federation will come into play
at some point. At which point I will turn to FEBRL and PIDS
as the first step for using an (if local) MPI.

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