Hi Hugh and Gerard,
I very much agree that snomed coding should only be done where it adds
value. Since archetypes provide meaning themselves not everything has
to be coded (as opposed to HL7 that relies more on external codes).
Although for export to non-openEHR formats (or data-mining on
Dear all,
It is all about patterns for documenting.
I agree that inspection of the present collection of openEHR
archetypes and those produce by the NHS are a nice resource.
But we must realize that these were produced for demonstration,
testing, learning or the collection of information
Hi,
The way I like to think about it is that there is a generic archetype
for lab-tests as a recurring 'pattern'.
Each individual lab test procedure is a code from a general coding
system.
The way Lab-test are reported (quantitative data, in what units of
measurement, precision, normal
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080612/fb6f2e22/attachment.html
Hi Hugh,
ok, you got me ;), I tried but I could not find a case were there would
have been a value in knowing that two standings are (more or less) the
same, I think because the word standing is so obviously *well-enough*
defined in everyday English, even for a Swede! But what about e.g. the
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080611/73a8c58e/attachment.html
Dear Daniel,
yes, I said that the grey zone is a relic of the past,
It is there and we have to deal with it.
But that is not to say that it must stay the same.
To my mind we have to be aware that when dealing with semantics and IT
we must stay close to the eons proven way to do things.
For
Dear Everyone,
just to add another perspective, in the Galen project post coordination
was the norm while IHTSDO sits on a heritage of some 300 000 things
Snomed CT needs to take care of. Also, pre-coordination is (I think)
required for making fixed length identifiers. Still, Snomed CT is
?
In order to solve it we must look forward and reduce the 'grey zone'
by acknowledging that most post-coordination (using modifiers in
Snomed-space instead of Archetype/Template space) must end.
Gerard
Realizing that the current Snomed CT Concept Model is not enough (today,
unfortunately
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/d6b41912/attachment.html
Hugh,
The argument comes when you say that every data point in an archetype
needs to be coded and here there are arguments both ways. I would say
that it is unnecessary to code every data point. There is little
benefit for instance in coding sitting, lying, standing, reclining n a
blood
Hi Daniel, Hugh et al.
A couple of weeks ago I started a section on the wiki to collect use
cases for terminology mappings from archetypes:
http://www.openehr.org/wiki/display/healthmod/Archetypes+and+Terminology#ArchetypesandTerminology-Usecasesforterminologyreferencesinarchetypes
IMHO this is
Dear colleague,
I agree with you that the grey zone is a relic from the past we have
to deal with.
Never the less, I want to argue that we have to reduce this grey-zone.
By means of my suggestion to do post-coordination as much as possible
in the archetype.
The main reason is:
- In language
leslie,
I agree with the statement below.
Gerard
On Jun 10, 2008, at 10:06 AM, Hugh Leslie wrote:
openEHR needs SNOMED and I believe that SNOMED needs archetypes.
The decision will be where archetypes and SNOMED should begin and
end and I think there will be a lot of debate in the next
Hi Gerard,
I agree with most of your comments and in principle that most
post-coordination (using modifiers in Snomed-space instead of
Archetype/Template space) must end, this amounts to heresy in a UK
context and I think we should be prepared to regard David Markwell's
Grey Zone as a contested
Hi Ian and Gerard,
Could you please explain what post-coordination is and maybe provide
an example of post- (and pre-?) coordination?
Cheers,
Stef
Op 5-jun-2008, om 0:48 heeft Ian McNicoll het volgende geschreven:
most
post-coordination (using modifiers in Snomed-space instead of
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/725c0b1f/attachment.html
Ian,
I agree.
But my wished outcome is clear.
And of course we have to deal with the past.
But the sooner we, ...
Gerard
On Jun 5, 2008, at 12:48 AM, Ian McNicoll wrote:
Hi Gerard,
I agree with most of your comments and in principle that most
post-coordination (using modifiers in
technical
discussions
Cc: timothywayne.cook at gmail.com
Subject: Re: Decision Support was: MIE-2008
Yes, agree on the querying ... and for querying we need structured
content!
As Sam and I noticed before this has to be considered when designing
archetypes. This doesn't mean there shouldn't
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/5d6ab130/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanInformaticsl.JPG
Type: image/jpeg
Size: 5828
Hi,
Free text versus structured data and information debate:
- Like Ian said: Archetypes and templates take away problems from the
IT-domain and leave them for those in healthcare.
When those in health need, want decision support they will have to use
more structured info.
In the end they
Hi Sam,
Boosted clinical process is a nice term indeed, maybe another alternative
would be augmented clinical process, inspired by augmented reality, which
could probably have interesting applications in healthcare.
I should say that I am not sure if I have made my mind about the outcomes of
On Mon, 2008-06-02 at 00:41 +0300, Seref Arikan wrote:
In case any member of this group have a candidate app for a trial like
this, I'd be delighted to get some pointers for future work.
I was going to save this for the decision support mailing list. But
since you asked ... :-)
The
On Mon, 2008-06-02 at 09:45 -0300, Tim Cook wrote:
A re-implementation of this engine using GLIF instead of Arden Syntax
guideline encoding
BTW: I am not including/excluding other possibilities here. PROforma is
a prime candidate but even after reading John Fox's book Safe and
Sound:
On Mon, Jun 02, 2008 at 09:48:17AM -0300, Tim Cook wrote:
I'd really like to see the outcomes of a little project which would be
about porting a simple existing decision support system to an OpenEHR
based infrastructure. Warning against adverse drug events for patient
safety would be a
On Mon, Jun 02, 2008 at 09:45:08AM -0300, Tim Cook wrote:
The EVIDENCE-BASED GUIDELINES AND DECISION SUPPORT SYSTEM (EGADSS)
The basic concept is that an EMR sends a basic known set of information
about a patient to the DSS. The DSS processes whatever clinical
guidelines it knows about
-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Thilo Schuler
Sent: Saturday, 31 May 2008 8:13 PM
To: timothywayne.cook at gmail.com; For openEHR technical discussions
Subject: Re: Decision Support was: MIE-2008
I am also interested. I wonder how much
On Mon, 2008-06-02 at 15:14 +0200, Karsten Hilbert wrote:
That's precisely how I would want a DSS to work for
interfacing it with GNUmed. When I last looked at EGADSS (a
year or so ago) it looked like they wanted me to use their
own GUI not just for defining guidelines but also make the
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080601/4358c1c3/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanInformaticsl.JPG
Type: image/jpeg
Size: 5828
Tim Cook wrote:
On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote:
I wonder if we should have a particular list for people who are interested
in working with openEHR from a decision support point of view.
This may not be appropriate just yet but I believe it will generate a
I am also interested. I wonder how much decision support has to be
considered when designing archetypes. In the near and midterm future
decision support will probably mostly happen on a local (i.e.
template) level, but I still assume that there should be design
patterns of the underlying
Hi,
That's an interesting question, and honestly, my knowledge of archetypes is
a little bit rusty to comment on this. However, there are other aspects of
OpenEHR related work which I find worthy of discussing in the context of
decision support.
A decision support system is built on top of other
On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote:
I wonder if we should have a particular list for people who are interested in
working with openEHR from a decision support point of view.
This may not be appropriate just yet but I believe it will generate a
considerably different
33 matches
Mail list logo
