Eclipse OHF Project OpenEHR Component
The Eclipse Open Healthcare Framework (OHF) Project is an open source project whose aim is to build an e-health computing platform (tools, run-times and community) on which developers can more effectively build useful and interoperable applications? Eclipse is widely known as a tools IDE, or even just a Java development environment. But Eclipse is more than this. Eclipse is a community with a strong open source governance model that develops tools which have strong reuse of the knowledge code for run-time use by developers. We believe that the openEHR community could leverage the Eclipse platform - the tooling, run-time and governance support, to improve the coherence of the the tools, implementations and uptake of openEHR. OHF will propose an openEHR component at the European EclipseCon meeting. We have an OHF FTF meeting in Stuttgart on Oct 13th, where the project will be proposed for formal adoption as an OHF component. I am currently working with Tom Beale to clarify the scope of the proposal, and how it relates to an overall tooling roadmap for openEHR. This notice is an invitation to come to the Stuttgart meeting and have your say, or to work with Tom and I on the proposal in advance. Grahame links: Eclipse OHF: http://www.eclipse.org/ohf EclipseCon: http://www.eclipsecon.org/summiteurope2006/ Stuttgart Meeting announcement: http://www.eclipse.org/newsportal/article.php?id=216group=eclipse.technology.ohf#216 (see http://www.eclipse.org/newsgroups/register.php for access to OHF newsgroup)
[RESEND] C_PRIMITIVE and C_DOMAIN_TYPE
Resending, because of problems with the list. Should C_DOMAIN_TYPE classes be defined based (using) on C_PRIMITIVE? and more, are any of the C_PRIMITIVE classes used directly as a constraint to an archetype element? these questions refer to the fact that string or integers by themselves do not have any semantic meaning, they acquire meaning inside DATA_VALUE instances, do they not? So as we advance in using and understanding AM we find that more classes may be needed in the PROFILE package in order to validate DATA_VALUES. just thoughts, and doubts, we are trying to understand the model, and how it is used. If you could tell us how you use it, I believe it would be very helpful. thank you Rodrigo Filgueira Asistente Docente/Investigador N?cleo de Ingenier?a Biom?dica, FING - UDELAR
Parsing of TEXT
Hi,
I am trying to figure out what should be the correct production in the
AOM for the following ADL code. What bothers me most is the TEXT
matches {*} construct.
ELEMENT[at0002] matches {-- Accident or exposure
value matches {
TEXT matches {*}
}
}
I have seen this used quit a bit in the sample archetypes, but I dont
thing the parsed object model from the java parser is correct since it
makes it a CComplexObject leaf node with RMTypenam of TEXT. From the
specification I know that CComplexObject should only be inner nodes in
the AOM. I have queried the online documentation and found references
to TEXT in the 1.2 adl, but nothing in 1.4 that describes what TEXT
matches {*}.
I was inclined to assume it should be DvText constrained with the
regular expression /*/.
Please advise if I am totally off the ball with this.
Thanks
Newton
[RESEND] C_PRIMITIVE and C_DOMAIN_TYPE
Rodrigo Filgueira wrote: Resending, because of problems with the list. Should C_DOMAIN_TYPE classes be defined based (using) on C_PRIMITIVE? I believe a common interface (C_DATA_TYPE) should be extract from these two classes as I pointed in my previous post. Rong and more, are any of the C_PRIMITIVE classes used directly as a constraint to an archetype element? these questions refer to the fact that string or integers by themselves do not have any semantic meaning, they acquire meaning inside DATA_VALUE instances, do they not? So as we advance in using and understanding AM we find that more classes may be needed in the PROFILE package in order to validate DATA_VALUES. just thoughts, and doubts, we are trying to understand the model, and how it is used. If you could tell us how you use it, I believe it would be very helpful. thank you Rodrigo Filgueira Asistente Docente/Investigador N?cleo de Ingenier?a Biom?dica, FING - UDELAR
Parsing of TEXT
Newton Aird wrote:
Hi,
I am trying to figure out what should be the correct production in the
AOM for the following ADL code. What bothers me most is the TEXT
matches {*} construct.
ELEMENT[at0002] matches {-- Accident or exposure
value matches {
TEXT matches {*}
}
}
I have seen this used quit a bit in the sample archetypes, but I dont
thing the parsed object model from the java parser is correct since
it makes it a CComplexObject leaf node with RMTypenam of TEXT. From
the specification I know that CComplexObject should only be inner
nodes in the AOM. I have queried the online documentation and found
references to TEXT in the 1.2 adl, but nothing in 1.4 that describes
what TEXT matches {*}.
I was inclined to assume it should be DvText constrained with the
regular expression /*/.
Hi Newton,
TEXT matches {*} basically says a DvText object will be created for
this node and there is no constraint on the actual value. So what's
produced from the parser is correct.
But for String constraints cADL has its own syntax. So the ADL should be
something like the following to be more correct. Then a CString node
will be created instead.
ELEMENT[at0002] matches { -- A..
value matches {/*/}
}
See part 4.4.1 of ADL speficiation for more information.
Cheers,
Rong
Please advise if I am totally off the ball with this.
Thanks
Newton
Eclipse OHF Project OpenEHR Component
This sounds like a very good idea. A coherent environment (including demos, code examples, tutorials etc...) would give openEHRarchetypes the boost that this well-designed architecture deserves. Will ask Tom about it at the MIE. I would like to help, but I am only a med student and no real geek. Live only 3 hours from Esslingen, unfortunately I already have an appointment on this friday morning. -Thilo Grahame Grieve schrieb: The Eclipse Open Healthcare Framework (OHF) Project is an open source project whose aim is to build an e-health computing platform (tools, run-times and community) on which developers can more effectively build useful and interoperable applications? Eclipse is widely known as a tools IDE, or even just a Java development environment. But Eclipse is more than this. Eclipse is a community with a strong open source governance model that develops tools which have strong reuse of the knowledge code for run-time use by developers. We believe that the openEHR community could leverage the Eclipse platform - the tooling, run-time and governance support, to improve the coherence of the the tools, implementations and uptake of openEHR. OHF will propose an openEHR component at the European EclipseCon meeting. We have an OHF FTF meeting in Stuttgart on Oct 13th, where the project will be proposed for formal adoption as an OHF component. I am currently working with Tom Beale to clarify the scope of the proposal, and how it relates to an overall tooling roadmap for openEHR. This notice is an invitation to come to the Stuttgart meeting and have your say, or to work with Tom and I on the proposal in advance. Grahame links: Eclipse OHF: http://www.eclipse.org/ohf EclipseCon: http://www.eclipsecon.org/summiteurope2006/ Stuttgart Meeting announcement: http://www.eclipse.org/newsportal/article.php?id=216group=eclipse.technology.ohf#216 (see http://www.eclipse.org/newsgroups/register.php for access to OHF newsgroup)
