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 [email protected], 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 
> 

Reply via email to