gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] emrjounalplugin.py comments further html work


From: Syan Tan
Subject: Re: [Gnumed-devel] emrjounalplugin.py comments further html work
Date: Mon, 19 Sep 2005 16:18:57 +0800


I think not having a meta-schema is one of the problems that makes gnumed development very slow.
Karsten seems to refine his ideas about his static clinical schema quite frequently enough, and this
breaks any attempts to parallelize work on gnumed, where people want to contribute , but don't want
to step on Karsten's carefully evolved central schema and schema viewer/editor ( aka business layer, gui layer)
versioned co-existing schemas using a meta-schema and and viewers/ editors that manipulate the schema
via the metaschema might work as a way of isolating domain refinement changes from application programming.
People have been promoting openehr as a way of doing this , but what is openehr ? If one looks at  the java docs for Chime website which is managing openehr web front, the schema is that of another project , and the java adl parser subversion repository has a script which puts a copyright header for university college london on the java programs, not very inviting as a basis for a gnumed metaschema.

gnumed has a encounter , health_issue, clin_episode, clin_root_item division ,  which on a very basic level is really a division of

the attributes time, place, observer,  classification,  aggregator ,  clinical details. The aggregator is clin_episode, and it aggregates

clinical details which links the tuple (time,place,observer) with a classification.

Previous  free to use schemas already exist, which are in corba  COAS clinical observation service , and are defined as IDL headers, and

are easily compilable to python , C++, java with the numerous freely available corba distributions ; the observation based schema

might parallel the HL7 2.3   OBX / OBR segments, and one presumes that the mapping between COAS objects and HL7 OBX/OBR isn't

that far apart.  Some one might argue that gnumed should give up health_issue , and make it some sort of  clinical_item, and clin_root_item

some sort of clinical_item,  only that it has  a reference to an encounter, wherease all clinical_items have a reference to a patient,

which would make it more parallel to the COAS and HL7 objects , and might make take it easier to translate between the different

schemas.

 





On Mon Sep 19 6:39 , J Busser sent:

At 10:50 AM +1000 9/19/05, Horst Herb wrote:
>Don't think of it as a diagnosis then, think of it as a problem list.
>How else would you be able to quickly browse a patient's history if encounters
>weren't labelled with something meaningful?
>
>Even if you have ten encounters labelled as "vague unspecific symptoms" it is
>most helpful, because then really alarm bells should ring - whereas 10
>unlabelled episodes are far less likely to draw your attention

Horst, in your mini-gnumed is each of your visit SOAP notes a single
row in a clinical notes table?

And how are your many-to-one relationships between multiple problems,
and a particular progress note, stored in the mini-gnumed backend? I
don't believe GNUmed proper, as its schema is currently defined,
would support that (?)

Karsten, are these approaches (current GNUmed vs Horst's in which a
single note record can be linked to multiple problems) incompatible
in the same schema?


_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel



reply via email to

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