ok, we have real convergence here.
OpenEHR works exactly like HL7 - define a reference model
with all the needed semantics, and then refine things away
in constraint models (and use the refinements as a basis for
composition). So the principle is the same.
We can generate [class
Grahame,
One of the theoretical difficulties of the debate that you are contributing
so eloquently to is to separate methods proper to computing from methods
defined by domain specificity.
Object-oriented programming, modular design, abstract data types, etc. are
fundamental principles whose
Graham,
Isn 't is a matter of scope, as the thing we need to have agreement
on first?
Isn 't is a matter of requirements, as the thing we need to have
agreement on second?
Will the rest of the harmonisation process follow from that?
I think that harmonising two things with substantial
Hi Tom
This is not a difference; it's true of HL7 as well
I think people would have a hard time finding it - where is the
reference model from which you can build software?
You can build it from RIM or DMIM's or Messages. Would this be a
good choice? I suspect not. But let's be correct
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/bc7ff7d5/attachment.html
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/cf880ee3/attachment.html
Dear William,
Please note that some of the vocabulary mappings, and correspondence with the
main HL7 Act specialisations are provided in 13606 Part 3. I recognise this is
not the complete solution you seek, but it is a start.
(The Enquiry draft of Part 3 was recently circulated to CEN Working
Hi Tom
The main difference architecturally is that there in openEHR there is a
reference model from which software and systems can be built.
This is not a difference; it's true of HL7 as well
Archetypes
and templates simply designate legal configurations of instances of the
reference
al).
well, I can't speak for the designers (I'm spending some time with him
today on this subject ;-), but archetypes and HL7 models are the same thing.
I can interconvert between them. The only issues are syntactical differences
in things that are allowed in each language, and they
I have code to build the archetypes from the internal source of
the R-MIM's rather than the schemas. I will be publishing
this through eclipse shortly.
I will be able to go the other way too, but both formats will
need modifications for gap coverage. I am presenting changes
to the RMIM diagrams
In een bericht met de datum 13-9-2006 23:44:53 West-Europa (zomertijd),
schrijft Thomas.Beale at OceanInformatics.biz:
The main difference architecturally is that there in openEHR there is a
reference model from which software and systems can be built. Archetypes
and templates simply
Williamtfgoossen at cs.com wrote:
Yes, it is currently not possible in the archetype editor to define
the goal of an instrument, have a abstract of the evidence base in the
clinical world underpinning it, work instructions, interpretation
guidelines, references to the literature or
Williamtfgoossen at cs.com wrote:
In een bericht met de datum 14-9-2006 20:33:51 West-Europa
(zomertijd), schrijft Thomas.Beale at OceanInformatics.biz:
Hi William,
Since I am not 100% sure of the details of what you want to do, I won't
make any claims yet, but it seems to me that the
In een bericht met de datum 13-9-2006 21:25:34 West-Europa (zomertijd),
schrijft odysseas at sysnetint.com:
Hello,
Are there any documents anywhere that describe or compare and contrast the
OpenEHR initiative and the HL7 EHR effort? I have seen a couple of
references
to the fact
The main difference architecturally is that there in openEHR there is a
reference model from which software and systems can be built. Archetypes
and templates simply designate legal configurations of instances of the
reference model. In HL7, the data are instances of schemas that are
15 matches
Mail list logo
