[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: [openhealth] Consolidation Proposal: ClearHealth,

From: Ian Haywood
Subject: Re: [Gnumed-devel] Re: [openhealth] Consolidation Proposal: ClearHealth, FreeMED and OpenEMR
Date: Thu, 16 Jun 2005 23:01:08 +1000
User-agent: Debian Thunderbird 1.0.2 (X11/20050331)

Tim Cook wrote:

> This question again really refers back to my question about your
> CLINICAL data and maintaining the context in a patient record over long
> periods of time.  Load testing for performance is a very different
> thing.  If this issue still isn't clear I'll attempt to expand on it.
I think your question relates to eariler generations of database
technology which had a tendency to 'lose' records due to loss of database 

Postgresql has been in use for a long time (10+ years) storing large datasets 
for long
periods (we must not be so arrogant as to think only doctors value data 

>>>7) is all clinical data coded?
>>All clinical data is categorized into SOAP. All clinical
>>narrative *can* be coded if you so wish.
> Certainly anyone CAN type in ICD's or other codes.  The question is does
> your data entry mechanisms FACILITATE clinical coding?  This is
> important so that the EMR can drive things such as billing, decision
> support, population health and other analysis reporting (given
> appropriate ethical considerations of course).  Otherwise the EMR falls
> short of user expectation and actually increases the overall workload
> for no apparent benefit.
>>>If so which vocabularies or standards
>>>are allowed/provided for?
>>*Any* you care to use.
> A meaningless answer.  Does this indicate the level of understanding of
> clinical coding or a lack of appreciation for the requirement?
One of the problems (in the Australian context) is clinical coding is
often an answer in search of a question.

To clarify:
        - GPs are not funded by diagnosis coding.
        - there is very little research activity outside of public hospitals
(even less since a privacy scandal engulfed the only GP-based data registry)
        - decision support is poorly trusted, lack of good clinically relevant 
knowledge sets
makes this worse (i.e interaction databases cannot distinguished clinical 
relevance of warnings,
so the prescriber is swamped by pointless warnings, so turns them off) The 
reward/cost benefit
for coding everything just for decision support is difficult to justify.        

>>>8) do you have a dynamic security model that allows various roles
>>>are implementation specific?
I suspect this question involves HIPPA somewhere along the line.
The simple answer is we are not targetting the US so have no interest (yet)
in its specific requirements

The longer answer is postgresql allows permissions to the set for each 
individual table,
so its easy to define privileges to very precise levels.

What's not possible (yet) is per-patient privileges, this would have to be 
but I'm don't see how this is fundamentally more or less difficult than adding 
any other feature.

> How curious.  This is usually considered a "quick win". An EMR without
> prescribing capability.  Is there a specific reason for this?
No, this should clarify the development stage of gnumed.
(i.e were it an embryo it would still have gill-slits ;-)
>>>If you allow nulls anywhere in your database you run the risk of
>>>returning incorrect information.
Huh? This means your query is wronly designed.

Personally I think NULLs are useful. Certainly better than using a dummy value, 
NULL != NULL, which is the correct bhevaiour.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]