terminology
I found it out, partly, myself. The document RC1.1/publishing/architecture/computable/terminology/Terminology.xsd.html (in my local copy of the repository) was very helpful. I, now, more or less understand the structure of classes which form the terminology. *Please correct me if I am wrong.* It all boils down to the concept/language which will be represented in the terminology-access. This looks like this id: String all_codes: Set codes_for_group_id (group_id: String): Set codes_for_group_name (name, lang: String): Set rubric_for_code (code, lang: String): String So, the groups (grouper) are visible in Group_id, which can be retrieved by querying the OPENEHR_TERMINOLOGY_GROUP_IDENTIFIERS Class. The openehr terminologies are all in the file terminology.xml, organised in the structure which is described in the above html-file. This is very good. There is one minor problem, the group_id's in the class do not sync 100% with the group-id's in the xml-file. Here is a question *Which one will prevail, that from xml, or that from PDF? * I found out, that there are some codes which have a structure that does not fit in terminology_access, because they have more "fields" like territory and terminologyidentifier, mediatype. *How to handle these? *Finally, there is the property-unit-propertyuntit structure. It looks like, but I am not sure, that these are for, I can guess. But maybe my guess is wrong, the terminolgoyaccess class does not offer space for properties. *How to handle these, what are these for *Thanks for your attention Bert -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070307/2b3c6868/attachment.html> -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
On Wed, Mar 07, 2007 at 12:43:51AM +0100, Gerard Freriks wrote: ... > ... revolutions, that changed society ... Past Tense ... > And EN13606 and openEHR will be the same. Future Tense "Revolutionary" can only be applied after the fact. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN meeting and data types
Hi >> So the HL7 qualifier thing is (mostly) simply a predefined expression syntax >> for >> post-coordination. It overlaps with terminologies that have their own >> expression >> syntax - such as SNOMED. The HL7 model does allow a richer expression of the >> details of the construction of the expression - such as which text led to >> which >> qualifier, but this is, as I said, for precision and pedantry. Not for normal >> everyday use. So the question is, is it better to squeeze things into the >> text of a CODE_PHRASE, or to squeeze things into xml? Either way, you need to >> have a terminology service to do anything useful with the data. So what's the >> difference? I don't have a strong feeling about that. >> >> > I think the main point here is that CODE_PHRASE and other similar parts > of the openEHR model (and this applies to any model at all) that are > modelled using an internal syntax string (which could itself be XML - > who is to say it isn't?) implies quite strongly that the contents of the > relevant attributes (CODE_PHRASE.code_string) are the business of some > outside system, not openEHR itself. In purely technical terms, using a > class modelling approach for such things may be the same as using the > syntax approach - i.e. any code_string generated by a terminology server > can most likely be modelled using a class model as well, something like > HL7's classes. But > * there is always the possibility that it can't - because the class > model commits to one idea of terminology coordination, while the syntax > approach leaves it open do we know of any case? > * the information model shouldn't dictate to the terminology environment > how to represent its artefacts. I have some sympathy for this. I have been tempted to toast the qualifier and push everything into code as you guys have done, for the same reasons. But I haven't found any case where the existing qualifier syntax is a problem, and there is accepted requirements for originalText on the qualifiers (at least, HL7 has accepted them). SO I didn't toast it, but I did say in the openEHR mapping that you'd collapse the qualifiers into the code phrase. I don't have a strong feeling for whether this would be necessary or appropriate for 13606 Grahame ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
Quoting Gerard Freriks : > Okay Ognian. > > Let us settle for your point of view and agree. > > In the mean time you all know that it is, has to be true. > The railway and locomotive, > the steam engine in ships, > the telephone, > the fax, > the PC, > Internet, > the printed book or newspaper, > and many more things were paradigm shifts, > were revolutions, that changed society. > > And EN13606 and openEHR will be the same. > It is 'disruptive technology'. > It is ' creative destruction'. Hear, hear!!! This message was sent using IMP, the Internet Messaging Program. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
It's not a nasty word. But the revolution is over. Now it's implementation time. This is a typical case of an innovation that is mature enough to be implemented by many not only by the original inventors. Venture capitalists don't like "revolutionary", it's true. O. Pishev Quoting Gerard Freriks : > Dear Karsten, > > For several reasons I was using that special nasty word " > revolutionary". > > -1- > To be able to get 'plug-and-play' interoperability as opposed to the > very big problem of implementing many messages across vendors in a > uniform way, is REVOLUTIONARY. > > -2- > To have a standard with these capabilities that signals a paradigm > shift. > Paradigm shifts by definition are a "disruptive technology". > Meaning all old, present, working systems have to be changed > completely, rewritten even, to have the full benefit of this new > paradigm. > This is my second reason to use the word REVOLUTIONARY. > > > Perhaps people become reluctant to read about it, deploy it, etc. > But what can I do? > Tell a lie? > Play nice? > > With all reservations I will play honest. > > Gerard > > > -- -- > Gerard Freriks, MD > Huigsloterdijk 378 > 2158 LR Buitenkaag > The Netherlands > > T: > M: > E: gfrer at luna.nl > > > Those who would give up essential Liberty, to purchase a little > temporary > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov > 1755 > > > > > > On 6-mrt-2007, at 13:01, Karsten Hilbert wrote: > > > Anything dubbed "revolutionary" raises cautionary red flags. > > > > As Adrian Midgley once aptly put it: > > > > Ars longa, IT brevis. > > > > Karsten > > This message was sent using IMP, the Internet Messaging Program. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Model Driven Architecture for building the HDR and CDS
FYI: Ken Rubin passed this notice to various listservs on behalf of Bo Dagnall: [ HELP!!! I am writing an AMIA paper ] http://edodds.blogs.com/conmergence/2007/03/model_driven_ar.html -- Ed Dodds Strategist, Systems Architect facilitating convergence dodds at conmergence.com http://www.conmergence.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN meeting and data types
Grahame Grieve wrote: > > So the HL7 qualifier thing is (mostly) simply a predefined expression syntax > for > post-coordination. It overlaps with terminologies that have their own > expression > syntax - such as SNOMED. The HL7 model does allow a richer expression of the > details of the construction of the expression - such as which text led to > which > qualifier, but this is, as I said, for precision and pedantry. Not for normal > everyday use. So the question is, is it better to squeeze things into the > text of a CODE_PHRASE, or to squeeze things into xml? Either way, you need to > have a terminology service to do anything useful with the data. So what's the > difference? I don't have a strong feeling about that. > > I think the main point here is that CODE_PHRASE and other similar parts of the openEHR model (and this applies to any model at all) that are modelled using an internal syntax string (which could itself be XML - who is to say it isn't?) implies quite strongly that the contents of the relevant attributes (CODE_PHRASE.code_string) are the business of some outside system, not openEHR itself. In purely technical terms, using a class modelling approach for such things may be the same as using the syntax approach - i.e. any code_string generated by a terminology server can most likely be modelled using a class model as well, something like HL7's classes. But * there is always the possibility that it can't - because the class model commits to one idea of terminology coordination, while the syntax approach leaves it open * the information model shouldn't dictate to the terminology environment how to represent its artefacts. The key point about the openEHR approach in this area is that a CODE_PHRASE code_string is just a 'key' to a database that just happens to be a terminology service. The construction of the keys is the latter's business not the business of the client of the service. - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
Okay Ognian. Let us settle for your point of view and agree. In the mean time you all know that it is, has to be true. The railway and locomotive, the steam engine in ships, the telephone, the fax, the PC, Internet, the printed book or newspaper, and many more things were paradigm shifts, were revolutions, that changed society. And EN13606 and openEHR will be the same. It is 'disruptive technology'. It is ' creative destruction'. Greetings, Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 6-mrt-2007, at 22:56, ognian.pishev at oceaninformatics.biz wrote: > > It's not a nasty word. But the revolution is over. Now it's > implementation time. > This is a typical case of an innovation that is mature enough to be > implemented > by many not only by the original inventors. > Venture capitalists don't like "revolutionary", it's true. > > O. Pishev -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070307/335d9eae/attachment.html> -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN meeting and data types
Graham, There can not be one model (or model of systems) that does it all in a perfect way. We must agree that it is best to leave every domain with its own problems and models that help solve it. We must have a standard way to deal with it. About what is needed for EN13606 (a formal European standard and Nationale one in all Member States) I do not know for certain. On one hand everything in the EHRcom extract traveling between systems will be resolved completely. No dependence on services somewhere (or not) in between. But this holds for legacy systems, as we know them. What we want, and expect to happen, is that those old legacy systems are replaced by OpenEHR conformant (EN13606 conformant) systems. Then the rules will be different, because without several standardised services used by EHR-systems of the future we can not build the systems of the future.. Provided that those services are based on (European) Standards, no doubt. Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 7-mrt-2007, at 0:03, Grahame Grieve wrote: > I have some sympathy for this. I have been tempted to toast the > qualifier > and push everything into code as you guys have done, for the same > reasons. > But I haven't found any case where the existing qualifier syntax is a > problem, and there is accepted requirements for originalText on the > qualifiers (at least, HL7 has accepted them). SO I didn't toast it, > but > I did say in the openEHR mapping that you'd collapse the qualifiers > into > the code phrase. I don't have a strong feeling for whether this > would be > necessary or appropriate for 13606 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070307/2ca08552/attachment.html> -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
terminology
Hi,
I hope this is a stupid question, and people can overload me with
information.
I am trying to build a terminology-service, but because I want to
conform as much as possible to the specs, I try to understand them.
I have a few questions:
we have the openehr-terminology, like this: (excuse me for using html-table)
Terminology: openehr
Group_name("en"): "attestation reason"
Concept_id Rubric (en) Description (en)Mappings
240 "signed"The attested information has been signed by its
signatory. HL7_ParticipationSignature::10284
648 "witnessed" This attested information has been witnessed
by the signatory.
And I have the TerminologyAccess-class.
I cannot get them fitted to each other. I have the latest documentation,
but I cannot find a way to fit above table-information in the
terminologyaccess-class.
I figured out following, which is probably wrong:
The terminologyAccess class, to my information has mapping to table above
id -> terminology:openehr
set codes
codePhrase has following
terminologyID -> same as above -> terminology:openehr
codestring -> rubric (?)
Whereto do I map the rest?
The mappings, the description?
---
Maybe someone knows how to, and help me find some information. Some
example-code, UML, text, whatever will do.
thanks in advance
bert
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070307/c77b74e7/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
