An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070221/8984f349/attachment.html>
-- next part --
___
openEHR-clinical mailing list
o
Andrew and William,
> > For me encounter and medication list are definitely not archetypes:
> > they differ too much in each circumstance, they are templates that
> > will hold several to many archetypes.
>
> I don't understand the distinction you make here - archetypes
> can hold other arche
William,
> In this formalism we need to be able to define discrete items (clinically:
> one observation
> or one measure, e.g. weight). Then we must be able to have archetypes that
> combine
> clinically natural combinations of discrete variables (blood pressure:
> systolic, diastolic,
> cuff s
Andrew,
> I was just asking from the point of view that, if it say
> became mandatory (or even a selling point) in the US to
> support CCR, how would you imagine it being supported in an
> openehr system (as much as that would be a waste of the
> features in openehr - sometimes you've gotta do
> Well, we will have to agree to disagree, but ultimately it is the clinicians
> that will make the decision, not us techos.
Actually, I'm understanding your point of view more now - I'm totally
in agreement that its not us technical people that makes these
decisions. The CCR may be an absolute ab
Brett,
> I know what you are saying about RIM semantics but aren't the
> openEHR RM classes, OBSERVATION, INSTRUCTION, EVALUATION,
> etc. implying a general weak clinical semantic as a framework
> for hanging stronger semantic archetyping. I can imply
> certain things about a stored openEHR
Andrew,
> > Actually sections are purely organisational only, they do
> not change
> > the semantics of the entries inside them.
>
> I guess I disagree about the possibility (or usefulness) of
> defining globally recognised archetypes as you go further up
> the tree (towards organising arche
Dear Sam,
One thing that's not clear with me is the very issue you ask which is
fundamental requirement: why to restrict/limit slots? I guess possibly
due to licensing issues and also data integrity and interoperability. So
I see this issue mainly as how much control is kept in openEHR space or
attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070221/f184c2d3/attachment.html>
-- next part --
___
openEHR-clinical mailing list
openEHR-clinical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Heath,
I know what you are saying about RIM semantics but aren't the openEHR RM
classes, OBSERVATION, INSTRUCTION, EVALUATION, etc. implying a general
weak clinical semantic as a framework for hanging stronger semantic
archetyping. I can imply certain things about a stored openEHR
OBSERVATION bas
> openEHR does not intended for this to happen. However, this does not mean
> that organisations can't have local archetypes but they should not
> semantically overlap with those archetypes that are globally recognised.
> This is the fundamentals of Archetype Governance which is under development
Andrew,
> > data structure defined by a particular organisation but has no true
> > semantics in health, where as a discharge or referral is a
> common concept.
>
> Well, not strictly true - the CCR has semantics that aren't
> the same as discharge or referral but they are seemingly
> clear
> data structure defined by a particular organisation but has no true
> semantics in health, where as a discharge or referral is a common concept.
Well, not strictly true - the CCR has semantics that aren't the same as
discharge or referral but they are seemingly clear to the CCR people
- the CCR
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070221/3ad85e5e/attachment.html>
-- next part --
___
openEHR-clinical mailing list
o
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070221/43a05b7c/attachment.html>
-- next part --
___
openEHR-clinical mailing list
o
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070221/9b28f35e/attachment.html>
-- next part --
___
openEHR-clinical mailing list
o
Hi Ian,
> I am interested in your comment "the former template design
> is a knowledge development step possible used by more than
> one application" because as well as templates being a
> precursor to form design can they also play a part in
> 'dataset' definition by capturing the requirement
I apologise for my rather irreverant previous postthat was an oops.
Are openEHR template specialisation hierarchies a real possibility? This
would be particularly useful in message profiles, and conformance level
assertions made by systems.
Btw: would consider the openEHR RM classes archetype
lied to it, for a start it is considered an
> observation not
> an instruction for instance.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070221/5658c20c/att
:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20070221/9203867f/attachment.html>
-- next part --
___
openEHR-clinical mailing list
openEHR-clinical at openehr.org
http://www.chime.
"Heath Frankel" wrote:
I have to agree to a high degree with Heath here (exception is on the HL7
harmonisation process).
I have been working on developing archetypes since original CEN work for ICNP /
Mose / Nursys, and follow up work in templates within HL7 work. Further several
Dutch projec
21 matches
Mail list logo
